用例图设计的核心路径是：先划定系统边界并识别参与者，再从参与者要达成的目标推导用例，用包含、扩展和泛化关系整理复用与分支，最后按场景走查校验。整个过程产出一张结构清晰的用例图和一份可追溯的用例清单，本文按这五步给出具体做法、角色分工、完整示例和交付前检查表。
要点总览（TL;DR）
- 用例图设计按五步推进：划定系统边界、识别参与者、从参与者目标推导用例、整理包含/扩展/泛化关系、按场景走查校验。
- 参与者按人、外部系统、定时触发三类排查，用角色名而非人名命名；用例用动宾结构命名，一个用例对应一个可观察的完整结果。
- 包含用于多个用例共用的必执行片段，扩展用于条件触发的可选分支并须标注条件，泛化只在共性真实存在时使用。
- 业务方提供场景与验收期望，分析人员负责建模，开发与测试参与走查确认可实现与可测性，用例清单与需求条目保持双向追溯。
- 交付前按关联、边界位置、关系正确性、命名、可追溯与可测性逐项核对，全部通过后进入评审。
先定边界与参与者：用例图设计的第一步
用例图回答的是“谁使用系统做什么”，因此第一笔要落在系统边界上。边界框代表本次建模的系统或模块范围，框内放用例，框外放参与者。边界说明要写清三件事：系统名称与版本范围、本次纳入的业务流程、明确排除的相邻系统或流程。边界不画的内容包括内部技术组件、数据库、界面控件，这些属于设计与实现层面，放进用例图会让读者误以为它们是外部可见行为。
参与者指与系统交互、并从交互中获得可观察结果的外部角色。识别时按三类逐一排查：
- 人：直接操作系统或从系统获取结果的岗位角色，如借阅管理员、读者、审批主管。
- 外部系统：与本系统有数据或服务往来的其他系统，如支付网关、身份认证服务、库存系统。
- 定时触发：按时间规则自动发起交互的机制，如每日对账任务、月度报表生成。定时触发是否单列为参与者，取决于它是否代表一个独立的发起方；若只是系统内部调度，可写入用例的触发条件而不单列。
参与者命名使用角色而非具体人名或部门名。“借阅管理员”比“张三”稳定，“财务审核岗”比“财务部小王”更便于长期维护。同一岗位承担多种职责时，按职责拆成多个参与者，避免一个参与者挂满所有用例而失去分析价值。
本步骤的输入是业务范围说明、需求来源清单或现有流程文档；输出是一份边界说明加一张参与者清单，清单中每个参与者注明类型、交互目的和对应的业务来源。完成标志是：团队能对着清单说清“谁在系统外、谁在系统内、各自为什么来”。
从参与者目标识别用例并控制粒度
用例从参与者的目标出发，而不是从功能菜单出发。做法是对每个参与者追问：他来找系统，想完成的那件有结果的事是什么？把答案写成动宾结构，如“借阅图书”“续借图书”“冻结借阅证”“导出月度借阅统计”。动宾结构让用例名自带目标和对象，评审时一眼能判断范围。
粒度判断用一条标准：一个用例对应一个参与者可观察的完整结果。借阅成功、借阅被拒并给出原因，都属于“借阅图书”这个用例的不同场景，写进用例描述的主流程与备选流程，不拆成两个用例。相反，“输入读者编号”“扫描图书条码”“确认借阅”是操作步骤，属于用例内部的流程，不应各立一个用例。用例与功能点、页面、按钮的区别正在于此：功能点和按钮是实现视角的切分，用例是参与者目标视角的切分，一个用例可能跨多个页面，一个页面也可能服务多个用例。
识别时可以先列场景再归并：让业务方按“什么时候、谁、想做什么、期望看到什么结果”描述若干真实场景，分析人员把指向同一目标的场景合并为一个用例，把目标不同的场景拆开。每个用例在清单中记录名称、主参与者、触发条件、前置条件、成功结果和失败结果。这份清单初稿就是后续画图和写用例描述的底稿。
本步骤输入是参与者清单与场景描述，输出是用例清单初稿。完成标志是每个用例都能回答“谁发起、什么条件下发起、完成后看到什么”，并且清单中没有以页面或按钮命名的条目。
包含、扩展与泛化：关系怎么画才不混乱
三类关系各有明确适用条件，判断时先问“这段行为是否在多个用例中重复出现或按条件出现”，再决定用哪种关系。
| 关系 | 适用条件 | 画法方向 | 常见误用 |
|---|---|---|---|
| 包含 | 多个用例共用的、每次执行都必然发生的片段，如“身份校验”“记录操作日志” | 基础用例指向被包含用例 | 把可选分支画成包含，导致读者以为每次都执行 |
| 扩展 | 在基础用例的特定条件下才触发的可选分支，如借阅时“读者有逾期未还”触发“限制借阅” | 扩展用例指向基础用例，并注明扩展条件 | 不写触发条件，扩展点位置含糊 |
| 泛化 | 参与者或用例之间存在共性抽象，如“借阅管理员”与“系统管理员”泛化为“管理员” | 子元素指向父元素 | 为减少线条强行抽象，父子关系在业务上不成立 |
取舍规则可以简化为三条。第一，共用且必执行才用包含；只是偶尔出现的分支用扩展，并在图上或清单中写明条件。第二，能用一段文字在用例描述里说清的分支，不必上升为关系，关系过多会让图难以阅读。第三，泛化只在共性确实存在、且抽象后能减少重复描述时使用，参与者泛化尤其要谨慎，避免把权限差异掩盖在抽象层级里。
关系不能代替需求描述。包含与扩展只表达结构，具体的前置条件、业务规则和异常处理仍要写在用例描述或需求条目中。一张可读的用例图，关系线数量通常明显少于用例数量；如果图上线条密布，优先检查是否把流程步骤误画成了用例。
本步骤输入是用例清单初稿，输出是关系判定规则和修订后的用例图。完成标志是每条关系都能说出“为什么需要它”，且没有循环指向和重复路径。
角色分工与各阶段交付物
用例图不是分析人员独自完成的文档，它需要业务方、分析人员、开发和测试在各自环节提供输入并确认交接物。分工不清时，最常见的结果是用例漏掉异常场景，或者用例无法转化为测试用例。
| 角色 | 主要职责 | 输入 | 输出/交接物 |
|---|---|---|---|
| 业务提出方 | 提供真实业务场景、业务规则与验收期望 | 业务流程说明、历史问题记录 | 场景描述、验收期望清单 |
| 业务分析人员 | 划定边界、识别参与者、建模用例与关系 | 场景描述、需求来源 | 边界说明、参与者清单、用例清单、用例图 |
| 开发人员 | 参与走查，确认用例可实现、边界与外部系统交互清楚 | 用例图与用例清单 | 走查意见、接口与外部系统交互确认 |
| 测试人员 | 参与走查，确认每个用例可设计测试场景 | 用例清单中的触发条件与结果 | 可测性意见、场景覆盖缺口清单 |
交接节奏上，业务方场景描述先于建模，用例清单初稿完成后组织一次开发与测试参与的走查，走查意见回填后再定稿。走查的重点是异常分支和外部系统交互，这两类内容最容易在建模阶段被简化。用例清单与需求条目之间保持双向可追溯：每个用例注明来源需求，每条需求注明覆盖它的用例，后续需求变更时能快速定位受影响的图与描述。
当用例清单需要多人维护并与需求、测试用例保持关联时，可以借助需求管理工具承载。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，并提供业务、产品经理与研发团队三个视角，便于追溯需求与问题；其需求—任务—测试—缺陷的流程闭环，以及用例库、测试计划等功能，适合把用例清单与后续测试场景放在同一条链路上管理。是否需要在 ONES 中直接绘制用例图，属于工具选型时需单独确认的事项，本文不对图形绘制能力作断言。
一个完整示例：图书借阅场景的用例图
以下为演示情景，用于说明前四步方法如何连续落地，不代表真实项目案例。
边界与参与者。系统边界定为“图书借阅管理系统”，纳入借书、还书、续借、借阅证管理、逾期处理；排除采购入库与财务结算。参与者包括：读者（人）、借阅管理员（人）、身份认证服务（外部系统）、每日逾期提醒任务（定时触发）。
用例划分。主要用例为“借阅图书”“归还图书”“续借图书”“管理借阅证”“处理逾期”。次要用例包括“查询借阅记录”“导出借阅统计”，前者服务读者与管理员，后者仅服务管理员。
关系落点。“借阅图书”“续借图书”“管理借阅证”都需要确认操作人身份，抽出被包含用例“身份校验”，三个基础用例指向它。“借阅图书”在读者存在逾期未还时触发“限制借阅”，用扩展关系表达，扩展条件写为“读者存在逾期未还记录”。“读者”与“借阅管理员”在“查询借阅记录”上目标一致，可保留两个参与者分别关联，不必强行泛化；若后续出现更多共享查询目标的角色，再考虑抽象为“查询用户”。
用例清单片段。
| 用例 | 主参与者 | 触发条件 | 成功结果 |
|---|---|---|---|
| 借阅图书 | 借阅管理员 | 读者持有效借阅证到柜台 | 借阅记录生成，库存数量减一 |
| 续借图书 | 读者 | 所借图书未逾期且未达续借上限 | 应还日期延长，记录更新 |
| 处理逾期 | 借阅管理员 | 每日逾期提醒任务生成逾期清单 | 逾期状态标记，通知发出 |
| 限制借阅（扩展） | 借阅管理员 | 读者存在逾期未还记录 | 借阅被拒并提示原因 |
对照这张清单可以检查图的一致性：每个用例都有主参与者，扩展用例写明了条件，被包含用例没有独立参与者。示例中的“身份校验”只出现在关系线上，其具体校验规则写在用例描述里，不在图上展开。
完成检查：用例图交付前的核对项
用例图达到可评审状态，需要逐项核对以下条目。建议在走查会上按表过一遍，未通过项记录责任人和修订期限。
| 核对项 | 判断标准 | 不通过时的处理 |
|---|---|---|
| 用例与参与者关联 | 每个用例至少关联一个参与者，无孤立用例 | 补充发起方，或确认该用例是否属于本次边界 |
| 边界内外位置 | 参与者全部在边界外，用例全部在边界内 | 调整图形位置，检查是否把内部组件误列为参与者 |
| 关系正确性 | 包含为必执行共用片段，扩展均标注条件，泛化有业务共性 | 删除无依据的关系，把可选分支改为扩展或写入描述 |
| 无循环与冗余 | 关系线无循环指向，无重复表达的等价路径 | 合并重复用例，简化关系结构 |
| 命名规范 | 用例为动宾结构，参与者为角色名 | 统一改写命名，避免人名、部门名和页面名 |
| 可追溯 | 每个用例可追溯到需求来源，清单含触发条件与结果 | 补齐来源标注，回填缺失的触发条件与成功/失败结果 |
| 可测性 | 测试人员能据清单设计出主流程与异常场景 | 补充异常分支描述，明确前置条件 |
全部条目通过后，用例图与用例清单即可进入评审。评审后的变更同步更新图、清单和来源追溯关系，保持三者一致，这张图才能在后续需求迭代中持续可用。
常见问题
用例图和功能清单、页面原型之间是什么关系，能不能互相替代？
三者视角不同，不能互相替代。用例图从参与者目标出发，回答“谁使用系统达成什么结果”，一个用例可能跨多个页面；功能清单和页面原型是实现视角的切分，便于排期和开发，但无法直接说明业务目标与异常分支。
可行的衔接方式是：用例图与用例清单确定目标与场景，功能清单承接实现拆分，页面原型承接交互细节。评审时用用例清单反查功能清单，确认每个用例都有对应实现项，每个功能项都能追溯到某个用例或明确的支撑性需求。
用例数量很多时，一张图放不下怎么办？
优先按参与者或业务子域拆成多张图，每张图保持单一主题，例如“借阅业务用例图”“借阅证管理用例图”，并在图名中写清范围。拆分后保留一张总览图，只画参与者与主要用例，细节图通过用例名与总览对应。
拆分前先检查用例粒度是否过细：如果图上大量条目是操作步骤或页面动作，应先归并到参与者目标层面，再判断是否仍需拆图。关系线密集往往也是粒度问题的信号。
扩展关系和备选流程写在用例描述里，怎么选？
判断标准是这段分支是否需要被单独识别、复用或追踪。若分支涉及独立的业务规则、需要单独评审或测试设计，且会在多个基础用例中出现，画成扩展用例更清晰；若只是某个用例内部的少量条件处理，写在用例描述的备选流程中即可。
无论选哪种，扩展条件都必须写明触发前提，例如“读者存在逾期未还记录”。只画关系线不写条件，读者无法判断分支何时发生，图的可评审性会下降。
用例清单在需求变更后怎么维护，才能和图保持一致？
把用例清单作为受控条目管理，每个用例记录来源需求、主参与者、触发条件、成功与失败结果，变更时先改用例清单，再同步图和用例描述。需求条目与用例之间保持双向标注，需求变更时能定位受影响的用例，用例调整时能回溯来源。
当清单需要多人维护并与需求、测试场景关联时，可以借助需求管理工具承载。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，并提供业务、产品经理与研发团队三个视角，便于追溯需求与问题；其需求—任务—测试—缺陷的流程闭环，以及用例库、测试计划等功能，适合把用例清单与后续测试场景放在同一条链路上管理。是否在 ONES 中直接绘制用例图，属于选型时需单独确认的事项。
定时任务一定要画成参与者吗？
取决于它是否代表独立的发起方。若定时机制按业务规则主动发起一次交互，并产生参与者可观察的结果，例如每日生成逾期清单并通知管理员，单列为参与者能让触发来源清晰；若只是系统内部的调度细节，写入用例的触发条件即可，不必在图上单列。
判断时问一句：业务方在讨论场景时会不会提到“每天几点系统自动做这件事”。会提到就单列，不会提到就放进触发条件。
