总部设在美国西得梅因市的爱荷华州助学贷款流动资产管理公司（Iowa Student Loan Liquidity Corporation，下文简称Iowa Student Loan），在2009年进行了一项相当重要的商业模式变更。过去一年，金融市场动荡使得贷款方几乎无法为私人学生贷款找到资金来源，因此，许多贷款方被迫放弃私人学生贷款市场或改变自己的商业模式。该公司适应了当时的市场。它从银行和其他金融机构募集资金来支助私人助学贷款，而不是使用债券收益。

　　Tim Andersen是一位软件分析师，同时也是一名开发人员，他说为了有效地适应市场，他们不得不“有声有色地进行系统核心大检修”。在开发软件时，他们的团队把活文档作为一项主要机制来编写业务需求文档。活文档系统让他们可以探悉新需求所带来的影响、帮助他们确定所需的变更，而且可以确保系统的其余部分仍旧正常工作。他们当时只花了一个月时间对系统实施了根本性的变更并将其发布到了生产环境，活文档系统是做这项变更的根本。Andersen说：

任何未进行这些测试（活文档）的系统，都必将导致开发停顿和重写。

　　在加拿大魁北克省的蒙特利尔市，Pyxis技术公司的Talia项目团队也有类似的经验。Talia是企业系统的一个虚拟助理，它是一个拥有复杂规则、能与员工交流的聊天机器人。从初开始，Talia团队使用实例化需求说明来构建一个活文档系统。一年之后，他们不得不从头开始编写虚拟代理引擎的核心——而此时，正是在活文档方面的投资大显成效的时候。Talia的产品总监Andre? Brissette是这样说的：

如果没有活文档，任何重大重构都无疑是自寻死路。

　　他们的活文档系统使得团队在变更完成时可以自信地说，新系统具有和老系统一样的功能。该活文档系统还能帮助Brissette管理并追踪项目的进度。

　　总部位于伦敦的现场音乐消费性网站Songkick的团队在重新开发网站活动摘要时，使用了一个活文档系统来协助变更。他们意识到目前的摘要系统无法扩展到所需的容量，活文档在重新构建摘要系统时提供了有力的支持。Phil Cownas是Songkick的CTO，据他估计，因为拥有了活文档系统，他们的团队在实施变更时节省了至少50％的时间。据Cowans所述：

　　因为我们拥有让人满意的覆盖率，并且我们确实信任这些（在活文档系统里的）测试，所以我们很有信心可以快速地对基础结构进行大的变更。我们知道，系统功能不会改变，即使变了，测试也会发现。

　　ePlan Services是一个养老金服务机构，位于科罗拉多州的丹佛市，它的开发团队从2003年开始已经使用了实例化需求说明。他们构建并维护一个金融服务系统，该系统涉及众多的项目干系人、复杂的业务逻辑以及复杂的监管需求。在项目开始三年之后，其中一位经理搬去了印度，而对于系统遗留部分，有些内容是只有他才掌握的。根据ePlan Services的测试人员及Agile Testing: A Practical Guide for Testers and Teams一书作者Lisa Crispin的描述，当时，团队努力地学习那位经理所拥有的知识并将其构建成活文档。活文档系统帮助他们获得了业务流程的专业知识，并立即提供给所有的团队成员。他们借此消除了知识传递的瓶颈，可以有效地支持并扩展系统。

　　在比利时Oostkamp的IHC集团，病人管理中心项目组实施了一个活文档系统，并取得了类似的结果。该项目开始时重写了一个大型机系统，它是从2000年开始的，目前还在进行中。Pascal Mestdach是该项目的方案架构师，他说团队从中受益匪浅：

　　当时遗留系统中的一部分功能只有少数几个人了解，而现在情况已经好很多了，那是因为团队拥有一套针对那部分功能的、不停增长的测试套件（活文档），它描述了该遗留系统的功能。当专家休假时，还可以从活文档系统中寻找问题的答案。对其他开发人员来说，可以更清晰地了解软件中某部分的功能。并且还是测试过的。

　　这些例子阐述了活文档系统如何帮助交付团队分享知识并应付人员变动。它还使得业务可以更有效地响应市场变化。我将在第3章里对此做更具体的说明。

　　更高的产品质量

　　实例化需求说明可以改善交付团队成员之间的协作，促进商业用户更好地参与，并为交付提供清晰客观的目标——大幅提高产品质量。

　　有两个突出的案例，分别来自Wes Williams[来自世博控股（Sabre Holdings）的敏捷教练]以及Andrew Jackman[为法国巴黎银行（BNP Paribas）的一个项目工作的顾问开发人员]，他们将描述之前失败过多次的项目如何通过实例化需求说明走向成功。本文中描述的方法帮助他们的团队克服了业务领域的复杂性，之前这种复杂性是很难处理的。同时还帮助他们确保了交付的高质量。

　　在世博控股，Wes Williams工作的项目是一个为期两年的航班订票项目，团队分布在全球各地，流程又是数据驱动的，这使得项目十分复杂。项目有3个团队，30名开发人员，分布于两个洲。据Williams说，系统头两次构建都失败了，但是第三次使用实例化需求说明后成功了。Williams说：

　　我们在一家大客户（一家大型航空公司）上线时缺陷非常少，在（业务验收）测试阶段只有1个缺陷是比较严重的，是故障切换（fail-over）相关的问题。