用例（Use Case）是对一个系统与外部参与者之间一次完整交互目标的描述，用参与者的目标、触发条件、主流程和异常分支说明系统应当提供什么行为。它属于需求表示方法，回答“谁为了什么目标、在什么条件下、系统要完成哪些交互”，不描述界面布局，也不替代需求内容的判断与澄清。本文按定义、边界、组织方式、相邻概念和示例逐层展开，帮助你在需求分析中准确使用用例。
要点总览（TL;DR）
- 用例是对系统与外部参与者之间一次完整交互目标的描述，核心要素包括参与者、目标、前置条件、主流程、异常分支和后置条件。
- 用例描述系统对外可见的行为，不负责界面绘制和架构设计，也不判断需求内容本身是否正确。
- 用例以参与者目标为起点组织，一个目标对应一个用例，主成功场景只有一条，扩展场景按触发条件展开。
- 用例适合交互复杂、分支多的场景；用户故事适合快速排列优先级；验收条件用于判定条目是否完成，三者可以配合使用。
- 常见误解包括把用例写成界面操作步骤、当成测试用例或塞入多个不相关目标，纠正的关键是回到参与者目标与可观察结果。
用例的准确定义与核心要素
用例描述的是系统为外部参与者提供的一项完整服务。它从一个参与者的目标出发，写明触发这次交互的条件、系统与参与者之间的交互步骤、中途可能出现的偏差，以及交互结束时系统应达到的状态。判断一段文字是不是用例，可以看它是否同时具备明确的参与者和可观察的目标结果；只写“系统应支持查询”这类功能条目，缺少参与者与目标，通常还不构成用例。
一个结构完整的用例通常包含以下要素：
| 要素 | 说明 | 写作要点 |
|---|---|---|
| 用例名称 | 以参与者目标命名，如“提交报销申请” | 用动宾结构，避免写成“报销模块” |
| 参与者 | 与系统交互的人、外部系统或设备 | 区分主要参与者与辅助参与者 |
| 目标 | 参与者希望通过这次交互达成的结果 | 目标应可观察、可验收 |
| 前置条件 | 用例开始前必须成立的状态 | 只写与本次交互直接相关的条件 |
| 主流程 | 顺利达成目标时的交互步骤序列 | 按参与者与系统的交替动作书写 |
| 异常分支 | 主流程中可能出现偏差时的处理路径 | 写明触发条件和系统响应 |
| 后置条件 | 用例成功或失败后系统应处于的状态 | 区分成功结束与放弃结束 |
参与者与目标的关系决定了用例的划分方式。同一个参与者可能有多个目标，每个目标对应一个用例；不同参与者追求同一目标时，可以共享一个用例并注明各自的参与方式。前置条件与后置条件把用例锚定在具体状态上，使读者知道这次交互从何处开始、到何处结束，避免用例写成没有边界的操作说明。
用例覆盖什么、不覆盖什么
用例覆盖的是系统对外可见的行为：参与者发起什么、系统响应什么、在什么条件下走哪条路径、最终达成什么结果。它描述“系统应当提供什么行为”，把实现方式留给设计阶段。因此，用例中写“系统校验发票金额与申请金额是否一致”，比写“调用校验服务并写入校验日志”更合适，后者属于实现细节。
用例不承担三类工作。第一，它不负责界面绘制。页面布局、控件位置、交互视觉属于界面设计，用例只需说明参与者提交了什么信息、系统返回了什么结果。第二，它不承担架构设计。模块划分、接口协议、数据存储方案由架构与详细设计决定，用例只约束外部可观察的行为。第三，它不判断需求内容本身是否正确。某个目标是否值得做、业务规则是否合理，属于需求分析与澄清的范畴，用例是把澄清后的结论表达清楚，而不是替代澄清过程。
明确这条边界有实际好处：用例保持稳定，界面和架构变化时不必重写；评审时可以把“业务目标是否合理”和“行为描述是否完整”分开讨论，减少来回返工。
用例如何组织：从参与者目标到场景分支
用例的组织以参与者目标为起点。先识别参与者，再列出每个参与者希望系统帮助达成的目标，一个目标对应一个用例。目标确定后，把达成目标的最顺利路径写成主成功场景，再逐一考虑“如果某一步条件不成立会怎样”，把偏差写成扩展场景。主成功场景只有一条，扩展场景可以有多条，每条都标明它在主流程的哪一步触发、触发条件是什么、系统如何响应、最终回到主流程还是以其他结果结束。
用例之间还存在两种常见关系。包含关系表示多个用例共用的行为被抽取为独立用例，例如“提交报销申请”和“提交采购申请”都包含“上传附件”，可把上传附件的交互抽成被包含用例。扩展关系表示在特定条件下才插入的行为，例如“提交报销申请”在金额超过阈值时扩展出“触发上级审批”。这两种关系用于消除重复和表达条件性行为，使用时应有明确理由，避免为了结构好看而过度拆分。
组织完成后，可以用一张场景清单检查完整性：主成功场景是否覆盖了目标的完整达成；每个可能失败的步骤是否都有对应的扩展场景；每个扩展场景是否有明确的结束状态。这份清单也是后续编写验收条件和测试场景的输入。
用例与用户故事、验收条件的区别
用例、用户故事和验收条件都是需求表达方式，差别在于粒度、写法和使用场合。用例偏向完整行为描述，适合交互步骤较多、分支复杂、需要跨角色协作确认的场景；用户故事偏向简短的价值陈述，适合迭代中快速排列优先级；验收条件则是对某个需求条目“怎样算完成”的具体判定。三者可以配合使用：用用户故事管理待办与优先级，用用例展开复杂交互，用验收条件锁定每个条目的完成标准。
| 对照维度 | 用例 | 用户故事 | 验收条件 |
|---|---|---|---|
| 表达重点 | 参与者目标与完整交互行为 | 谁需要什么价值、为什么 | 满足什么条件才算完成 |
| 典型粒度 | 一个完整目标，含多条分支 | 一条可在一个迭代内交付的价值 | 若干条可核验的判定语句 |
| 写法 | 结构化：参与者、前置条件、主流程、扩展场景、后置条件 | 简短叙述，常配讨论补充细节 | 条件与预期结果的对应列表 |
| 适用场合 | 交互复杂、分支多、需多方确认行为 | 需求池管理、迭代排期、快速沟通 | 开发完成判定、测试设计输入 |
| 配合方式 | 为复杂故事提供行为细节 | 作为用例的上层待办与优先级载体 | 从用例的主流程与扩展场景中提炼 |
故事地图与用例的关系体现在组织层面。故事地图按用户活动顺序排列故事，帮助团队看到整体流程和缺口；用例则对其中交互复杂的活动做深入描述。两者结合时，故事地图负责“有哪些活动、先后顺序如何”，用例负责“某个活动内部系统与参与者如何交互”。验收条件通常从用例的主成功场景和关键扩展场景中提炼，一条扩展场景往往对应一条异常路径的验收条件。
一个具体用例示例与常见误解
以下为演示情景，用于说明写法，不代表真实项目。
用例名称：提交报销申请
主要参与者：员工
辅助参与者：审批系统
目标：员工完成一次报销申请提交，系统生成待审批记录
前置条件：员工已登录且具备报销申请权限
主成功场景：
1. 员工选择新建报销申请，填写费用类型、金额与发生日期。
2. 员工上传发票附件并提交。
3. 系统校验必填项与附件格式，校验通过。
4. 系统生成待审批记录，通知审批人，向员工返回提交成功结果。
扩展场景：
3a. 必填项缺失：系统提示缺失字段，返回步骤1，员工补充后重新提交。
3b. 附件格式不支持：系统提示支持的格式，保留已填内容，员工重新上传。
3c. 金额超过设定阈值：系统在生成待审批记录时增加上级审批节点，其余流程不变。
后置条件：成功时存在一条待审批的报销记录；放弃提交时系统不保留未提交的草稿以外的数据。
业务规则：金额阈值与审批层级由组织制度确定，用例只引用规则，不重复定义数值。
围绕这个示例，常见的误解有几类。把用例当界面流程，写成“点击按钮A，弹出窗口B”，一旦界面调整用例就失效；纠正方式是只写参与者提交了什么信息、系统返回了什么结果。把用例当测试用例，直接照搬步骤作为测试步骤；测试用例还需要测试数据、预期结果和覆盖策略，用例提供的是行为依据而非测试设计。把用例写成功能清单，一个用例塞进十几个不相关的目标；纠正方式是回到参与者目标，一个目标一个用例。把扩展场景写成异常列表而不标触发点，读者无法判断它在哪一步发生；纠正方式是每条扩展场景标注所对应的主流程步骤编号。
当用例作为需求条目进入管理与评审流程时，需要承载它的工具能保存结构化描述、关联参与者与业务规则，并支持评审意见的流转。ONES 的需求管理可用于承载需求条目并组织评审，把用例的主流程、扩展场景和验收条件作为条目内容维护，便于在评审中逐条确认行为描述是否完整。具体字段与流程形态以实际配置为准。
常见问题
用例和用户故事可以互相替代吗？
两者可以配合使用，但替代关系取决于场景复杂度。用户故事适合在需求池中快速表达价值与优先级，一个迭代内可交付；用例适合展开交互步骤多、分支复杂、需要多方确认行为的需求。实践中常见做法是用用户故事管理待办，对其中交互复杂的条目补充用例描述，再用验收条件锁定完成标准。如果需求本身简单、交互路径单一，只写用户故事加验收条件通常足够；如果涉及多个参与者、多条异常路径，用例能提供更完整的行为依据。
一个用例的主成功场景可以有多条吗？
通常只保留一条主成功场景，即最顺利达成参与者目标的路径。多条“成功路径”往往意味着目标定义不够聚焦，或者把不同触发条件混在了一起。如果确实存在两种都算成功的走法，可以先判断它们是否服务于同一个可观察目标：是同一目标下的不同条件分支，应放入扩展场景并标明触发点；是不同目标，则应拆成两个用例。保持主成功场景唯一，能让读者快速抓住核心行为，也便于后续提炼验收条件。
用例写好后，验收条件应该从哪里提炼？
验收条件通常从用例的主成功场景和关键扩展场景中提炼。主成功场景的每一步可以转化为“完成该步后应可观察到的结果”，扩展场景则对应异常路径的判定条件，例如触发条件成立时系统应给出什么响应、流程回到哪一步或如何结束。提炼时注意验收条件要可核验，写明条件与预期结果的对应关系，避免直接照搬用例步骤作为测试步骤。用例提供行为依据，测试设计还需要补充测试数据与覆盖策略。
用例中的业务规则数值应该写在哪里？
用例适合引用业务规则，把具体数值留给规则本身维护。例如金额阈值、审批层级、时效要求等，如果在用例正文中重复定义，规则调整时容易遗漏更新。更稳妥的做法是在用例中写明“金额超过设定阈值时触发上级审批”，并在业务规则清单或需求条目关联的规则说明中维护具体数值。这样用例保持稳定，规则变化时只需更新一处，评审时也能把行为描述与规则合理性分开讨论。
把用例放进需求管理工具时，需要关注哪些承载方式？
重点看工具能否保存结构化描述并支持评审流转。用例包含参与者、前置条件、主流程、扩展场景、后置条件等多个部分，如果只能存成一段纯文本，后续检索和逐条评审会比较困难。可以关注需求条目是否支持自定义字段或模板来承载这些结构，评审意见能否关联到具体条目并留下处理记录。ONES 的需求管理可用于承载需求条目并组织评审，把用例的主流程、扩展场景和验收条件作为条目内容维护；具体字段与流程形态以实际配置为准。
