【发布时间】：2010-10-17 01:46:37
【问题描述】：
UI 驱动开发的想法是否有意义？我们的大多数客户都喜欢以屏幕的形式表达他们的要求。例如我想要一个屏幕来做这个和那个。有时他们甚至会自己决定屏幕的布局（这可能是因为今天的客户已经在他们的大部分任务中使用了软件应用程序）。
此外，这种需求收集方法似乎可以自动传达数据和相关行为。
你们觉得呢？
【问题讨论】：
标签： user-interface requirements
【发布时间】：2010-10-17 01:46:37
【问题描述】：
其实在这方面确实是有道理的。用例在这里的不同之处在于它们不能以相同的方式使用。用例将有助于提取和形式化需求。
前段时间我在一个 UI 实验室工作，我们玩弄了这个概念，尽管我们没有这样称呼它。这里的基本想法是，我们将使用敏捷迭代方法进行开发，我们将使用可用性测试来帮助收敛到所需的解决方案。
典型的循环是：
- 草拟了一些需求和用例，范围非常有限，非常集中。
- 创建一个测试协议，使我们能够收集有关此功能的数据（可用性、易用性、接受度、性能等）。
- 创建或扩展应用程序以包含此功能
- 让一些用户使用敏捷适应可用性测试（请参阅Ruben's Handbook of Usability Testing）来测试应用程序，我们会将测试会话限制为 15 分钟，并进行 15 分钟的 debreifing。
- 从测试中提取有用的数据以注入未来的迭代中。
当用户要么不确切知道他们想要什么或不能告诉我们时，这种方法特别有用。因此，我们必须设计测试来收集关于软件对用户的实际有用性的客观数据，并因此尝试调整下一次迭代。 （如果我可以这样称呼他们，我们的许多“客户”都严重残障，无法说话，所以我们必须要有创意）。
这种工作方式迫使我们在软件开发生命周期的早期就为客户提供一个 GUI，因为它是我们直接测试的中心点，可以说它是 GUI 驱动的设计，因为它是融合的驱动力是用户与系统的交互。
尽管我们主要针对非常具体的情况开发了这种技术，但我们在普通软件上与普通用户进行了一些测试，并获得了非常积极的结果。设计将很快收敛到用户的需求。此外，他们参与这种设计方法的事实也对目标社区对产品的接受度产生了非常积极的影响。
不幸的是，在我们发表结果并扩大这一研究范围之前，实验室就因内部冲突而解散，真的很遗憾。
因此，UIDD（请原谅这个不好的首字母缩写词）将成为 TDD 系列软件开发方法的成员，其中迭代取决于用户交互。
关于该主题的补充阅读：
http://www.codinghorror.com/blog/archives/001091.html
http://cakebaker.42dh.com/2007/07/07/usability-driven-development/
http://www.springerlink.com/content/l413k76812896gnt/
http://www.agilemodeling.com/essays/agileUsability.htm
http://www.uxbooth.com/blog/how-test-driven-development-increases-overall-usability/
【讨论】：
你在做什么样的开发？当我开发 Web 应用程序（flex 或 php）时，我使用绘图（线框），这样我就可以让客户了解应用程序的流程/外观，而无需编写任何代码。
没有适合每个人的“正确的发展方式”，你只需要找到最适合你的方式。干杯！
【讨论】：
我发现这是收集需求的合理方式。我会小心实际构建屏幕，然后直接开发功能。您会发现代码重用率很低，并且您将拥有一个看起来很漂亮的应用程序，但速度很慢或不能完全正确地工作。它将适用于某些项目，而不适用于其他项目，具体取决于需求的复杂程度以及预测数据瓶颈、缓存问题等问题的能力。
听起来它类似于行为驱动开发、线框图和用户故事。
【讨论】：
故事测试驱动开发我认为这是一个很好的主意，只要你认真对待它的自动化部分。如果你不能自动化你的测试，那么你就有麻烦了。 在这里查看一篇论文：http://www.industriallogic.com/papers/storytest.pdf 听起来您的客户并没有为您提供自动化 UI 测试，但我认为这是最好的方法。
【讨论】：
我认为您在这里真正谈论的是用例 - 请参阅 this article 了解简介。
【讨论】：
-
我不同意...用例是一种工具，但它们不一定像 TDD 或 BDD 那样推动开发。用例与 TDD 中的单元测试处于同一水平，TDD 比单元测试要多得多，因为 UI DD 比用例要多得多。