Gojko：故事卡本意并不会长期保存。在做短期的优先级排列和计划时它们非常有用。但是当一个故事完成六个月后，如果你需要了解系统时，这些卡片却不会有太大的帮助。而传统的文档又很容易过期。把程序源代码当作唯一可靠的资源用以了解系统的功能，会导致信息瓶颈和黑洞，从长期来看，这正是编写良好的实例化需求的作用。由于这些需求的验证通过验收测试自动化了，并经常被执行，所以我们可以相信系统的行为符合这些测试所指定的功能。或者从另外一个角度来讲，这些文档实时追踪着系统的功能。一个编写良好的实例化需求，应该简单易懂，并容易获取，可以帮助我们消除那些信息瓶颈。
我曾工作过的许多大公司，因为没有一个可靠的文档系统，不仅让软件交付团队面临着很大的问题，而且更重要的是它在商业上也会造成很大程度的损失。通过创建和维护一份可靠和可维护的业务流程文档，活文档可以为IT团队带来额外的商业价值。
InfoQ：你对于那些想要实施这种方法的团队有什么建议吗，为了确保他们已经准备好去做这些改变，他们要做些什么呢？
Gojko：所有的事情都是有前后关系的。每个团队都需要知道他们的问题是什么，然后利用书上的想法作为启发来解决这些问题。一个好的对策就是让整个团队能够对他们在交付高质量产品所面临的首要问题上达到一致，并致力去解决它，然后接着解决下一个问题。这是个非常有效的改进策略，因为它提出了一个共同的目标，可以减少抵制心理，并给管理层提供了一个令人信服的理由去支持改变（因为团队正在解决他们的首要问题）。
InfoQ：为了采用这种方法，团队和组织需要做出的最大改变是什么？
Gojko：再强调下，这是有前后关系的。通常情况下最大的改变就是文化，从涂鸦墙上什么任务应该要抛弃掉、什么责任需要被转移的传统方式转变到一个更具协作性和整体性的软件交付方式上。实例化需求需要团队不同角色间紧密的合作，并共同支持团队向一个更为协作的环境转变。
InfoQ：你见过的最常见的错误是什么，团队应该怎样去避免他们呢？
Gojko：把精力放在一个特定工具上是很多人都会犯的一个严重错误，因为这并不会提高协作能力，反而会造成更多的问题。还有一个常见的问题就是实施这一过程时单纯从测试角度去考虑问题，工件变成了过度饱和的数据和测试用例的组合爆炸，这让实例化需求失去了作为沟通工具的作用。第三个常见的问题就是需求说明的错误设计，利用技术语言或脚本去描述某个功能是怎么被测试的，而不是去描述系统应该怎么工作。
这会造成后期维护的困难。
为了避免这些问题，团队必须专注于价值、协作和改进沟通，发展出一套通用的语言，并在所有工件中使用一致。
InfoQ：你能给团队什么建议来帮助他们维持这种改变，并保持活文档的“活性”呢？
Gojko：团队应该意识到随着知识领域的发展和商业机会的改变，项目语言也会随着时间的推移而演进。这会影响实例化需求以及活文档系统组织和解释事情的方式。为了获得长期的受益，团队必须保持活文档系统的一致性。这是一个更为广泛的话题，包括领域驱动设计、统一语言以及如何一致地使用它去支持对称的改变：一个业务功能上的小改动将通过软件和文档中的小变动来体现。如果我们让这些模式慢慢分开，那么软件很快就会变为古董，到了某一时刻，很多人就会放弃更改而决定重写。但是如果这些模式能够协调一致，我们完全可以避免这种遗留陷阱。因此，活文档系统的确可以更早地提醒我们这类问题，我认为团队应该要明白保持文档活性的同时可以确保相关软件的活性。
InfoQ：那些采用实例化需求的团队和组织是如何从中受益的呢？
Gojko：大体上可分为四种好处：更高的产品质量、迭代时团队在分析/开发/测试等活动上可以保持更好的一致性、 更有效地实现变更、大幅降低返工。这些都意味着可以更快地推向市场，并具备更好的质量。比如说：有一个团队尽管每两个礼拜发布一次，但产品多年来都没出现严重的缺陷；有一个团队成功地改进了一个可怕的遗留系统，他们停用了缺陷跟踪系统；某个团队将产品推向市场的时间从6个月降到平均4天。重要的是这个过程并不是一件错综复杂的事情，也不是什么黑色艺术，它是完全可以达到的，只要大家付出努力，并通过正确的方式去实践，它的成功就是可以复制的。
Blogger Craig Smith是这本书的早期评论者，他在博客中写道：
总体上来说，任何团队（尤其是敏捷团队），只要他们尝试去平衡或寻找一种适当的关于需求和测试的方法，那么他们就应该阅读这本书。针对在敏捷团队中如何处理测试和需求的问题，它很好地平衡了各种模式，提供了真实的案例学习。在我必读的图书清单中，该书位于测试类书籍的前5名，敏捷类的前10名。现在我终于明白如何正确命名内嵌在高速公路上的猫眼了！
他从书中提取了如下要点：
以下是我从书中总结的要点：
这是人的问题，而不是技术问题。
正确地构建一个产品和构建一个正确的产品是两件完全不同的事情，我们要确保他们都成功。
活文档，从根本上来讲，如同程序源代码一样，是关于系统功能的另一个可靠的信息源，只是更容易被获取，更容易被理解。
让产品待办事项更容易地管理。
只有当团队已经准备好实现某事项时才开始着手实例化需求，比如迭代开始的时候。
从目标获取范围，交流商业意图，然后团队提出解决方案。
冗长的描述会过度地约束系统，与其描述什么是必须要做的，不如描述为什么需要去做什么。
传统的验证方式有这样的问题：如果我们在业务需求和技术自动化之间转化时丢失了某些信息，那么我们就冒着引入问题的危险。