用例建模在研发团队落地，关键是把范围收在一条业务主线或一个迭代内，先约定用例粒度与命名规则，再按识别参与者、梳理主成功场景与异常分支、编写用例描述、补充验收条件的顺序推进。业务分析或产品角色主笔，研发与测试参与评审，用例作为需求条目挂到需求管理工具中，与验收条件、测试用例建立可追溯关系。本文按范围界定、操作步骤、角色分工、工具承载、示例与检查六个环节展开，ONES 作为承载用例登记与流转的工具之一在相应章节说明。
要点总览（TL;DR）
- 首批建模范围限定在一条业务主线或一个迭代内，动笔前约定“一个用例对应一个参与者目标”的粒度规则，并配正反例统一判断。
- 按识别参与者、梳理主成功场景与异常分支、编写用例描述、补充验收条件、评审定稿五步推进，每步都有输入、输出和完成标志。
- 业务分析或产品角色主笔，研发核对可实现性与边界，测试派生测试场景，评审组织者与记录人分别负责排期和结论留存。
- 用例作为需求条目登记并统一编号，与验收条件、测试用例建立追溯关系，变更从用例条目发起评审并回写状态。
- 用范围、粒度、场景完整性、验收条件、关联关系、变更回流六项清单检查落地效果，重点纠正功能清单化、备选流缺失和用例与测试脱节三类偏差。
落地前先定范围与用例粒度
用例建模最常见的失败起点，是第一次就把整个系统的用例铺满，结果参与者识别不全、场景写到一半失去重点，评审也无法收敛。首批建模范围建议限定在一条业务主线或一个迭代内，例如“订单从提交到完成”或“本迭代新增的会员权益发放”，范围之外的需求先登记、不建模。范围说明写清三件事：这条主线覆盖哪些业务环节、涉及哪些参与者和外部系统、哪些内容留到后续批次。
粒度约定要在动笔前定下来，核心规则是一个用例对应一个参与者目标。参与者发起动作、期望达成某个可观察的结果，这个目标构成一个用例；同一参与者为达成不同目标发起的动作，拆成不同用例；目标相同但路径不同的情况，写进同一用例的基本流与备选流，不拆成多个用例。粒度约定最好配两三个正例和反例，让主笔和评审人对“一个用例多大”有共同判断。
建模阶段只负责把需求表达成结构化的用例，需求内容本身的业务合理性、优先级取舍、与用户确认口径，属于需求分析与澄清的工作，在建模前完成或并行推进，不在用例文档里展开论证。启动前需要准备三类输入：业务目标或本次迭代目标，参与者与外部系统清单，以及已经登记的需求条目。已有需求条目是用例的来源和挂接对象，缺少这一项，后续追溯关系就无从建立。
首批建模范围说明建议包含以下字段，作为启动评审的交付物：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 建模范围 | 一条业务主线或一个迭代，写明起止环节 | 订单提交至订单完成 |
| 范围外内容 | 明确本批不建模的需求，登记留待后续 | 售后退款流程 |
| 参与者清单 | 人、角色与外部系统分开列 | 买家、客服、支付网关 |
| 粒度约定 | 一个用例对应一个参与者目标，附正反例 | “取消未支付订单”为一个用例 |
| 输入来源 | 业务目标、需求条目编号、相关文档位置 | 迭代目标文档、需求池条目 |
用例建模的操作步骤与每步产出
从识别参与者到用例定稿，可以拆成五步。每一步都有明确输入、动作、输出和完成标志，团队按表推进即可，不必额外设计流程。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 识别参与者与外部系统 | 范围说明、业务流程图、需求条目 | 列出直接使用系统达成目标的人与角色，以及系统交互的外部系统；区分主要参与者与辅助参与者 | 参与者清单，标注每个参与者的目标 | 清单经业务与研发确认，无遗漏的主要参与者 |
| 2. 梳理主成功场景与异常分支 | 参与者清单、业务规则 | 对每个参与者目标写出顺利完成的路径，再列出可能中断或改道的分支：校验失败、外部系统不可用、权限不足、超时等 | 每个用例的场景清单，区分主成功场景与异常分支 | 每个用例至少有一条主成功场景，异常分支覆盖已识别的业务规则 |
| 3. 编写用例描述 | 场景清单、业务规则 | 按前置条件、基本流、备选流、后置条件四段编写；基本流写步骤编号，备选流标注从基本流哪一步分叉、如何回到主线或结束 | 用例描述文档，统一编号与命名 | 描述可被未参与讨论的研发人员独立读懂 |
| 4. 补充验收条件 | 用例描述 | 从基本流和每条备选流的终点提炼可验证的结果，写成可判定的验收条件 | 每个用例对应的验收条件列表 | 每条验收条件都能对应到具体场景，且可被测试验证 |
| 5. 评审与定稿 | 用例描述、验收条件、关联需求条目 | 组织业务、研发、测试评审，记录问题并修订；确认用例与需求条目、验收条件的关联完整 | 定稿用例、评审记录、遗留问题清单 | 评审问题关闭或转为待办，用例状态置为已定稿 |
第 2 步的异常分支容易写少。一个实用的检查方式是逐条对照业务规则：每条校验规则、每个外部依赖、每种权限状态，都问一句“这里出问题会怎样”，把答案落到备选流。第 3 步的备选流要写清分叉点和回归点，只写“若失败则提示错误”这类描述，测试无法据此设计场景。第 5 步的完成标志以状态为准，评审通过但问题未关闭的用例不进入定稿，避免带着争议进入开发。
角色分工与交付物清单
用例建模需要四类角色参与，主笔只有一个，避免多人合写导致口径不一。业务分析或产品角色主笔用例描述，负责参与者识别、场景梳理和验收条件的初稿；研发角色在评审中核对场景可实现性与系统边界，指出外部系统交互、状态流转中不成立的部分；测试角色基于用例派生测试场景，检查每条备选流是否有对应验证路径；评审组织者负责排期、收集问题、跟踪关闭，记录人负责留存评审结论和修订记录。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 业务分析/产品 | 主笔用例描述，识别参与者，梳理场景，初拟验收条件 | 用例描述初稿、参与者清单、验收条件初稿 | 评审前两个工作日提交评审材料 |
| 研发 | 核对场景可实现性、系统边界与外部依赖 | 评审意见、边界问题清单 | 评审会上给出，或评审前书面反馈 |
| 测试 | 基于用例派生测试场景，核对备选流覆盖 | 测试场景清单、覆盖缺口说明 | 用例定稿后进入测试设计前 |
| 评审组织者 | 排期、组织评审、跟踪问题关闭 | 评审通知、问题跟踪表 | 评审前后各一次状态同步 |
| 记录人 | 记录评审结论、修订项与责任人 | 评审记录、修订记录 | 评审结束后一个工作日内发出 |
交接时点决定流程是否顺畅。主笔在评审前提交材料，让研发和测试有时间预读；测试的场景派生放在用例定稿之后，避免用例还在修订就先行设计测试；记录人的评审记录要包含每条问题的责任人和关闭时间，作为下一轮检查的依据。小团队可以合并评审组织者与记录人，主笔与评审角色仍应分开，保证有人从实现角度提出异议。
用例如何挂到需求管理与协作流程中
用例停留在文档里，修订和引用就会失控。落地时把每个用例作为需求条目或需求下的子项登记，统一编号与命名，编号规则建议采用“模块前缀-序号”，命名采用“参与者+动作+对象”的结构，例如“买家-修改-未支付订单收货地址”。用例条目下挂验收条件，测试用例通过关联字段指向来源用例，形成用例—验收条件—测试用例的追溯链。变更发生时，从用例条目发起需求评审，评审结论回写到用例状态，而不是在聊天记录里口头确认。
ONES 在需求与交付协同上提供了可用的承载方式。其统一的需求池、工单与任务看板可以实时同步状态与信息，追溯需求与问题；业务需求池、产品需求池与工单系统支撑需求—任务—测试—缺陷的全流程闭环；测试管理侧配套用例库、测试计划、缺陷管理与报告生成。团队可以把用例作为需求条目登记进需求池，用状态流转承载“草稿—评审中—已定稿—变更中”的过程，把验收条件写在条目描述或关联文档中，测试用例在用例库中建立并关联来源需求。用例评审可以借助迭代计划与任务看板安排评审任务，评审记录沉淀在文档中，便于后续追溯。
需要说明的是，ONES 是否提供用例图绘制或 UML 建模的专用图形能力，公开资料未作说明，选型时应向厂商核验；用例与测试用例之间关联的具体配置方式，也建议在试用环境中确认。若团队使用 ONES Assistant，其可连接 ONES Project、ONES Wiki 与 ONES TestCase，理解项目与 Wiki 上下文，把自然语言指令转化为可追踪的工作并保存为工作项或 Wiki 页面，可用于辅助整理用例草稿和评审待办，具体可用性以开通情况为准。
一个订单改址场景的用例示例
以下为演示性示例，用于说明写法与粒度判断，不代表真实客户案例。
用例名称：买家修改未支付订单收货地址
用例编号：ORDER-012
参与者：买家（主要参与者）；支付网关（辅助外部系统）
目标：买家在订单支付前把收货地址改为新地址，订单继续有效
前置条件：订单已提交且处于待支付状态；买家已登录；新地址在配送范围内
基本流：
- 买家在订单详情页选择“修改收货地址”。
- 系统展示当前地址与可选地址列表。
- 买家选择新地址并确认。
- 系统校验新地址在配送范围内，更新订单地址，展示修改成功。
- 买家继续完成支付。
备选流：
- 3a. 买家选择的新地址不在配送范围内：系统提示不可配送，保留原地址，返回步骤 2。
- 4a. 订单在修改过程中被支付：系统提示订单已支付无法修改，流程结束，引导买家走售后地址变更。
- 4b. 地址服务调用超时：系统提示稍后重试，订单地址保持不变，返回步骤 2。
后置条件：订单地址更新为新地址，订单状态仍为待支付；修改记录写入订单日志。
验收条件：
- 待支付订单可成功修改为配送范围内地址，订单详情展示新地址。
- 配送范围外地址提交时给出明确提示，原地址不变。
- 订单已支付时发起修改，给出不可修改提示并提供售后入口。
- 地址服务异常时订单数据不被改写，用户可重试。
这个示例体现两条粒度规律：目标单一，买家要达成的是“改地址后继续支付”，支付本身属于另一用例；分支归并，配送范围校验、支付状态冲突、外部服务异常都作为备选流写在同一用例内，不拆成独立用例。命名上采用“参与者+动作+对象”，编号带模块前缀，便于在需求池中排序和检索。
落地完成检查与常见偏差
判断用例建模是否落地到位，可以按下面清单逐项核对，每项都要求有可留存的证据，避免只凭印象判断。
| 检查项 | 通过标准 | 证据留存 |
|---|---|---|
| 范围 | 首批建模范围有书面说明，范围外需求已登记 | 范围说明文档、需求池条目 |
| 粒度 | 每个用例对应一个参与者目标，无功能清单式条目 | 用例清单与粒度约定对照记录 |
| 场景完整性 | 每个用例有主成功场景，异常分支覆盖已识别业务规则 | 场景清单、评审问题记录 |
| 验收条件 | 每条验收条件可判定，且能对应到具体场景 | 用例条目下的验收条件列表 |
| 关联关系 | 用例与需求条目、测试用例可双向追溯 | 需求池关联视图、测试用例关联字段 |
| 变更回流 | 变更经用例条目发起评审，结论回写状态 | 变更评审记录、状态流转日志 |
常见偏差有三类。第一类是用例写成功能清单，条目按页面或按钮组织，参与者目标消失；纠正动作是回到参与者清单，逐条问“谁要达成什么结果”，把功能描述改写成目标描述，无法归入任何参与者目标的条目退回需求分析环节。第二类是备选流缺失，只写顺利路径；纠正动作是按业务规则、外部依赖、权限状态三类逐条排查，每条补一个分支，并在评审中由测试角色专门核对。第三类是用例与测试脱节，测试用例另行编写、不指向来源用例；纠正动作是在测试设计启动前完成关联登记，把“测试用例是否关联来源用例”纳入测试计划准入检查。
落地效果可以用三个可观察指标跟踪：评审一次通过率、用例对已识别场景的覆盖率、变更发生后用例与测试用例的同步修订比例。指标连续两个迭代无改善时，优先检查范围是否铺得过大、粒度约定是否被绕过，而不是增加评审频次。
常见问题
团队第一次做用例建模，范围铺多大比较合适？
建议从一条业务主线或一个迭代开始，例如“订单提交至订单完成”或“本迭代新增的会员权益发放”。范围说明里写清覆盖哪些业务环节、涉及哪些参与者和外部系统、哪些需求本批不建模但已登记。范围收窄后，参与者识别和场景梳理能在一次评审内收敛，粒度约定也更容易被验证。等首批用例定稿并跑通评审流程，再按批次扩展。
用例描述写到什么程度算可以定稿？
一个实用标准是：未参与讨论的研发人员能独立读懂。具体看三点——基本流有步骤编号，备选流标注从哪一步分叉、如何回到主线或结束；每条验收条件可判定，且能对应到具体场景；用例与来源需求条目的关联已登记。评审通过但问题未关闭的用例不进入定稿，避免带着争议进入开发。
用例和测试用例之间怎么保持同步？
关键是建立指向关系：测试用例在编写时关联来源用例，测试设计启动前完成关联登记，把“是否关联来源用例”纳入测试计划准入检查。用例发生变更时，从用例条目发起评审，评审结论回写状态，同时检查受影响的测试用例是否需要修订。ONES 提供用例库、测试计划与缺陷管理，需求—任务—测试—缺陷可形成闭环，具体关联配置方式建议在试用环境中确认。
小团队人手少，角色分工可以合并吗？
可以合并部分角色。评审组织者与记录人常由同一人承担，主笔也可以兼任部分测试场景的梳理。主笔与评审角色仍建议分开，保证有人从实现角度提出异议。合并后要在流程里写清交接时点，例如评审材料提前两个工作日发出、评审记录一个工作日内发出，避免因人手少而跳过预读和问题跟踪。
用例建模落地后，怎么判断是否真的在起作用？
可以跟踪三个可观察指标：评审一次通过率、用例对已识别场景的覆盖率、变更发生后用例与测试用例的同步修订比例。指标连续两个迭代没有改善时，先检查范围是否铺得过大、粒度约定是否被绕过，再考虑调整评审方式。检查过程要留存证据，例如范围说明文档、场景清单、评审问题记录和需求池关联视图，便于回溯。
