书简述了ATDD和BDD的区别。ATDD侧重于让开发目标更加明确。BDD则侧重于制定系统行为的场景。两者对防止功能退化十分重要。但是书指出，实例化需求既不是防止退化的充分条件，也不是必要条件，只是有效条件。
并且，在Estimating Software Costs 这本书中作者做了统计：通过回归测试移除缺陷的平均有效率只有23%。 也就是是说，从保证软件质量角度，实例化需求所做的长期投资并不是非常划算。 书中给出了SongKick公司团队使用tests来指导系统变更实现时节省了50%的时间，这个很惊人。
根据可执行的需求说明创建文档 观点： 1.由于可以快速验证，可以低成本的保持被测系统与可执行文档的一致性。 2.文档是增量式的，其它工作可以同时进行。如果编制文档较大，完全没有必要让其他人等候！
以文档为中心的模型所具有的好处： 交付团队应该把测试文档看做是一个单独工件，与交付的系统等同重要。把文档当成关键性交付物是以文档为中心的模型最核心的部分。 增强技术结构或者澄清测试意图不再是技术负债！ 把验收测试的工作交给初级开发人员和测试人员是有问题的！ （注：同意这句话，不过对测试人员比较有杀伤力，要考虑出路鸟，哈哈哈。） 把活文档看成交付过程中的单独工件，团队还可以避免对它投资过度！
实例化需求说明的两种模型 BDD，ATDD及其应用场景。 实例化需求说明的创建是循序渐进的。 活文档是交付过程中的重要工件，与代码一样重要。 侧重于建立业务流程文档系统可以帮助你避免长期维护需求说明和测试脚本造成的大部分常见问题。
改变过程，改变团队文化
过程的改变可以从以下几点做起：如果已经在进行一个过程变更，那么就通过它实现实例化需求说明的主要思想。
将实例化需求说明的思想当做改善产品品质的灵感。
为那些没有自动化功能测试的团队，实施功能测试的自动化。
对那些自动化测试与开发环节脱离的团队，引入自动化的可执行需求说明（作者好想比较推崇Fitnesse）。
对那些时间测试驱动开发的团队，使用TDD作为下一步的踏脚石。
一些tips：
可以把实例化需求作为更大变革中的一部分。打到包里好办事儿（经验看的确如此）。
把重心放在专注于质量提高上，而不是改变上，两者可以相互促进。
如果开发人员和测试人员不紧密合作，这事儿就不好成。
不要一开始就实例化需求，先从把功能测试自动化做起来开始。
在实现功能测试自动化自动化的时候要做好工具选型，工具要适合实例化需求。
团队文化的改变从以下几点做起：
避免使用“敏捷”术语。从帮助团队提高质量和开发效率的一点一滴做起，每一步都起到实效。
获取管理层支持。因为需要显著改变工作方式，不可避免会遇到阻力。
把实例化需求当做是比执行验收测试更好的方式来推销。酒香也怕巷子深。
不要让自动化测试成为最终目标。
不要太拘泥于工具。实例化需求并不以程序员为重心，程序员独立使用一个工具不会取得良好效果。
在迁移过程中，注意需要有人维护遗留脚本。
跟踪那些人在运行/没有运行自动化检查程序。