今天，我阅读了《实例化需求》的7–9章。
第7章主要讲了举例说明的好处和举例说明交叉功能的方法和一些不容易捕获的精确价值的概念。
首先讲了例子的相关问题，例子必须要精确到位，不要在例子中出现是/否等回答，这会使得例子简单化，并且可能带来一种大家已经达成共识的错觉，而事实上不是这样。当我们可以指定一个具体的例子的时候，我们不要使用等价抽象的东西。因为不是具体的东西，不同的人会有不同的理解。例子必须要真实而完整，最好从客户那里获得例子。
例子要应该很容易被人所理解，并可以描述其非功能性需求。
读完这一章，我知道了我们在进行项目开发的时候，我们应该始终使用同一组例子贯穿需求说明、开发阶段以及测试阶段，以确保全体人员对需要交付的内容有同样的理解。
然后例子应该精确、完整、真实以及易于理解。
第8章主要讲了一份好的需求说明是什么样的以及在提炼需求说明的所需要关心的问题。
一份好的需求说明应该是不言自明的，别人直接看就能看懂，从来不需要多一个字去解释它。而一份差的需求说明需要从测试数据去理解业务规则。我们在提炼需求说明的时候需要关心实例要精确可测。因为需求说明是衡量成功与否的客观标准，可以明确地告诉我们何时完成了开发。他必须包含可验证的信息，可用来对系统进行检查。为了满足这些要求，需求说明必须基于精确实际的例子。然后我们需要注意的是脚本不是需求说明。脚本是解释如何测试某个东西。而需求说明是解释系统在做什么。需求说明应该是不言自明的。需求说明时要专注，一个需求说明应该单独描述一件事情：一条业务规则.一个功能，或者过程的一个步骤。专注的需求说明比那种定义多个相关规则的足球说明更容易理解。其次，它们还更易于理解。
通过阅读第8章，我知道了在需求说明时不要直接使用最初的实例要对它们进行提炼，来得出需求说明。在需求说明中要避免使用脚本，避免谈及软件设计。所有重要的用例集，都要先从一个例子开始着手，并增加值得程序员和测试人员特别关心的例子。
第9章主要讲了如何自动化验证而不改变需求说明，如何控制自动化的长期维护成本。首先先阐述了自动化的必要性。自动化对于大型团队来说可以确保我们对是否完成了某样东西拥有公正客观的标准。就长期而言，自动化也很重要，因为它可以让我们频繁的检查更多的用例。然后我们需要事先计划自动化，这样可以是生产力大幅提升。不要拖延自动化工作或将其委派他人。这样会导致大量返工来回折腾。避免根据原有的手动测试脚本进行自动化，手动检验与自动化检验的约束条件是完全不一样的。在手动测试中，准备上下文环境所花的时间往往是主要的瓶颈所在。而在自动化中，时间主要花在了寻找失败的原因上。
通过阅读第九章，我知道了自动化提炼好的需求说明必须尽量减少改动。自动化定义如何进行测试，而需求说明则应该定义要测试什么内容。