用例（Use Case）描述某个参与者为达成一个目标，与系统之间进行的一组有先后次序的交互。它站在系统外部使用者的视角，说明系统应当提供哪些可观察的行为结果，不涉及系统内部如何实现。本文围绕用例的定义、边界、组成形式与相邻概念展开，并用一个图书借阅示例说明写法与常见误解。
要点总览（TL;DR）
- 用例（Use Case）是对某个参与者为达成一个目标、与系统之间一组有序交互的描述，站在系统外部视角说明系统应提供哪些可观察的行为结果。
- 用例包含参与者、目标、前置条件、主流程、备选流程和后置条件；系统架构、数据库设计、界面布局与算法实现不属于用例内容。
- 用例通常以用例图和用例规约两种形式表达：图给出参与者、用例、系统边界与关联关系，规约写清主成功场景、扩展流程与异常处理。
- 用例与用户故事、功能列表、业务流程、场景各有分工：用例强调交互序列与条件分支，场景是用例中的一条具体路径。
- 图书借阅示例说明：一个参与者目标对应一个用例，步骤写意图与系统响应，避免把界面操作、功能条目或过细动作当成用例。
用例的准确定义：它描述的是什么
用例的英文是 Use Case，中文也译作“用况”。在需求分析语境下，可以给出如下定义：用例是对“某个参与者为了达成一个目标，与系统之间进行的一组有先后次序的交互”的描述。这个定义包含三个关键限定：有明确的参与者、有可陈述的目标、有可观察的交互序列。缺少任何一项，写出来的内容往往就不再是用例。
用一句话解释：用例回答的是“谁为了让系统帮他做成什么事，会和系统来回发生哪些交互，最后得到什么结果”。
理解这个定义，需要把握它的视角。用例站在系统边界之外，以使用者的目标为起点，描述系统对外表现出来的行为。它关心的是“系统应当对外提供什么”，而不是“系统内部由哪些模块、类和表来实现”。同一个用例可以由完全不同的技术方案支撑，这正说明用例属于需求层面的描述。
用例描述的是交互序列，这一点常被忽略。一条功能点式的表述，例如“系统支持导出报表”，只说明了一个能力条目；用例则会说明参与者何时发起、系统如何响应、中间经过哪些判断、成功与失败分别以什么状态结束。交互序列让用例能够承载条件分支和异常情况，也让后续的测试设计有了可依据的路径。
用例与需求分析的关系体现在转化动作上。需求分析要把业务目标转成系统应承担的行为：业务方说“希望读者能自助借书”，分析人员需要判断系统在这件事里承担哪些职责、与哪些外部角色交互、在什么条件下给出什么结果，这些判断沉淀下来就是用例。用例因此是业务语言与系统行为之间的中间层，既贴近业务目标，又足够具体到可以验收。
用例包括什么、不包括什么
用例的边界可以用一句话概括：凡是描述“参与者与系统之间可观察交互”的内容属于用例，凡是描述“系统内部如何构造”的内容不属于用例。这条界线决定了用例该写多深，也决定了它与其他需求文档的分工。
用例通常包含以下要素：
- 参与者：与系统交互以达成目标的人、外部系统或定时触发方，位于系统边界之外。
- 目标：参与者希望通过这次交互获得的可观察结果，一个参与者目标对应一个用例。
- 前置条件：用例开始前必须成立、且系统可以检验的状态，例如“读者已登录且账户状态正常”。
- 主流程：在一切顺利的情况下，参与者与系统之间按顺序发生的交互步骤。
- 备选流程：主流程中某个判断出现其他结果时，系统转而执行的交互路径，包括可恢复的异常。
- 后置条件：用例结束后系统应处于的状态，区分成功结束与失败结束。
用例不包括以下内容：
- 系统架构、分层方案、服务划分等技术设计决策。
- 数据库表结构、字段类型、索引与存储方案。
- 界面布局、控件选择、按钮位置与视觉样式。
- 具体的算法实现与代码结构。
需要区分的是，业务规则本身是否成立，属于需求分析与澄清的工作。例如“逾期未还的读者能否继续借书”“同一读者最多可借几本”，这些规则的确认要在需求澄清阶段与业务方谈清楚；用例负责在规则确定后，把它表达为可观察的判断分支和系统响应。把规则判断和用例书写混在一起，容易让用例变成规则讨论记录，失去行为描述的清晰度。
粒度控制是用例写作中最实际的问题。合理的做法是一个参与者目标对应一个用例：读者借书是一个用例，管理员上架新书是另一个用例。如果把“点击借阅按钮”“填写借阅表单”这类界面动作拆成独立用例，粒度就过细，用例会退化为操作说明；反过来，把“图书馆全部日常运营”写成一个用例，又过于笼统，无法指导开发与测试。
用例由哪些部分组成：用例图与用例规约
用例通常以两种形式表达：用例图给出全局结构和关系，用例规约给出单个用例的完整细节。两者配合使用，图负责“有哪些、谁和谁相关”，规约负责“具体怎么发生”。
用例图的组成要素
| 要素 | 作用 | 常见写法 |
|---|---|---|
| 参与者 | 标识系统边界外的交互方 | 人形符号，标注角色名称 |
| 用例 | 标识一个参与者目标 | 椭圆，以动宾短语命名 |
| 系统边界 | 划定哪些行为由本系统承担 | 矩形框，框内为用例 |
| 关联关系 | 表示参与者与用例之间的交互 | 连接参与者与用例的实线 |
用例规约的字段与填写顺序
用例规约是把一个用例写清楚的模板。字段不必求多，但顺序应稳定，便于评审和后续追踪。建议按以下顺序填写：
| 字段 | 作用 |
|---|---|
| 用例名称与编号 | 唯一标识，名称用动宾短语表达目标 |
| 参与者 | 主要参与者与辅助参与者 |
| 目标 | 一句话说明参与者想达成什么 |
| 前置条件 | 开始前必须成立且可检验的状态 |
| 主成功场景 | 顺利情况下的编号步骤序列 |
| 扩展或备选流程 | 按触发条件列出偏离主流程的路径 |
| 异常处理 | 系统无法完成目标时的响应与最终状态 |
| 后置条件 | 成功与失败两种结束状态 |
用例之间的关系有三类，使用场合各不相同：
- 包含：多个用例共有的一段交互被抽取为独立用例，被包含的用例是完整流程中的必要片段，调用方每次执行都会经过它。
- 扩展：在特定条件下才追加到基础用例上的行为，条件不成立时基础用例照常完成，适合描述可选或例外分支。
- 泛化：参与者或用例之间的特化关系，子用例继承父用例的行为并可增加或改写步骤，适合存在明显共性又各有差异的场景。
这三类关系容易过度使用。关系画得越多，图越难读，规约也越难维护。实践中可以先按目标平铺用例，只有当重复片段确实稳定、或条件分支确实独立成块时，再引入包含与扩展。
用例规约作为需求文档，需要在团队内评审、定稿并被开发与测试持续引用。在 ONES 中，可以把规约作为需求文档承载，与对应的需求工作项关联，评审意见留在文档上，后续开发任务和测试用例再链接回同一工作项，形成从规约到交付的追踪链条。
用例与用户故事、功能列表、业务流程的区别
这四个概念常在同一个项目里同时出现，混淆会导致文档重复或遗漏。区分的关键在于各自回答的问题不同。
| 概念 | 回答的问题 | 典型形式 | 适用场合 |
|---|---|---|---|
| 用例 | 参与者为达成目标，与系统发生哪些有序交互 | 用例图加用例规约 | 交互复杂、分支多、需要完整行为描述时 |
| 用户故事 | 谁想要什么价值，为什么 | 简短的价值陈述加验收条件 | 迭代中快速表达需求、便于排优先级时 |
| 功能列表 | 系统提供哪些功能条目 | 条目化清单 | 范围盘点、工作量粗估时 |
| 业务流程 | 跨角色的端到端业务如何流转 | 流程图加角色泳道 | 梳理组织级流程、识别系统介入点时 |
用例与用户故事的区别在于详略与结构。用户故事用一两句话表达价值，细节留到开发前再补；用例则把交互序列、条件和结果写完整，适合需要提前对齐行为的场景。两者可以配合：用故事管理优先级，用用例承载复杂故事的细节。
用例与功能列表的区别在于是否描述行为目标。功能列表是条目罗列，容易让人知道“有什么”却不知道“怎么用、什么条件下可用”；用例以目标为线索把相关行为组织起来，天然带有条件和结果。
用例与业务流程的区别在于系统边界。业务流程跨越多个角色和多个系统，描述业务在组织内如何流转；用例只描述系统边界内、某个参与者与系统之间的交互。业务流程梳理清楚后，可以据此识别系统应承担哪些用例。
用例与场景的关系是包含关系。一个用例包含多条场景：主成功场景是一条顺利路径，每个备选流程和异常处理各是一条具体路径。场景是用例的一条具体走法，用例是这些走法的集合。
一个具体例子：图书借阅用例怎么写
下面以图书馆系统中“读者借书”为例，展示从目标到规约的写法。示例为演示情景，用于说明结构，不代表任何真实系统。
用例规约示例
- 用例名称与编号：借阅图书，UC-01。
- 参与者：主要参与者为读者，辅助参与者为馆藏系统。
- 目标：读者成功借出所选图书，系统记录借阅关系。
- 前置条件：读者已登录且账户状态正常；所选图书在馆且状态为可借。
- 主成功场景：
- 读者选择要借阅的图书并提交借阅请求。
- 系统校验读者账户状态与借阅额度。
- 系统校验图书状态为可借。
- 系统登记借阅记录，更新图书状态为已借出。
- 系统向读者显示借阅成功及应还日期。
- 备选流程：
- 2a 读者有逾期未还图书：系统提示存在逾期记录并拒绝本次借阅，用例结束于失败状态。
- 2b 读者借阅数量已达上限：系统提示额度已满并拒绝本次借阅。
- 3a 图书已被他人借出或状态不可借：系统提示该书不可借，建议读者选择其他图书，流程返回步骤1。
- 异常处理：登记借阅记录时馆藏系统无响应，系统提示稍后重试，不生成借阅记录，图书状态保持不变。
- 后置条件：成功时存在一条借阅记录且图书状态为已借出；失败时借阅记录与图书状态均不变。
常见误解与纠正
第一种误解是把界面操作步骤当用例。例如把“点击借阅按钮”“打开借阅弹窗”写成主流程步骤。界面会改版，用例不应随按钮位置变化。纠正方法是把步骤写成参与者意图与系统响应，例如“读者提交借阅请求”“系统校验并登记借阅记录”。
第二种误解是把用例写成功能清单。例如列出“查询图书、借书、还书、续借”四条，每条只有名称没有流程。这样的清单无法说明条件与结果。纠正方法是每条至少补齐前置条件、主成功场景与主要备选流程。
第三种误解是用例粒度过细。例如把“输入读者卡号”“扫描图书条码”各立一个用例。粒度应以参与者目标为准：读者借书是一个目标，输入卡号只是其中一步。纠正方法是先问“参与者想达成什么”，再决定用例边界。
把这三类问题改掉之后，用例规约就能同时服务于三方：业务方确认行为是否符合预期，开发方明确需要处理哪些分支，测试方按主流程与备选流程设计用例路径。
常见问题
用例一定要画用例图吗？只写用例规约可以吗？
可以。用例图的作用是快速呈现参与者、用例、系统边界和关联关系，帮助团队建立全局认识；用例规约负责单个用例的完整细节。项目里用例数量少、参与者关系简单时，直接写规约并配上文字说明也能满足需求评审和开发测试的需要。用例数量多、参与者与用例交叉复杂时，补一张用例图能减少沟通成本。两种形式服务的目标一致，选择取决于团队需要多快看清全局结构。
用例的粒度怎么把握，什么情况该拆成两个用例？
判断标准是参与者目标是否发生变化。读者借书是一个目标，管理员上架新书是另一个目标，应拆成两个用例；而“输入读者卡号”“扫描图书条码”只是借书目标中的步骤，留在同一个用例的主流程里即可。遇到拿不准的情况，可以先问“参与者这次想达成什么结果”，如果两段交互对应不同的可观察结果，就拆开；如果只是同一目标下的不同操作顺序，就合并。粒度偏细会让用例退化为操作说明，偏粗则无法指导开发和测试设计。
用例里的备选流程和异常处理有什么区别，需要分开写吗？
备选流程描述主流程中某个判断出现其他结果时，系统转而执行的路径，其中一部分仍可能成功完成目标，例如读者额度已满时提示并结束。异常处理侧重系统无法完成目标时的响应与最终状态，例如登记借阅记录时外部馆藏系统无响应。两者分开写的好处是评审时能清楚看到哪些分支仍可达成目标、哪些以失败结束，测试设计也能据此区分路径。如果项目规模小、分支少，合并在扩展流程一节里写也可以，但成功与失败的结束状态要分别标明。
已经有用户故事了，还需要补用例吗？
取决于交互复杂程度。用户故事用简短陈述表达价值，适合迭代中快速排优先级；当某个故事的交互分支多、条件判断复杂，或者需要开发与测试提前对齐行为时，补一份用例规约能把主成功场景、备选流程和结束状态写清楚。常见做法是用用户故事管理优先级和范围，把复杂故事的细节放到用例规约里承载，两者通过同一个需求工作项关联，避免文档各写一份、后续难以对齐。
用例写完之后，怎么和后续的开发、测试衔接？
关键是让用例规约成为可追踪的需求对象，而不是一份孤立文档。评审意见留在规约上，定稿后与对应的需求工作项关联；开发任务从该工作项拆分，测试人员按主成功场景、备选流程和异常处理设计测试路径，并把测试用例链接回同一工作项。这样需求变更时能快速定位受影响的开发任务和测试用例。在 ONES 中，可以把规约作为需求文档承载并与需求工作项关联，评审、开发和测试围绕同一对象协作。
