http://tommwq.tech/blog/2020/11/18/221
范围（scope）是工作的边界，范围之外的东西不需要关注。如果一项工作的边界不断变化，这项工作根本无法完成。这也是很多软件项目失败（大幅超期、超预算）的原因。不同的人对范围的理解有着很大的差异。随着项目的推进，人们对工作范围的认识也会发生变化。为了让需求方和开发团队就范围达成一致，需要对范围进行跟踪和管理。内外列表（in/out list）是一种管理工具。
| 主题 | 内 | 外 |
|---|---|---|
| 以任意形式开发票 | 外 | |
| 产生请求报告 | 内 | |
| 将请求合成一个PO | 内 | |
| 部分发货、延迟发货、错误发货 | 内 | |
| 所有新的系统服务、软件 | 内 | |
| 系统中的任意非软件部分 | 外 | |
| 识别任何可用的已存在软件 | 内 | |
| 申请 | 内 |
内外列表分为3列，第一列是主题，后两列用于标记该主题是否在范围内。
功能范围是系统要提供的服务。识别用例和确定功能范围是两个关系密切的工作。为了很好的完成这些工作，除了内外列表，还有两个有力的工具，它们是执行者-目标列表（actor-goal list）和用例简述（use case briefs）。
| 执行者 | 任务级目标 | 优先级 |
|---|---|---|
| 任何人 | 检测请求 | 1 |
| 授权者 | 改变权限 | 1 |
| 购买者 | 改变卖主契约 | 3 |
| 请求者 | 发起请求 | 1 |
| 改变请求 | 1 |
执行者-目标列表展示了系统支持的所有用户目标，它是需求方和开发团队沟通的出发点。
从执行者-目标列表到详细的用例，中间还有很多工作要做。一开始就编写详细用例通常不是好的做法。因为在捕获需求的最初阶段，很难完整准确的预见所有用例和用例的优先级。更好的做法是首先建立用例简述。
| 执行者 | 目标 | 简述 |
|---|---|---|
| 生产人员 | 修改行政区格 | 生产人员向参考数据库中加入行政区域元数据（行政登记、货币、语言代码、街道类型等）。源数据的相关信息被分类。这是更新数据的一个特殊情况。 |
| 生产人员 | 准备数字绘图源数据 | 生产人员在准备与操作数据库合并时，将外部的数字数据转换成一种标准格式，并对其进行验证和校正。数据被分类并存储到数据库中。 |
| 生产人员和实施工地人员 | 将共享数据的更新事务提交给操作数据库 | 工作人员将堆积的更新事务实施到操作数据库上，非冲突事务被提价给操作数据库。应用程序的上下文与操作数据库是同步的。已提交的事务从应用程序上下文中被删除掉，以保证操作数据库的一致性。冲突事务则通过手工方式或交互方式解决。 |
用例简述给出用例的概括性描述。用例简述和系统使用叙述有点像，但也有着显著的差异。用例简述描述的是抽象的行为，执行者是抽象的。系统使用叙述描绘的是一次具体的行为过程，执行者是具体的。实际上执行者-目标列表和用例简述正是第一章提到的，最粗粒度的两种用例。
为了避免理解上出现偏差，应当指出每个用例的范围。范围分为组织、系统、子系统三个层级。
| 组织（或业务） | 把组织作为一个整体，描述一个组织所提供的业务。组织可以是一个企业或一个部门。 |
| 系统 | 系统的硬件或软件部分。 |
| 构件（或子系统） | 系统中的一个相对独立的部分。 |
为了便于理解，应当为每个层级的范围分配一个具体的名称。假设MyTelCo公司正在设计一个NewApp软件，其中包括一个搜索子系统SearchSubSystem。那么三个层级的范围应当被命名为MyTelCo、NewApp和SearchSubSystem。