这本书给出了做到实例化需求的关键过程模式： 从目标中获取范围——协作定制需求说明——举例说明——提炼需求说明——不需要修改需求说明的自动化验证——频繁验证——演化出一个文档系统。
从目标中获取范围：交付团队不应该指望用户直接给出范围或者解决方案，因为客户大部分时候并不具备提供良好需求的专业能力，且团队拥有的项目知识可能也被浪费了。因此需要帮助用户找出真正的目标，并通过协作共同界定项目范围。 分工是这样：用户提供需要的
功能以及开发软件的目的，团队根据用户给出的信息提出解决方案。
协作制定需求说明：成功的团队不会依赖于某个人独自去收集正确的需求，而是会与商业用户一起制定解决方案。不同背景的人拥有不同的想法，他们会凭借自己的经验解决问题。能够让每个人更大程度的参与到交付活动中去。
举例说明：自然语言会有歧义，会有上下文相关内容，有些内容则需要有专业知识做背景才能懂，会造成客户与团队、团队内部理解不一致，因此需要某种编程语言来描述需求。 对于成功的团队，不会一上来实现全部需求，而是先确定出那些描述预期功能的关键实例。如
果关键实例容易理解和沟通，就可以被有效用作清晰和详细的需求。成功的团队不会一开始就将所有需求精确的用某种编程语言表达出来，他们会举例来描述需求。
提炼需求说明：提炼从集体收集到的信息，滤去杂质。为开发和测试创建一个具体的、精确的上下文。以适量的细节来定义目标，以便实现和验收。可以当做交付的验收条件。只有当所有实例在系统中都可以正常工作时，开发才算完成了。
频繁验证： 通过频繁检查所有可执行的需求说明，团队能够快速的发现系统和需求说明之间的任何差别。由于可执行的需求说明容易理解，团队可以与商业用户讨论这些改动，并决定如何处理。他们可以不断的同步系统和可执行的需求说明。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
