敏捷开发方法需要为最后阶段定义最小需求。换句话说，所创建的任何需求细节都必须是对整个团队有关键性质的。那么，怎样确定最小需求，又由谁来负责呢？协作式或分布式团队有什么不同？如何应付这些需求在细节和优先级上的变化？下面是关于这些问题所做的解答。

如何确定最小需求？

确定最小需求是一项既简单又复杂的工作。简单是指如果作对了就会一切顺利；而复杂是指这里牵涉到许多元素，比如团队的规模大小、团队成员的融洽度、所构建的软件版本的复杂度、所开发的是插件模块还是全新系统或产品，以及在业务上广度与质量哪一方面更为重要。因此，你可能需要一些如何为团队确定需求的建议。本文将就这方面提供了一些简单的建议。

选择细节等级

首先要确定需求细节要做到什么程度。下面的表格提供了一些参考，但在最后阶段仍然要随时做好更改的准备。

“需求卡片”不能满足要求时

需求卡片是一种敏捷开发团队中常用且很有价值的方法。这些需求卡片描述了“哪些人需要做哪些事，以及为什么要做”，有时也会用来提供一些关于屏幕样图和测试方案的信息。这种方法或许足以应付小规模的开发，但如果涉及比较大型或较复杂的对其它部分有较强依赖性的模块时，就会略显不足。

不要勉强使用不适合的方法

有许多已经经过实践证明的需求采集的方法。但适时选择合适的方法是需要技巧的。比如，有时只需要在需求卡片上用文字简单地概括出“哪些人、做什么、为什么这样做”即可。而有些时候为这些描述添加一些图片可能会更好，比如模拟屏幕截图，或者再加上些脚注。

有时，要了解一个很复杂的需求的流程，可能要用到“用例流程（use case flows）”和/或“模拟过程（simulations）”来确定最小需求。但我认为，用“用例”来描述复杂的逻辑或业务规则（比如验证逻辑）却不是一个好方法。通常文字或表格更适合用来描述这种需求。比如，一个简单的2x2的表便可以用行列分别表示验证规则的功能及其作用，这比用“用例”来表示之间的选择关系要有效得多。

同样，在做模拟过程的时候也有可能因为做得过于细致而浪费与所得价值不成正比的精力。虽然模拟过程在“生动地描述一个概念”方面有不可估量的价值，但要将每一个细节都考虑进去却需要时间。并且很显然，对于开发人员来说，还要反向剖析这些模拟过程并从中抽取出离散的需求来，而这项工作有时会很困难。还以业务的验证规则为例，开发人员通过阅读一个2x2表格便能很快明白要做哪些事，但运行一个模拟过程并反向剖析出同样的信息来却要复杂的多。

可能每个人都在描述需求的时候都有自己喜欢的方法，但对于团队来说，更重要的是团结协作，为各种需求确定合适的方法，而不是勉强用一种方法来描述所有的需求。

什么时候即时信息比文件信息更有用

即时交流（比如用电子公告板）无疑是传递需求最快的方式。但这“开始时”的快捷所带来的问题是，它无法保证所有利益相关人同时获得信息，并且有时会产生太多的细节方面的假设。这种情况下，每次需求细节分析都很容易得到与两周前不同的结果，更不用说两个月前了。这会导致在开发、测试、编写用户说明文档和培训材料过程中产生对需求的误解，浪费很多时间。所以虽然开始的时候可能会节省时间，但长远看来，却是在浪费时间。

那么什么时候即时信息比文件信息更有用呢？敏捷方法认为通过文件进行交流更为有效，但从我的实际经验来看，人们经常忽略这一点，引发许多后果。除非可以创造比长期效益更大的短期效益，否则决不能仅依赖于即时信息。

会议记录或电子公告板的截图或许是讨论所有利益相关人的需求的开始。然而，当所有图片或记录消失于数不清的电子邮件中，也没有存储在关联了其它需求细节的核心信息库中时，团队将很确定在整体需求网络中的位置。

维持所有需求与核心信息库的联系

不管团队选用什么方法描述需求，将这些需求细节或文件有条理地储存在核心信息库中并保持相互之间的关联将是需求采集过程成功的关键。你不能仅靠人力去整理数不清的邮件和描述信息。手工维护和更新需求文件之间的关联是很繁琐的工作，很可能导致无法跟上进度。所以无论如何都要让信息库能够根据你的方式自动创建和维护这些关联。比如某阶段的一个用例用到一个显示屏幕，那么信息库要自动将这个显示屏幕与这个阶段关联到一起。

限于篇幅，无法进行更深入的讨论。但最需要注意的几点是：

• 明智地确定开始时所需的细节等级，并做好在最后阶段更改的准备。
• 选择合适的方法描述需求。
• 维持一个关联所有需求文件的、完整的核心信息库。