这本书书简述了ATDD和BDD的区别。ATDD侧重于让开发目标更加明确。BDD则侧重于制定系统行为的场景。两者对防止功能退化十分重要。但是书中指出，实例化需求仅仅只是防止退化的有效条件。从保证软件质量角度，实例化需求所做的长期投资并不是非常划
算。 书中给出了SongKick公司团队使用tests来指导系统变更实现时节省了50%的时间，这个很惊人。
根据可执行的需求说明创建文档观点：
1.由于可以快速验证，可以低成本的保持被测系统与可执行文档的一致性。
2.文档是增量式的，其它工作可以同时进行。如果编制文档较大，完全没有必要让其他人等候！
以文档为中心的模型所具有的好处： 交付团队应该把测试文档看做是一个单独工件，与交付的系统等同重要。把文档当成关键性交付物是以文档为中心的模型最核心的部分。 增强技术结构或者澄清测试意图不再是技术负债！ 把验收测试的工作交给初级开发人员和测试人员是有问题的！
实例化需求说明的两种模型 BDD，ATDD及其应用场景。 实例化需求说明的创建是循序渐进的。 活文档是交付过程中的重要工件，与代码一样重要。 侧重于建立业务流程文档系统可以帮助你避免长期维护需求说明和测试脚本造成的大部分常见问题。
改变过程，改变团队文化过程的改变可以从以下几点做起：如果已经在进行一个过程变更，那么就通过它实现实例化需求说明的主要思想。将实例化需求说明的思想当做改善产品品质的灵感。为那些没有自动化功能测试的团队，实施功能测试的自动化。对那些自动化测试与开发环节脱离的团队，引入自动化的可执行需求说明。对那些时间测试驱动开发的团队，使用TDD作为下一步的踏脚石。
团队文化的改变从以下几点做起：避免使用“敏捷”术语。从帮助团队提高质量和开发效率的一点一滴做起，每一步都起到实效。获取管理层支持。因为需要显著改变工作方式，不可避免会遇到阻力。把实例化需求当做是比执行验收测试更好的方式来推销。