用例建模是一种从使用者目标出发描述系统行为的建模方法：它把系统当作一个整体，围绕参与者通过系统完成某个可观察目标的过程，写出用例及其主流程、备选流程和前置后置条件，用来表达和确认需求中的功能范围与交互约定。本文围绕定义、组成要素、覆盖边界，以及它与用户故事、流程图、功能列表的区别展开，并用一个示例说明写法。
要点总览（TL;DR）
- 用例建模从使用者目标出发描述系统行为，围绕参与者通过系统达成的完整目标，写出用例及其主流程、备选流程和前置后置条件。
- 一个用例由参与者、目标式命名的用例、主流程、备选流程、触发事件与前后置条件共同构成，缺一项都会留下模糊地带。
- 用例建模覆盖功能目标、参与者、触发条件、正常与异常路径；系统架构、接口设计、界面布局、优先级取舍和非功能需求的完整表达不属于它。
- 与用户故事、流程图、功能列表相比，用例建模强调目标完整性与系统职责边界，适合功能范围需多方确认、交互约定较复杂的场景。
- 用例图只是视图，建模主体是文字描述；把界面操作当步骤、按按钮拆用例、以数量衡量完整性，都是常见误解。
用例建模的核心定义与关键术语
用例建模回答的是“谁在什么条件下要系统帮他达成什么目标”。它把系统视为一个黑盒，只描述外部可见的行为，不涉及内部如何实现。一个完整的用例建模产物，通常由参与者、用例、场景与流程、前置后置条件几类要素共同构成，这些要素合起来表达功能范围与交互约定。
理解用例建模，先要建立一套共同语言。下表列出最常用的术语及其含义。
| 术语 | 含义 | 在建模中的作用 |
|---|---|---|
| 参与者（Actor） | 位于系统外部、与系统交互的角色或外部系统，可以是人，也可以是另一个系统 | 界定“谁在使用系统”，确定系统边界之外的交互方 |
| 用例（Use Case） | 参与者与系统协作达成的一个完整目标 | 表达一项有始有终的功能目标，是建模的基本单元 |
| 场景（Scenario） | 一次具体执行路径，是主流程或某条备选流程的一次实例 | 把抽象流程落到具体情形，便于讨论和验证 |
| 主流程 | 顺利达成目标的标准步骤序列 | 描述“一切正常时”系统与参与者的交互 |
| 备选流程 | 主流程之外的分支、异常或替代路径 | 覆盖条件不满足、出错、取消等情形 |
| 前置条件 | 用例开始前必须成立的状态 | 说明触发该用例的前提 |
| 后置条件 | 用例结束后系统应处于的状态 | 说明目标达成后留下的结果 |
在需求表示中，用例建模处在“功能需求”这一层。它承接业务目标与用户诉求，向下为设计、开发和测试提供可讨论的功能范围。它既不是业务战略描述，也不是技术设计文档，而是把“系统该为谁做什么”写成可评审、可追踪的文本。参与者与用例的关系可以用用例图呈现，但建模的主体是文字描述，图只是辅助视图。
用例建模包括什么、不包括什么
用例建模的边界，决定了它适合承载什么、应当交给哪些环节。把它当成“画几张图”或“写全部需求”，都会导致产物失真。下面按覆盖与不覆盖两类分别说明。
用例建模覆盖的内容：
- 功能目标：系统为参与者提供哪些可观察的目标。
- 参与者：谁使用系统、谁被系统调用，以及外部系统的交互关系。
- 触发条件：什么事件或状态启动一个用例。
- 正常与异常路径：主流程以及各类备选流程、异常分支。
- 前置条件与后置条件：用例开始与结束时系统应处的状态。
用例建模不覆盖的内容：
- 系统架构与模块划分：这些属于设计决策，用例只描述外部行为。
- 数据库与接口设计：表结构、字段、接口协议不在用例描述范围内。
- 界面布局与视觉稿：按钮位置、页面跳转的视觉呈现不属于用例步骤。
- 需求价值判断与优先级取舍：判断某个需求值不值得做、先做哪个，属于需求分析与澄清的工作。
- 非功能性需求的完整表达：性能、安全、可用性等只能作为约束附在用例上，无法由用例结构完整承载。
这条边界有一个实际意义：用例写得好，说明功能范围与交互约定清楚了；但它不能替代架构评审、优先级决策和非功能需求的专项梳理。把这些内容硬塞进用例，会让用例变得臃肿，也会让真正该由其他环节处理的问题被掩盖。
用例建模怎么运作：从目标到用例的组成结构
用例建模的运作过程，可以理解为从“找参与者”到“写清一个完整目标”的逐步收敛。每个用例由若干要素配合表达，缺一项都会让需求留下模糊地带。下面按编写顺序说明各要素及其要点。
识别参与者
先问两个问题：谁直接使用系统完成工作？系统需要调用哪些外部系统？前者是主要参与者，后者是次要参与者。参与者是角色而非具体某个人，同一个人在不同场景下可能对应不同角色。识别参与者时，把系统边界画清楚，边界之外与系统交互的才是参与者。
确定目标并命名用例
每个参与者都有想达成的目标，一个完整目标对应一个用例。命名采用“动词+对象”的目标式写法，例如“提交报销单”“查询订单状态”，让读者一眼看出参与者要达成什么。避免用“报销单管理”这类笼统名词，它无法说明目标是否完成。
编写主流程
主流程是达成目标的标准步骤序列，按“参与者动作—系统响应”交替推进，写到目标达成为止。步骤应停留在业务动作层面，例如“参与者提交报销单，系统校验必填项并生成待审批记录”，而不是描述点击了哪个按钮。
补充备选流程与异常路径
主流程之外，把条件不满足、校验失败、取消操作、超时等情形写成备选流程，并标明它从主流程的哪一步分支、最终回到哪一步或如何结束。备选流程是需求完整性的关键，很多争议恰恰出现在异常路径上。
写明前置条件、后置条件与触发事件
前置条件说明用例开始前必须成立的状态，例如“参与者已登录且具备报销权限”；后置条件说明用例结束后系统应处的状态，例如“报销单已生成并进入待审批队列”。触发事件说明是什么启动了该用例，例如“参与者点击提交”。
处理用例之间的关系
当多个用例共享一段行为或存在特化关系时，可以用包含、扩展、泛化来表达。包含用于抽取多个用例共用的必经行为；扩展用于描述在特定条件下才插入的可选行为；泛化用于表达一般与特殊的关系。这三种关系应谨慎使用，关系过多会让用例结构难以阅读，能用文字说明清楚的，不必强行抽象。
用例建模与用户故事、流程图、功能列表的区别
这几种表达方式常被混用，但它们回答的问题不同。用同一口径对照，可以判断什么时候该用用例建模。
| 对比项 | 用例建模 | 用户故事 | 流程图 | 功能列表 |
|---|---|---|---|---|
| 核心关注 | 参与者目标与系统职责边界 | 用户价值与对话起点 | 步骤流转与判断分支 | 系统具备的能力清单 |
| 粒度 | 一个完整目标，含主流程与备选流程 | 较小，通常一句话加验收条件 | 可粗可细，按流程范围而定 | 按功能条目拆分 |
| 是否强调目标完整性 | 强调，目标达成才算用例结束 | 强调价值，完整性靠验收条件补充 | 不强调目标，强调路径 | 不强调目标，强调能力有无 |
| 验收方式 | 按主流程与备选流程逐条验证 | 按验收条件验证 | 按路径覆盖验证 | 按功能是否可用验证 |
| 适用场合 | 功能范围需与多方确认、交互约定较复杂时 | 迭代中快速拆分与沟通 | 梳理业务步骤与审批流转 | 盘点能力、做范围清单 |
还需要单独说明用例图。用例图是用例建模的一种视图，用参与者和用例的连线展示系统功能范围，但它不承载流程细节。建模的主体是用例描述文本，图只是索引。只画图不写描述，等于只给了目录而没有内容。
在实际项目中，这些表达方式常常配合使用：功能列表用于盘点范围，用例描述用于把关键功能写透，用户故事用于迭代拆分，流程图用于说明跨角色的步骤流转。判断是否该用用例建模，可以看这个功能是否有明确的参与者目标、是否存在多条路径需要约定、是否需要与业务方逐条确认交互边界。
一个具体例子与常见误解
下面以“在线提交报销单”为例，演示一个用例的完整写法。该示例为演示情景，用于说明结构，不代表真实项目。
示例用例：在线提交报销单
- 参与者：报销申请人（主要参与者），财务审批系统（次要参与者）。
- 前置条件：申请人已登录系统，且具备报销申请权限。
- 触发事件：申请人发起新建报销单。
- 主流程：申请人填写报销事由与金额；系统校验必填项与金额格式；申请人上传凭证；系统生成报销单并提交至审批队列；系统返回提交成功结果。
- 备选流程（凭证缺失）：申请人在上传凭证步骤选择暂不上传；系统提示凭证为必填项并阻止提交；申请人补传凭证后回到主流程继续。
- 后置条件：报销单已生成，状态为待审批，并进入对应审批人的待办列表。
这个例子体现了用例描述的几个要点：步骤停留在业务动作，参与者与系统交替推进，备选流程标明分支位置与回归路径，前后置条件说明状态变化。
常见误解与纠正
- 误解一：把界面操作步骤当作用例步骤。“点击提交按钮”“打开下拉框选择部门”是界面细节，界面改版后这些描述就失效。用例步骤应写业务动作，例如“申请人提交报销单”。
- 误解二：把每个按钮或每个接口写成一个用例。用例对应参与者的完整目标，一个目标下的多个操作属于同一用例的步骤。按按钮拆用例，会让目标被切碎，流程关系难以看清。
- 误解三：用例数量越多表示需求越完整。完整性取决于每个用例是否覆盖了主流程与关键备选流程，以及边界是否清楚。数量多但每个都只有主流程，反而掩盖了异常路径上的需求缺口。
- 误解四：用例建模只画图不写文字。用例图只表达参与者与用例的对应关系，流程、条件、异常都在描述文本里。评审时真正被讨论和确认的是文本。
当用例描述需要多人协作编写、逐条评审并随需求变更保持版本一致时，承载方式会影响建模的实际效果。ONES 提供 Wiki 页面与工作项来承载需求文档和评审记录，用例描述可以作为文档内容组织，评审意见与变更在工作项中流转；ONES Assistant 智能助手可理解项目、工作项、迭代和 Wiki 页面等工作上下文，基于项目数据和团队知识回答问题，并可将自然语言指令转化为可追踪的工作，例如把 PRD 拆解为需求和任务并按模块分配负责人。这样，用例从编写、评审到后续跟踪可以留在同一条协作链路上。需要说明的是，用例建模的方法本身独立于工具，工具解决的是承载、评审与追踪的问题。
常见问题
用例建模适合在什么阶段做，需求已经写成用户故事了还需要补用例吗？
用例建模通常在功能范围需要与业务方、开发、测试逐条确认时价值最大，可以放在需求澄清之后、进入迭代拆分之前。已经写成用户故事的需求，如果目标单一、路径简单，用验收条件补充即可；如果存在多条备选流程、跨多个角色或外部系统交互，补一份用例描述能把异常路径和前后置条件写清楚，减少后续争议。判断标准是目标是否完整、路径是否复杂，而非团队习惯用哪种模板。
一个用例的主流程写多细比较合适，写到界面操作算不算过度？
主流程应停留在业务动作层面，按“参与者动作—系统响应”交替推进，写到目标达成为止。出现具体按钮名称、页面跳转、控件类型时，说明已经进入界面设计层面，界面改版后这些描述就会失效。一个实用的检验方法是：把这段描述读给业务方听，对方能确认“这就是我要办成的事”，而无需讨论页面长什么样，粒度基本合适。
用例之间的包含、扩展、泛化关系，什么时候值得用？
这三种关系用于处理多个用例共享行为或存在特化的情况。包含适合抽取多个用例都必须执行的公共行为；扩展适合描述只在特定条件下才插入的可选行为；泛化适合表达一般与特殊的关系。使用前提是抽象之后结构更易读。如果只有两三个用例、共享内容用一句话就能说明，直接用文字描述更清楚。关系层次过多会让评审者频繁跳转，反而降低可读性。
用例描述写完以后，怎么保证评审意见和后续变更不丢失？
用例描述通常需要多人协作编写、逐条评审，并随需求变更保持版本一致。可以把用例文本放在文档协作空间中组织，评审意见与变更记录放在工作项里流转，让编写、评审和后续跟踪留在同一条链路上。ONES 提供 Wiki 页面与工作项来承载需求文档和评审记录，ONES Assistant 智能助手可理解项目、工作项、迭代和 Wiki 页面等工作上下文，基于项目数据和团队知识回答问题，并可将自然语言指令转化为可追踪的工作，例如把 PRD 拆解为需求和任务并按模块分配负责人。工具解决的是承载与追踪问题，用例建模方法本身独立于工具。
非功能性需求能不能写进用例里？
性能、安全、可用性等非功能性需求无法由用例结构完整承载，通常作为约束附在相关用例上，例如在“提交报销单”用例旁注明响应时间要求或权限校验要求。这样处理的好处是约束与具体功能目标相邻，开发和测试容易找到对应场景；局限是覆盖面取决于是否有人逐条梳理，因此非功能性需求仍需专项梳理，不能指望用例建模一并解决。
