Williams认为实例化需求说明是他们取得成功的一个关键因素。除了保证高质量外，实例化需求说明还有助于建立开发人员和测试人员之间的信任。

　　在法国巴黎银行，Sierra项目是另一个很好的例子，可以展现实例化需求说明如何带来高质量的产品。Sierra是一个债券的数据仓库，整合了一些内部系统、评级机构和其他来自外部的信息，并将它们分发给银行内部的各种系统。许多系统和组织使用相同的术语，表达的意思却不尽相同，这导致了许多误解。初两次实现系统的尝试都失败了，据Channing Walton说，团队中的一个开发人员促使了第三次尝试的成功。第三次努力的成功部分归功于实例化需求说明帮助团队处理了复杂性问题，并且确保了团队的共识。终的产品质量令人印象深刻。项目从2005年上线以来一直在运行，Sierra项目的顾问开发人员Andrew Jackman说：“生产环境中没有出现大的问题。”现在Sierra项目中的大多数工作人员都不是项目启动时的那些人，但是质量水平一直都很高。

　　Bekk咨询公司在为一家大型法国银行支行开发租车系统时也取得了类似的成果。Aslak Helles?y曾是那个团队的成员，还是Cucumber——一个支持实例化需求说明的热门自动化工具的创造者，据他说，尽管现在维护这个软件的是一个全新的团队，但他们在系统上线后的两年中却只发现了5个缺陷。

　　Lance Walton曾在一家大型瑞士银行伦敦分行的一个项目中担任过程顾问，这个项目是要开发一个订单管理系统，开始的几次也都失败了。Walton进入这个项目时，大家都认为实现这个系统需要至少和开发团队一样大的支持团队。他的团队使用了实例化需求说明，项目开始9个月后交付了生产系统，内通过了业务验收测试，之后6个月内没有发现任何缺陷。Walton说新的系统不需要额外的支持人员，成本比预期要低，而且团队更早地交付了成品。相比之下，他们旁边的团队需要10倍于开发团队的支持人员。Walton指出：

　　现在团队依然每周发布一次，用户总是对它非常满意。从质量上看，它棒极了。

　　实例化需求说明的技术不仅仅适合于新建项目，同时也适用于改建项目。建立起值得信赖的文档、清理遗留的系统，都需要一定的时间，但是团队很快能看到诸多的好处，并对新的交付充满信心。

　　还有一个不错的例子是伦敦摩根大通的外汇交易系统。Martin Jackson是该项目的自动化测试顾问，他说业务分析员预计项目会推迟，然而事实上，项目提前两个星期交付了。高质量的产品让他们成功地在一个星期内完成了业务验收测试阶段，而不是原先计划的4个星期。Jackson说：

　　我们部署好系统后，系统工作正常。业务人员向董事会报告说这是他们经历过的好的用户验收测试（UAT）。

　　实例化需求说明还使Jackson的团队在项目开发晚期快速实现了“一次重大的技术改动”，提高了计算的精确度。Jackson称：

　　FitNesse套件（活文档）覆盖的所有功能，通过了完整的系统测试和用户验收测试，在生产环境上线时也没有发现任何缺陷。系统测试时发现了几个核心计算组件以外的错误。业务人员之所以觉得用户验收测试非常好，是因为出现计算错误时，我们都非常确定根本问题是在计算代码的上游。使用了FitNesse后，很容易诊断出缺陷的根源，从而可以更加利落快速地交付到生产环境中。

　　科罗拉多州丹佛市的惠好公司有个软件开发团队，他们编写并维护一些工程应用和木制框架的计算引擎。在使用实例化需求说明以前，结构工程师通常不会参与到软件开发过程中，即使团队正在处理一些复杂的科学计算公式和规则。这导致了一些质量问题和延误，由于使用这个引擎的应用程序有好几个，计算过程变得更加复杂。项目的软件质量保证主管Pierre Veragen认为发布前的艰难时期会拖累项目，版本发布出去后很少会没问题。

　　实施实例化需求说明后，团队现在和结构工程师合作制定需求说明，并自动化验证结果。当有变更需求进来时，测试人员和结构工程师一起得出期望的计算结果，并在开发开始前用实例把结果记录在需求说明中。之后批准变更的工程师会编写需求说明和测试。

　　Veragen说新方法的主要好处是他们在做改动时有信心了。到2010年初，他们的活文档系统中已经有超过30 000个检查，而且几年内都没有发现大的缺陷，现在已经停止追踪缺陷了。Veragen指出：

　　我们不需要（缺陷数）这个指标了，因为我们知道它不会再回来了……工程师们喜欢测试先行的方式，并且能直接访问自动化测试。

　　Lance Walton参与过一家大型法国银行伦敦分行的信用风险管理程序的开发。项目刚开始的时候，有外来的顾问帮助团队采用极限编程的实践，但是他们没有采用任何实例化需求说明的做法（虽然极限编程包括客户测试，这个与可执行的需求说明很接近）。6个月后，Walton加入了这个项目，他发现代码质量很低。虽然团队每两个星期都会有交付，但是写出来的代码使验证变得很复杂。开发人员只测试近实现的功能，随着系统的增长，这样的做法不够了。“当有版本发布时，大家都紧张地围坐着，想确保所有功能都能正常运行，并且期望可以在几个小时内发现一些问题。”Walton如此说。在实施实例化需求说明后，产品的质量和人员的信心都有了显著的提高。他补充道：

　　我们十分确信我们发布的版本没有问题。我们高兴地部署完以后出去享受午餐了，不用再担心是否会出问题。

　　与此形成鲜明对比的是，英国贸易者传媒（Trader Media）集团的网站重写项目停止使用实例化需求说明后，却遭遇了质量问题。起初团队协作完成需求说明和自动化验证。在管理层的压力下，他们为了更早更快地交付更多的功能而没有继续下去。测试团队的主管Stuart Taylor说：“我们注意到质量出现了大幅下滑……以前我们（测试人员）很难找到缺陷，而后来我们却发现一个用户故事会有四五个缺陷。”