第二章给出了做到实例化需求的关键过程模式： 从目标中获取范围---->协作定制需求说明---->举例说明----->提炼需求说明----->不需要修改需求说明的自动化验证------->频繁验证----->演化出一个文档系统。
从目标中获取范围：交付团队不应该指望用户直接给出范围或者解决方案，因为客户大部分时候并不具备提供良好需求的专业能力，且团队拥有的项目知识可能也被浪费了。因此需要帮助用户找出真正的目标，并通过协作共同界定项目范围。 分工是这样：用户专注于传达所需功能希望达到的目的，以及他们期望由此带来的价值，团队根据用户给出的信息提出解决方案。 评：仅第一步就很难做成，需求获取也是门大学问，要做好这一步，首先团队中得至少有一个能力超强的需求人员，不过见到的好的需求人员真的很少。
协作制定需求说明：成功的团队不会依赖于某个人独自去收集正确的需求，而是会与商业用户一起制定解决方案。不同背景的人拥有不同的想法，他们会凭借自己的经验解决问题。能够让每个人更大程度的参与到交付活动中去。 评：good idea！让大家八仙过海各显神通显然最棒，不过构建这么一个团队却非容易的事情。
举例说明：自然语言会有歧义，会有上下文相关内容，有些内容则需要有专业知识做背景才能懂，会造成客户与团队、团队内部理解不一致，因此需要某种编程语言来描述需求。 对于成功的团队，不会一上来实现全部需求，而是先确定出那些描述预期功能的关键实例。如果关键实例容易理解和沟通，就可以被有效用作清晰和详细的需求。
评：英文标题是：Illustrating using examples ，感觉翻译成用实例来描述更好一些。 译文有一段读着不顺的地方： 在首次使用用编程语言实现需求的过程中，成功的团队不会等待需求被精确表述，而会举例说明需求。 原文为： Instead of waiting for speciications to be expressed precisely for the irst time in a programming language during implementation, successful teams illustrate speciications using examples.
我觉得更好的翻译应该为：成功的团队不会一开始就将所有需求精确的用某种编程语言表达出来，他们会举例来描述需求。
提炼需求说明：提炼从集体收集到的信息，滤去杂质。为开发和测试创建一个具体的、精确的上下文。以适量的细节来定义目标，以便实现和验收。可以当做交付的验收条件。只有当所有实例在系统中都可以正常工作时，开发才算完成了。
不需要修改需求说明的自动化验证方式：这一段列举了需求文档和自动化脚本不一致带来的问题。指出好的团队会把所有人员都可以理解、访问的自动化实例变成可执行的需求说明。需求和自动化脚本合一，如果需要修改，只改一处就可以了。
评：标题原文是Automating validation without changing speciications 中文标题看着疑惑，查看原文，感觉翻译的有些，自己翻译成：不需要修改说明的自动化验证方式。说实在的，这一段中英文都拗口，作者想表达的无非就是上边标绿的那句话！
频繁验证： 通过频繁检查所有可执行的需求说明，团队能够快速的发现系统和需求说明之间的任何差别。由于可执行的需求说明容易理解，团队可以喝商业用户讨论这些改动，并决定如何处理。他们可以不断的同步系统和可执行的需求说明。
评：这个没设么好说的，持续集成，每一个团队都应该追求的目标。最难的地方其实就在脚本的稳定性和可维护性了。
演化出一个文档系统：不断改进上边这些步骤，一个活文档系统就逐渐成形了。活文档清晰明了，并简单可靠 评：说白了又是一个PDCA
文章给出了一个电商的实例，读下去很顺，貌似有一定可行性，起码是一件能做得下去的工作，不过不知道在其它种类软件是否合适。