2、与被讨论系统的功能范围和设计范围相关的主题都可以使用“内/外”列表，内/外表示在项目内还是在项目外。
|
主 题 |
内 |
外 |
|
以任意形式开发票 |
|
外 |
|
产生请求报告（请求可能由卖主、分部或人发起） |
内 |
|
|
将请求合并成一个PO |
内 |
|
|
部分发货，延迟发货，错误发货 |
内 |
|
|
所有新的系统服务，软件 |
内 |
|
|
系统中的任何非软件部分 |
|
外 |
|
识别任何可用的已存在软件 |
内 |
|
|
申请 |
内 |
|
表3-1“内/外”列表
3、功能范围是指系统要提供的服务，她最终应被用例所捕获。
4、执行者－目标列表列举了系统支持的所有用户目标，展示了系统功能方面的内容。
|
执行者 |
任务级目标 |
优先级 |
|
任何人 |
检查请求 |
1 |
|
授权者 |
改变权限 |
2 |
|
购买者 |
改变卖主契约 |
3 |
|
请求者 |
发起请求 |
1 |
|
|
改变请求 |
1 |
|
…… |
…… |
…… |
表3-2 执行者－目标列表示例
5、用例简述是对用例行为所作的一个包含2～6句话的描述，它仅提及了最重要的活动和失败情况。可以将用例简述做成一个表格，或作为执行者－目标列表的扩充，或在初稿中直接将其作为用例体的一部分。
6、设计范围是系统的区域，是开发人员负责设计和讨论的系统的集合，包括硬件系统和软件系统；它是集合的边界。
7、功能范围由执行者－目标列表和用例就可以充分的进行定义，而设计范围则是每个用例中都关心的一个主题，通常只写“范围”（scope）一词时，指的是“设计范围”（design scope）。
8、业务用例把企业作为其（设计）范围，书上用建筑房屋作为其图标；系统用例将计算机系统作为其范围，书上用一个盒子作为其图标；构件用例是关于被设计系统的子系统或构件的描述，书上用一个螺钉作为其图标。
9、用例总是在一个设计范围内进行编写。通常，可以找到一个更广的设计范围，而主执行者仍然处于范围之外。如果不断扩大该范围，可以找到一个临界点，一旦越过这个临界点，主执行者就会被包含在范围之内。这个临界点就是最外层范围（outermost scope）。最外层范围有时是企业，有时是部门，有时仅仅是计算机。
10、提倡编写最外层用例是因为，编写这样的用例花费的时间很少，并能为用例集提供极好的语境信息。最外层用例显示了系统最终如何使其最外部用户收益；同时还为浏览系统的行为提供了一个内容列表。
这章的内容虽然不长，但值得摘抄的地方很多，即使如此，我还是没有完全弄明白里面的一些问题，这一章我的理解是，首先要弄清楚功能范围，这样可以把一些不是项目负责的功能剔除掉，然后对项目内的每条功能建两个用例，一个是针对系统被设计系统，另一个是针对比被设计系统更广的范围，但这样做是什么目的，我还是不太明白，觉得是为了控制范围，不会因为设计范围太大而导致引入更多的功能，看来要用书上的方法踏踏实实的写几个用例才能体会其中奥妙。
