用例建模在研发团队中落地，关键在建模前先定对象与粒度，建模中统一模板与分工，建模后把用例接入需求、变更和测试。本文按“判断适用范围—五步操作—角色分工—完整示例—流程衔接—完成检查”的顺序，给出一套可直接执行的落地方法，适合需求负责人、业务分析和研发测试团队参照使用。
要点总览（TL;DR）
- 先判断哪些需求值得写成用例：有明确参与者、有可陈述目标、目标达成可观察的交互型需求才纳入，纯算法、纯样式、纯数据迁移改用其他表达。
- 按五步推进：识别参与者、写目标级用例名、编写主成功场景与备选路径、补充前置后置条件与业务规则、编写验收条件并关联测试点，每步都有明确产出和完成标志。
- 角色分工要落到人：需求负责人编写并维护，业务方确认目标与规则，开发和测试参与评审，评审分用例清单、场景、验收条件三个时点。
- 用例要作为需求条目纳入版本与变更管理，与验收条件、测试用例保持双向追溯，变更触发条件写进规范。
- 用六项检查清单判断落地程度，优先补齐参与者清单和验收条件关联，这两项对后续变更和测试影响最大。
先定建模对象与粒度：哪些需求值得写成用例
用例建模的第一步是筛选对象，把有明确参与者、有目标达成判断的交互型需求挑出来写成用例。判断标准可以归纳为三条：存在外部交互方（人、外部系统或定时触发方）；该交互方有明确要达成的目标；目标是否达成可以被观察和判断。三条同时满足，才进入用例清单。
粒度规则建议统一为：一个用例对应一个参与者的一个目标，主成功场景能在一页内讲完。如果一页写不下，通常说明目标被拆得不够，或者把多个目标塞进了一个用例。团队应在启动前把这条规则写进建模规范，避免不同人写出粗细不一的用例。
以下需求类型不适合套用例模板：纯算法与计算逻辑、纯界面样式与布局、纯数据迁移与清洗、纯技术性能优化。这些需求缺少参与者目标这一核心要素，改用规则说明、界面说明、迁移方案或性能指标来表达更清楚。把它们硬套用例模板，只会增加文档量而不增加信息。
启动建模前需要确认三类输入：业务目标，说明这次建模要支撑什么决策或交付；参与者清单初稿，列出所有可能与系统交互的人和外部系统；范围边界，明确本次建模覆盖哪些业务流程、不覆盖哪些。三类输入齐备，再开始写第一个用例。
| 判断项 | 纳入用例 | 不纳入用例 |
|---|---|---|
| 交互方 | 有明确参与者或外部系统 | 无外部交互方 |
| 目标 | 参与者有可陈述的目标 | 只有处理规则或计算逻辑 |
| 完成判断 | 目标达成可观察、可验收 | 结果只能靠主观感受判断 |
| 粒度 | 一个参与者目标，主成功场景一页内讲完 | 多个目标混写，场景跨多页 |
| 替代表达 | — | 规则说明、界面说明、迁移方案、性能指标 |
核心操作步骤：从参与者到可验收用例的五步
五步流程按“参与者—用例清单—场景—条件与规则—验收条件”的顺序推进，每一步都有明确产出和完成标志，团队可以按步检查进度，避免写到一半发现对象选错。
第一步：识别参与者与外部系统
输入是业务目标与范围边界。动作是列出所有与系统交互的人、角色和外部系统，区分主要参与者与次要参与者，标注每个参与者的交互目的。输出是参与者清单。完成标志是清单经过业务方确认，没有遗漏的外部交互方。
第二步：为每个参与者写目标级用例名
输入是参与者清单。动作是以“参与者+动词+对象”的格式为每个目标命名，例如“客户取消订单”“运营人员导出对账单”，一个目标一个用例名，不把步骤写进名称。输出是用例清单，含编号、名称、参与者、优先级。完成标志是用例清单通过评审，名称粒度一致。
第三步：编写主成功场景与备选路径
输入是用例清单。动作是先写主成功场景，按“参与者动作—系统响应”交替的步骤推进，编号连续；再为每个可能偏离主场景的分支写备选路径或异常路径，标明触发条件和返回点。输出是场景步骤描述。完成标志是主成功场景步骤完整、备选路径覆盖已知异常，且每条路径都能回到明确的结束状态。
第四步：补充前置条件、后置条件与业务规则
输入是场景步骤。动作是写明用例启动前必须成立的前置条件、结束后系统应处于的后置状态，并把场景中引用的业务规则单独编号列出，例如金额上限、状态流转限制。输出是条件与规则清单。完成标志是每条规则都有编号，场景步骤能引用到对应规则。
第五步：编写验收条件并关联测试点
输入是场景步骤与业务规则。动作是把每个可观察的结果转成一条可测的验收条件，标注对应的场景步骤或规则编号，再由测试人员映射为测试点。输出是验收条件清单与测试点关联表。完成标志是每条验收条件都能被独立验证，且至少关联一个测试点。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、识别参与者 | 业务目标、范围边界 | 列出人与外部系统，区分主次 | 参与者清单 | 业务方确认无遗漏 |
| 二、写用例名 | 参与者清单 | 按“参与者+动词+对象”命名 | 用例清单 | 清单通过评审，粒度一致 |
| 三、写场景 | 用例清单 | 写主成功场景与备选路径 | 场景步骤 | 路径完整，结束状态明确 |
| 四、补条件与规则 | 场景步骤 | 写前置/后置条件，编号业务规则 | 条件与规则清单 | 规则可被步骤引用 |
| 五、写验收条件 | 场景步骤、业务规则 | 转成可测条件并关联测试点 | 验收条件与测试点关联表 | 每条条件可独立验证 |
角色与交付物：谁写、谁评审、谁维护
落地失败的常见原因是“大家都在写、没人负责”。建议明确四类角色，并把评审安排在三个固定时点，让每个交付物都有归属人。
需求负责人或业务分析人员是用例的主要编写者，负责参与者清单、用例清单、场景步骤、条件与规则的初稿。领域专家或业务方负责确认参与者、目标和业务规则，对业务正确性签字。开发人员参与评审，重点确认场景的可实现性和技术约束是否被遗漏。测试人员参与评审，重点确认验收条件可测、测试点覆盖完整。
评审时点建议设为三个：用例清单评审，在第二步完成后进行，确认对象和粒度；场景评审，在第三步完成后进行，确认主成功场景与备选路径；验收条件评审，在第五步完成后进行，确认可测性与测试点关联。三个时点各自有明确的通过标准，避免把所有问题堆到一次大评审。
| 角色 | 主要职责 | 交付物 | 参与评审时点 |
|---|---|---|---|
| 需求负责人/业务分析 | 编写用例与场景，维护版本 | 参与者清单、用例清单、场景、条件与规则、验收条件 | 组织并参与全部三次评审 |
| 领域专家/业务方 | 确认参与者、目标与业务规则 | 业务确认意见 | 用例清单评审、场景评审 |
| 开发 | 确认可实现性与技术约束 | 技术评审意见 | 场景评审、验收条件评审 |
| 测试 | 确认可测性与测试点覆盖 | 测试点关联表 | 验收条件评审 |
交付物归属上，用例文档由需求负责人维护，测试点关联表由测试人员维护，评审记录由组织评审的人保存。版本维护责任人应写进建模规范，避免用例更新后无人同步。
示例：一个订单取消用例的完整写法
以下示例为演示情景，用于说明模板字段如何填写，团队可照此迁移到自己的业务。
用例名称：客户取消订单。参与者：已下单客户（主要）、支付系统（次要）。目标：客户在允许取消的时间窗内成功取消订单并获得退款。范围：覆盖订单未发货前的取消，已发货订单的退货不在本用例范围。
前置条件：订单存在且状态为“待发货”；客户已登录。后置条件：订单状态变为“已取消”，退款请求已提交支付系统。
主成功场景：1. 客户在订单详情页选择取消订单；2. 系统校验订单状态与取消时间窗；3. 系统展示退款金额与预计到账时间；4. 客户确认取消；5. 系统将订单置为“已取消”并向支付系统提交退款请求；6. 系统提示取消成功。
备选路径：2a 订单已发货，系统提示需走退货流程并终止本用例；2b 超出取消时间窗，系统提示不可取消；5a 支付系统退款请求失败，系统记录失败原因并将订单置为“取消待退款”，提示客户稍后查看。
业务规则：R1 未发货订单可在下单后24小时内取消；R2 退款金额按实付金额计算，不含已使用的优惠券；R3 退款请求失败需在2小时内重试。
验收条件：AC1 对应步骤2、R1，未发货且在下单24小时内的订单可取消成功；AC2 对应步骤2a，已发货订单取消时提示退货流程；AC3 对应步骤5、R2，退款金额等于实付金额；AC4 对应步骤5a、R3，退款失败时订单状态为“取消待退款”且生成重试记录。每条验收条件标注来源步骤或规则编号，测试人员据此建立测试点。
把用例接入需求与变更流程
用例写完不等于落地，需要作为需求条目纳入版本管理，并与变更、测试保持关联。组织方式上，建议每个用例作为一个独立需求条目，编号规则可采用“模块前缀-序号”，例如“ORD-UC-012”，条目内包含参与者、场景、条件、规则和验收条件字段。这样用例可以被单独指派、评审和追踪状态。
变更同步的触发条件应写清楚：参与者或目标变化、主成功场景步骤增删、业务规则调整、验收条件修改，任一发生即触发用例更新，并同步检查关联测试点是否失效。用例与验收条件、测试用例之间保持双向追溯：从用例能查到对应测试点，从测试点能回溯到用例和规则编号。
评审记录与版本留痕需要保存每次评审的结论、参与人和修改内容，确保后续追溯时能看清某条规则是哪次评审确定的。这些管理动作如果靠文档散落保存，容易在版本迭代中丢失关联。
在需求管理工具中承载时，可以把每个用例建成需求条目，用状态字段标记“草稿—评审中—已确认—已变更”，用关联关系把用例与验收条件、测试用例、评审记录连接起来。ONES 的需求管理能力支持需求条目的组织、状态流转与关联关系维护，团队可以把用例清单、验收条件和测试点放在同一套条目体系下管理，变更时沿关联关系同步检查，减少用例写完即归档的情况。具体字段配置和流程设置需按团队现有规范调整。
完成检查：用例建模落地的验收清单
以下清单用于判断团队的用例建模是否达到可用状态，每项给出通过标准，可逐项核对。
| 检查项 | 通过标准 |
|---|---|
| 参与者清单覆盖度 | 所有外部交互方均已列出，主次参与者区分清楚，业务方已确认 |
| 用例目标明确性 | 每个用例有唯一参与者目标和可观察的完成判断 |
| 场景完整性 | 主成功场景步骤连续完整，备选路径覆盖已知异常并能回到明确结束状态 |
| 验收条件可测性 | 每条验收条件可独立验证，并关联至少一个测试点 |
| 版本与变更管理 | 用例作为需求条目纳入版本管理，变更触发条件已定义并执行 |
| 评审记录可追溯 | 三次评审均有记录，含结论、参与人和修改内容 |
六项全部通过，说明用例建模已形成可执行的流程；若有项目未通过，优先补齐参与者清单和验收条件关联，这两项对后续变更和测试的影响最大。
常见问题
团队规模较小、没有专职业务分析人员时，用例建模怎么分工？
可以由产品经理或需求负责人承担编写职责，业务方确认目标和业务规则，开发和测试参与评审。关键是把三个评审时点保留下来，即使参与人数少，也要在用例清单、场景和验收条件三个阶段分别确认，避免编写和评审由同一人一次完成、问题被掩盖。角色可以合并，职责和确认动作不建议省略。
已有用户故事和验收条件，还需要再写用例吗？
两者可以并存，按需求类型分工。用户故事适合表达较短周期的增量需求，用例适合表达参与者目标明确、路径分支较多的交互型需求。若某个用户故事涉及多个备选路径和异常处理，可以把它展开成用例，用场景步骤和业务规则补充细节；若需求本身简单、只有一条主路径，保留用户故事加验收条件即可，不必重复建模。
用例写到什么程度算完成，评审时最容易漏什么？
完成标志是主成功场景步骤连续、备选路径能回到明确结束状态、每条业务规则有编号且被步骤引用、每条验收条件可独立验证并关联测试点。评审中最容易漏的是备选路径的结束状态和业务规则的编号引用，前者导致异常处理无人负责，后者导致验收条件无法回溯到规则来源。
需求频繁变更时，用例维护成本会不会过高？
维护成本取决于变更触发条件是否清晰。建议只把参与者或目标变化、主成功场景步骤增删、业务规则调整、验收条件修改这四类情况定义为必须更新用例的触发条件，其余细节调整按影响范围判断。用例作为独立需求条目管理时，可以只更新受影响条目并检查关联测试点，避免整份文档重写。
用例和测试用例是什么关系，是否要各写一遍？
用例描述业务目标和场景，测试用例描述验证动作和数据，两者层次不同但应保持追溯。实践中可以从验收条件直接映射测试点，测试人员补充具体输入数据和预期结果，无需把场景步骤逐条复制成测试用例。保持从用例能查到测试点、从测试点能回溯到用例和规则编号即可。
