用例图用来表达“谁在系统边界内做什么”。一张可用的用例图，需要交代清楚目标场景、参与者清单、动宾结构的用例命名，以及包含、扩展、泛化关系的取舍理由，并为每个用例补上前置条件与主流程。下面以在线报销系统为示例，完整演示从场景到参与者、用例与关系的填写过程，并解释每一步的判断依据，便于迁移到自己的需求场景。
要点总览（TL;DR）
- 用例图的核心是回答“谁在系统边界内做什么”，一份完整示例应包含参与者清单、动宾命名的用例、关系取舍理由和用例说明表。
- 参与者按角色划分而非具体人员；用例粒度以一次完整用户目标为界，只有每次必做且规则独立的子流程才拆成包含关系。
- 扩展关系必须写明触发条件，泛化关系在共性稳定且层级不超过一层时使用，本示例主动放弃泛化。
- 迁移到新场景可按圈定边界、识别角色、目标转用例、判断关系、补齐说明表、对齐验收条件六步推进。
- 用例图适合表达角色与系统交互边界，界面布局、字段级规则和内部架构应交给原型、规则说明与架构文档。
示例目标：这张用例图要回答什么问题
本文使用一个演示情景：某公司计划上线一套在线报销系统，员工提交报销单，主管审批，财务复核并付款，系统对接银行完成打款。该情景为示例设定，用于说明写法，不指向任何真实客户，也不包含实测数据或成效结论。
示例的系统边界定为“在线报销系统”本身：报销单的填写、提交、审批、复核、付款状态跟踪在边界内；银行打款、发票查验等外部服务作为外部系统或外部参与者处理，不展开其内部逻辑。目标读者是需要把业务场景整理成需求条目的产品经理、业务分析人员和开发人员。
这张用例图要回答三个问题：
- 谁：哪些角色会与系统交互，各自的目标是什么。
- 在什么边界内：哪些行为由本系统承担，哪些交给外部系统。
- 做什么：每个角色通过哪些用例达成目标，用例之间的复用与分支关系如何。
选择报销场景做示范，是因为它同时具备多角色协作、审批分支和外部系统对接三类要素，能自然带出参与者划分、包含与扩展关系的判断，又不至于复杂到难以在一篇文章内讲完。
完整示例：在线报销系统的用例图填写稿
参与者清单
| 参与者 | 类型 | 角色说明 | 主要目标 |
|---|---|---|---|
| 员工 | 主要参与者（人） | 发生公务支出并申请报销的人员 | 提交报销单并跟踪进度 |
| 主管 | 主要参与者（人） | 对下属报销单做业务审批的管理者 | 审批或驳回报销单 |
| 财务 | 主要参与者（人） | 负责票据复核与付款执行的财务人员 | 复核单据并触发付款 |
| 银行支付网关 | 次要参与者（外部系统） | 接收付款指令并返回结果的外部服务 | 完成打款并回传状态 |
系统边界内的用例列表
用例统一采用动宾结构命名，粒度以“一次完整的用户目标”为界：
- 提交报销单（员工）
- 查询报销进度（员工）
- 审批报销单（主管）
- 复核报销单（财务）
- 执行付款（财务）
- 上传报销凭证（员工）——被“提交报销单”包含
- 撤回报销单（员工）——在“审批前”条件下扩展“提交报销单”
- 驳回后重新提交（员工）——扩展“提交报销单”
关系使用位置
| 关系类型 | 使用位置 | 说明 |
|---|---|---|
| 关联 | 员工—提交报销单、主管—审批报销单、财务—执行付款等 | 表示参与者与用例之间的交互 |
| 包含（include） | 提交报销单 → 上传报销凭证 | 每次提交都必须上传凭证，属于必选子流程 |
| 扩展（extend） | 撤回报销单 → 提交报销单；驳回后重新提交 → 提交报销单 | 仅在特定条件下触发，属于可选分支 |
| 泛化 | 审批报销单 ← 财务复核（示例中未采用） | 本示例保留独立用例，理由见下一节 |
用例说明表
| 用例 | 参与者 | 前置条件 | 主流程摘要 |
|---|---|---|---|
| 提交报销单 | 员工 | 已登录，报销单处于草稿状态 | 填写费用明细→上传凭证→校验必填项→提交，状态变为“待审批” |
| 上传报销凭证 | 员工 | 报销单已创建 | 选择文件→校验格式与大小→关联到费用明细 |
| 撤回报销单 | 员工 | 报销单处于“待审批”且主管尚未处理 | 确认撤回→状态回到“草稿” |
| 驳回后重新提交 | 员工 | 报销单处于“已驳回” | 查看驳回意见→修改明细→重新提交 |
| 审批报销单 | 主管 | 报销单处于“待审批” | 查看明细与凭证→通过或驳回→记录意见 |
| 复核报销单 | 财务 | 报销单已通过主管审批 | 核对票据合规性→确认金额→标记“待付款” |
| 执行付款 | 财务、银行支付网关 | 报销单处于“待付款” | 生成付款指令→调用银行接口→回写付款结果 |
| 查询报销进度 | 员工 | 已登录 | 按单号或时间筛选→查看当前状态与处理记录 |
图形层面，画布中央用矩形框表示系统边界，框内放置上述用例椭圆；四类参与者置于框外，用连线关联到对应用例；包含与扩展关系用带箭头的虚线标注，并在扩展关系旁注明触发条件。
逐项解释：参与者、用例与关系为什么这样定
参与者按角色划分，不按具体人员
示例中的“主管”是一个角色，对应所有具备审批权限的管理者，而不是某位具体经理。这样划分的好处是：人员调动不影响模型，权限差异可以通过角色属性补充说明。财务同时参与“复核报销单”和“执行付款”，说明同一角色可以关联多个用例；银行支付网关作为外部系统参与“执行付款”，体现次要参与者的用法——它由系统调用，而非主动操作系统。
用例粒度：以一次完整目标为界，共用必选流程才拆包含
“提交报销单”覆盖从填写到提交的完整目标，因此不把“填写费用明细”单独列为用例。而“上传报销凭证”被拆出并用包含关系连接，理由是：凭证上传有独立的校验规则和异常处理，且后续可能被其他用例复用，单独建模便于说明。判断是否使用包含关系，可以问两个问题：该子流程是否每次都被执行？它是否有值得单独描述的规则？两个答案都为“是”时才拆分，否则留在主用例的流程说明里即可。
扩展关系要写清触发条件
“撤回报销单”和“驳回后重新提交”都挂在“提交报销单”上，但触发条件不同：前者要求审批尚未处理，后者要求单据已被驳回。扩展关系的价值在于把低频分支从主流程中分离，让主用例保持清晰；代价是读者需要跳到扩展用例才能看到完整行为。因此扩展用例的说明表必须写明触发条件，示例中放在前置条件一栏，并在图上标注在关系线旁。
泛化关系适用面窄，本示例主动放弃
泛化可以用于参与者，例如抽象出“审批人”作为主管与财务负责人的父角色；也可以用于用例，例如让“财务复核”继承“审批报销单”的公共步骤。本示例没有采用，原因是：主管审批与财务复核的判断依据、权限和后续动作差异明显，强行抽象会让子用例继承到不合适的步骤；参与者只有三个人类角色，抽象层级带来的收益有限。泛化的适用条件是共性行为稳定且子类型确实共享同一套流程，层级建议控制在一层以内。
可迁移规律：换一个业务场景怎么照着写
把上面的示例方法迁移到新场景，可以按以下步骤推进，每一步都有可检查的产物。
- 圈定系统边界：用一句话写出“本系统负责什么”，把外部服务、线下动作明确排除在外。完成标志是边界内外各有一份清单。
- 从场景描述中找角色：逐句阅读业务描述，标出每个动作的执行者，再合并同义角色。检查点：每个参与者都能说出一个明确目标；具体人名、部门名已替换为角色名。
- 为每个角色写目标，再转成用例：一个目标对应一个用例，用动宾结构命名。检查点：用例名读起来是“做什么”，不出现“管理”“处理”这类无法判断完成与否的笼统动词；单个用例能在说明表中用五到八步讲完主流程。
- 按顺序判断关系：先看是否存在每次必做的共用子流程，有则用包含；再看是否存在特定条件下才发生的分支，有则用扩展并写明条件；最后才考虑泛化，且仅当共性稳定、层级不超过一层时使用。
- 补齐用例说明表：为每个用例填写参与者、前置条件、主流程和异常分支。这张表是用例图与需求文档之间的桥梁。
- 与验收条件对齐：把主流程的关键节点转成可验证的验收条件，例如“提交后状态变为待审批”“撤回仅在不处于审批中时可用”。检查点：每条验收条件都能追溯到某个用例的某个步骤。
完成上述步骤后，用例与说明表需要进入需求管理流程，供评审和后续追踪。以ONES为例，可以把每个用例作为一条需求条目承载，将前置条件、主流程和扩展条件写入条目描述，再通过需求评审收集主管、财务等角色的意见，评审通过后与开发任务关联，形成从用例到交付的追踪链路。这样用例图不只是一张图，而是需求条目的组织线索。
适用边界：用例图适合表达什么、不适合表达什么
用例图擅长表达角色与系统之间的交互边界：有哪些角色、各自能触发哪些系统行为、行为之间的复用与分支关系。它帮助团队在需求早期对齐“系统为谁解决什么问题”，也便于向非技术干系人说明范围。
以下内容不适合放进用例图：
- 界面布局与交互细节：页面结构、控件位置交给原型或界面说明。
- 字段级规则：金额上限、必填校验、格式限制等，写在用例说明表或独立的规则说明中。
- 系统内部架构：模块划分、接口设计、数据表结构属于架构文档的范围。
- 跨角色的时序与时限：审批超时提醒、多级流转的时间要求，用业务流程图或状态图表达更清楚。
用例图常与用户故事配合使用：用例图确定范围和角色，用户故事把每个用例拆成可排期的增量，验收条件则约束每个增量的完成标准。需求内容的业务判断——例如某类费用是否允许报销、审批层级如何设置——属于需求分析与澄清的工作，应在用例建模之前或并行完成，用例图只承载澄清后的结论。
常见问题
用例图和用户故事应该先用哪个？
两者可以并行，但顺序取决于团队需要先对齐什么。当角色和系统范围还不清楚时，先用用例图把参与者、边界和主要用例列出来，再为每个用例拆用户故事，增量划分会更稳。当范围已经明确、只差排期时，可以直接写用户故事，用例图作为范围索引保留。无论哪种顺序，验收条件都应能追溯到某个用例的某个步骤。
一个用例的主流程写多少步合适？
示例中建议控制在五到八步，覆盖从触发到目标达成的关键节点。步骤过多通常说明用例粒度过粗，可以把其中每次必做且规则独立的子流程拆成包含用例；步骤过少则可能漏掉状态变化或异常分支。判断标准是：读者只看说明表就能复述完整行为，并据此写出验收条件。
扩展用例的触发条件写在哪里比较清楚？
建议同时写在两处：图上标注在扩展关系线旁，说明表的前置条件一栏写明具体条件。只写在图上，读者容易忽略；只写在表里，看图时无法快速判断分支何时发生。触发条件要写成可判断的事实，例如“单据处于待审批且主管尚未处理”，避免“必要时”“特殊情况下”这类无法验证的表述。
参与者里要不要放外部系统？
需要放，但要区分主次。由系统主动调用、返回结果的外部服务（如示例中的银行支付网关）作为次要参与者放在边界外，用关联线连到对应用例。这样能说明系统依赖哪些外部接口，也便于后续梳理接口约定。外部服务的内部逻辑不展开，边界内只描述本系统发起调用和接收结果的行为。
用例图完成后，怎么和需求评审衔接？
把每个用例连同说明表作为需求条目提交评审，评审时重点确认三件事：参与者是否遗漏、用例粒度是否合适、扩展条件是否覆盖真实分支。评审意见回写到条目描述中，通过后再与开发任务关联。以ONES为例，可以将用例作为需求条目承载前置条件与主流程，通过需求评审收集意见并形成追踪链路；具体字段与流程配置以团队实际使用为准。
