可以有效地检查系统行为与需求说明的描述是否一致。

　　以少的维护成本维持文档的相关性与可靠性。

　　适合短迭代和基于流的过程，这样能为即将开展的工作提供即时足够的信息。

图1-2　对于敏捷项目，构建正确文档的关键因素

　　乍一看，这些目标似乎互相冲突，但有很多团队已经成功地达成了所有目标。在做调研时，我采访了30个团队，他们完成了大约50个项目。我试图找出一些模式与通用做法，并挖掘出这些方式背后的基本原则。这些项目的共同思想，定义了一种构建正确软件的好方法：实例化需求说明。

　　实例化需求说明是一组过程模式，它帮助团队构建正确的软件产品。使用实例化需求说明，团队编写的文档数量恰到好处，在短迭代或基于流的开发中可以有效地协助变更。

　　实例化需求说明的关键过程模式将在下一章介绍。本章我将阐述实例化需求说明的好处。我将使用实例化需求说明的风格来进行阐述，而不是以理论介绍的方式来构建一个案例，我将展示18个真实的例子，它们都来自于那些大大受益于实例化需求说明的团队。

　　在开始之前，我想强调一下，在一个项目中很难孤立地看待某种思想的影响或作用。本文所描述的实践，可以与已经开展的敏捷软件开发实践[例如测试驱动开发（TDD）、持续集成以及使用用户故事做计划等]共同使用，而且可以增强其他实践的效用。当我们转而去看那些有着不同背景的项目时，很多模式浮现了出来。我采访的团队中，有些在实施实例化需求说明前一直使用敏捷过程，而有些团队则是在过渡到敏捷过程的过程中实施了实例化需求说明。大多数团队使用基于迭代的过程，例如Scrum和极限编程，或者是基于流的过程，例如看板。但是有些团队，尽管他们使用了这些实践，但他们的过程以任何标准来看都不是敏捷的过程。然而，他们大多都收获了如下类似的收益。

　　更有效地实施变更。他们拥有活文档——系统功能的可靠信息来源——让他们得以分析潜在变更的影响，同时可以有效地分享知识。

　　更高的产品质量。他们清晰地定义了预期，使得验证过程很有效率。

　　更少的返工。他们在需求说明上协作得更好，并确保所有团队成员对预期达成共识。

　　同一项目不同角色的活动协调得更好。改善协作形成定期的交付流程。

　　在接下来的4个小节中，我们将通过现实世界的例子，近距离地审视这些收益。

　　更有效地实施变更

　　在做调研的过程中，我获得的重要的经验是关于活文档（living documentation）的长期收益的——事实上，我认为这是一个重要信息，本文广泛地涵盖了这部分内容。活文档是系统功能的一个信息源，它与程序代码一样可靠，但更容易使用和理解。活文档帮助团队共同分析变更所带来的影响并讨论潜在的方案。团队还可以为新的需求扩展已有的文档。长此以往，可以使需求说明和实施变更更有效。大多数成功的团队都发现活文档的长期收益是实施实例化需求说明所带来的结果。