1、范围（scope）一词用来描述项目开发人员负责的设计工作的边界，以便与应由其他人负责的设计工作或已经完成的设计工作相区别

2、与被讨论系统的功能范围和设计范围相关的主题都可以使用“内/外”列表，内/外表示在项目内还是在项目外。

表3-1“内/外”列表

3、功能范围是指系统要提供的服务，她最终应被用例所捕获。

4、执行者－目标列表列举了系统支持的所有用户目标，展示了系统功能方面的内容。

表3-2 执行者－目标列表示例

5、用例简述是对用例行为所作的一个包含2～6句话的描述，它仅提及了最重要的活动和失败情况。可以将用例简述做成一个表格，或作为执行者－目标列表的扩充，或在初稿中直接将其作为用例体的一部分。

6、设计范围是系统的区域，是开发人员负责设计和讨论的系统的集合，包括硬件系统和软件系统；它是集合的边界。

7、功能范围由执行者－目标列表和用例就可以充分的进行定义，而设计范围则是每个用例中都关心的一个主题，通常只写“范围”（scope）一词时，指的是“设计范围”（design scope）。

8、业务用例把企业作为其（设计）范围，书上用建筑房屋作为其图标；系统用例将计算机系统作为其范围，书上用一个盒子作为其图标；构件用例是关于被设计系统的子系统或构件的描述，书上用一个螺钉作为其图标。

9、用例总是在一个设计范围内进行编写。通常，可以找到一个更广的设计范围，而主执行者仍然处于范围之外。如果不断扩大该范围，可以找到一个临界点，一旦越过这个临界点，主执行者就会被包含在范围之内。这个临界点就是最外层范围（outermost scope）。最外层范围有时是企业，有时是部门，有时仅仅是计算机。

10、提倡编写最外层用例是因为，编写这样的用例花费的时间很少，并能为用例集提供极好的语境信息。最外层用例显示了系统最终如何使其最外部用户收益；同时还为浏览系统的行为提供了一个内容列表。

这章的内容虽然不长，但值得摘抄的地方很多，即使如此，我还是没有完全弄明白里面的一些问题，这一章我的理解是，首先要弄清楚功能范围，这样可以把一些不是项目负责的功能剔除掉，然后对项目内的每条功能建两个用例，一个是针对系统被设计系统，另一个是针对比被设计系统更广的范围，但这样做是什么目的，我还是不太明白，觉得是为了控制范围，不会因为设计范围太大而导致引入更多的功能，看来要用书上的方法踏踏实实的写几个用例才能体会其中奥妙。