用例建模与用户故事：需求表达、评审与变更的差异

用例建模和用户故事回答的是两个层面的问题：前者把系统与外部角色之间的交互目标写成带主流程、备选流程和异常路径的结构化规格，后者用角色—目标—价值描述需求意图，再配合验收条件和对话补充细节。团队在两者之间做选择，实际是在判断需求需要多完整的路径覆盖、多快的排序节奏，以及变更时希望改动落在哪一层。本文按表达、评审、变更三条主线对照，并给出组合使用的条件。

要点总览（TL;DR）

• 用例建模把一次参与者目标写成含主成功场景、备选与异常流程的结构化规格，适合交互分支多、外部系统对接多、验收要求严格的功能。
• 用户故事用角色—目标—价值陈述需求意图，配合验收条件和对话补充细节，适合需求演化快、需要频繁排序与拆分交付的场景。
• 评审关注点不同：用例评审走查路径完整性与异常覆盖，用户故事评审确认价值清楚、验收条件可判定、拆分合理。
• 变更影响面不同：用例变更牵动流程分支与相关参与者，需同步检查异常路径；故事变更多为卡片重写、验收条件调整或重新拆分。
• 两者可以组合：用故事承载待办、优先级与迭代安排，用用例承载复杂流程的完整规格，并约定书写规范与关联方式。

同一组标准下，两种表达方式差在哪里

把两种方法放在同一组维度上对照，差异集中在信息密度和正式程度上，并不构成优劣排序。用例建模把一次完整交互写成可逐条验收的规格，读者能顺着流程走完一个场景；用户故事把需求压缩成一句意图陈述，细节留到讨论和验收条件中展开。前者偏重覆盖，后者偏重排序和节奏。

对照维度	用例建模	用户故事
表达单元与粒度	一个用例对应一个参与者目标，粒度到流程步骤	一张卡片对应一个可交付的需求切片，粒度到价值点
角色与外部交互刻画	显式列出参与者及其与系统的交互边界	用“作为某角色”点明使用者，交互细节留给对话
流程与异常分支覆盖	主成功场景之外要求写出备选与异常流程	通常只写验收条件，异常路径按需补充
细节承载位置	写在用例正文的前置、流程、后置条件中	写在验收条件、补充说明和团队对话中
验收依据	以流程步骤和路径完成情况判定	以验收条件是否满足判定
评审关注点	参与者是否齐全、异常路径是否覆盖	价值是否清楚、验收条件是否可判定
变更影响面	牵动流程分支和相关参与者，需同步检查异常路径	多为重写卡片、调整验收条件或重新拆分
适用需求类型	交互分支多、外部系统对接、合规验收要求高	需求演化快、需要频繁排序与拆分交付

从表中可以看出，两者的差别不在“写得多还是写得少”，而在细节被放在哪个位置、由谁在什么时点补齐。用例把细节前置到规格里，评审时一次看全；用户故事把细节后置到对话和验收条件里，评审时先确认价值和可判定性。对于既有复杂交互又需要快速排期的产品，常见做法是让故事承担待办和优先级，让用例承担其中复杂流程的完整规格，两者在同一需求上并存。

表达结构：用例的主流程与用户故事的卡片

两种方法的信息放置方式不同，直接影响了写作投入和读者门槛。用例要求作者在动笔时就想清楚边界和分支，写作成本高，但产出物可以脱离作者被独立阅读；用户故事写作成本低，卡片本身不足以支撑开发，需要配合验收条件和持续对话。

用例的组成与写法要点

• 参与者：明确谁在系统外部发起或接收这次交互，包括主要参与者和支撑性参与者。
• 前置条件：写清用例启动时系统与数据需要处于什么状态。
• 主成功场景：按步骤写出一次顺利完成的交互路径，每步说明谁做什么、系统如何响应。
• 备选与异常流程：列出主流程在哪些节点可能分叉，以及分叉后系统如何处理。
• 后置条件：说明用例结束后系统状态发生了什么变化。

写法上，主成功场景保持一条主线，分支用编号挂回主流程的对应步骤，避免把多个目标混进同一个用例。参与者列表要覆盖触发这次交互的所有外部角色，包括定时任务、外部系统这类非人类参与者。

用户故事的组成与写法要点

• 角色：说明这条需求为谁而做。
• 目标：说明该角色想完成什么动作。
• 价值陈述：说明完成这个目标带来什么结果，用于排序和取舍。
• 验收条件：用可判定的表述列出满足交付的标准，通常写成若干条场景。
• 对话补充：把规则细节、边界情况留到需求澄清时与业务方和开发共同确认。

用户故事的写作要点是保持卡片简短，把无法在一句话内说清的内容拆成多条故事或转入验收条件。卡片越短，排序越灵活，但对团队对话质量的要求越高；如果团队缺少稳定的澄清机制，卡片背后的细节容易在交付时才暴露。

评审时各自看什么：路径完整性还是价值与验收

评审议程应当跟着表达结构走。用例评审的核心问题是“这条路径写全了吗”，用户故事评审的核心问题是“这条需求值得做、做完能判定吗”。两者对参与角色和会议形式的要求也不同。

用例评审的检查要点

• 参与者是否遗漏，特别是外部系统、后台任务和权限不同的角色。
• 主成功场景的每一步是否有明确的系统响应，步骤之间是否存在未说明的跳转。
• 异常路径是否覆盖了输入非法、外部系统不可用、权限不足、并发冲突等常见分叉。
• 前置条件与后置条件是否与流程步骤一致，是否存在流程走完后状态无法回退的情况。

用例评审适合业务方、需求作者和开发共同参加，逐条走流程。会议形式偏向走查，时间投入较大，适合交互复杂或验收要求严格的功能。

用户故事评审的检查要点

• 价值陈述是否说清了做这件事的理由，能否据此与其他故事比较优先级。
• 验收条件是否可判定，每条条件能否对应一个明确的通过或不通过结论。
• 拆分是否合理，单条故事是否能在一次迭代内完成并独立验收。
• 依赖关系是否标注，是否依赖其他故事、外部接口或数据准备。

用户故事评审适合在迭代计划或需求澄清会上进行，参与角色以业务方、需求和开发为主，形式偏向讨论和补充。常见遗漏有两类：用例评审容易漏掉异常分支，尤其是低频但影响大的失败路径；用户故事评审容易漏掉边界条件和外部依赖，导致开发阶段才发现前置数据或接口未就绪。

需求变更时，改动落在哪里

同一个变更，在两种表达方式下的影响范围不同。用例的变更往往牵动流程分支，需要顺着参与者、前置条件和异常路径同步检查；用户故事的变更更多表现为卡片重写、验收条件调整或重新拆分，影响面集中在待办和交付节奏上。

变更类型	用例中的处理	用户故事中的处理
新增一个参与者或外部系统	补充参与者列表，检查主流程与异常流程中所有交互点	新增或拆分故事，补充验收条件中的交互场景
业务规则调整	修改对应流程步骤，同步检查受影响的备选与异常路径	重写验收条件，必要时拆分为多条故事
范围缩小	保留用例但标注暂不实现的路径，避免后续恢复时重新梳理	将故事移出当前迭代，保留在待办中并注明原因
验收标准提高	补充异常路径和边界条件，更新后置条件	增加验收条件条目，确认拆分粒度是否仍然合理

变更追溯依赖表达单元与交付物之间的对应关系。用例的追溯通常落在流程步骤上，一个变更可以定位到具体步骤和受影响的参与者；用户故事的追溯落在交付项和验收条件上，一个变更可以定位到对应的工作项和验收条目。记录变更时，建议同时写下变更原因、影响到的流程步骤或验收条件，以及需要同步检查的关联需求，避免只改正文不记录影响范围。

当需求条目、验收条件和变更记录需要在同一处被团队持续查看时，可以把它们放进工作项与文档中管理。ONES 提供项目、工作项、迭代与 Wiki 页面的工作上下文，需求条目和变更说明可以在这些载体中留存并与迭代关联；ONES Assistant 智能助手能够理解项目、工作项、迭代和 Wiki 页面等上下文，基于相关数据和团队知识回答问题并执行后续操作，适合在变更讨论后快速定位相关条目。具体由哪些模块承载需求条目与变更记录，需结合团队实际配置确认。

团队怎么选：按需求特征与协作节奏判断

选择依据可以归结为两个问题：这条需求的交互路径有多复杂，团队需要在多短的周期内完成排序和交付。路径复杂、分支多、验收要求明确的功能，用例建模能把规格一次写清；需求还在演化、需要频繁调整优先级的场景，用户故事更便于排序和拆分。

判断条件	倾向用例建模	倾向用户故事
交互分支数量	分支多，异常路径需要逐条验收	分支少，主要路径即可覆盖
外部系统对接	涉及多个外部系统或协议，交互边界需要写清	对接关系简单，可在验收条件中说明
合规与验收要求	需要留存完整规格供审计或逐条验收	验收以业务结果为主，形式要求较松
需求演化速度	需求相对稳定，规格可一次写全	需求变化快，需要频繁重排和拆分
交付节奏	按功能整体交付，周期较长	按迭代小步交付，周期较短
团队协作方式	业务方与开发需要共同走查流程	业务方参与澄清，开发自主补充细节

组合使用的路径比较清晰：用用户故事承载待办列表、优先级和迭代安排，用用例承载其中交互复杂的部分，作为故事的补充规格。一条故事可以关联一个或多个用例，验收条件引用用例中的关键路径，这样既保留了排序的灵活性，又保证复杂流程有完整的路径覆盖。

从单一方法过渡到组合使用时，建议先约定书写规范：明确哪些需求必须写用例、用例与故事的关联方式、验收条件引用到哪一层流程、变更时由谁同步更新两侧内容。规范不必一次定全，可以在两三个迭代中根据实际遗漏情况调整。对于交互简单、团队规模较小的需求，单独使用用户故事并配合清晰的验收条件通常已经够用；对于外部对接多、验收条目需要逐条核对的功能，单独使用用例建模也能独立运转。两种方法的选择最终取决于需求本身的复杂度和团队的协作节奏，而非固定的方法偏好。

常见问题

团队已经在用用户故事，什么情况下值得为部分需求补写用例？

当某条需求的交互路径复杂到验收条件难以逐条覆盖时，补写用例更划算。典型情形包括：涉及多个外部系统或协议对接、异常分支多且每条都需要验收、合规或审计要求留存完整规格。做法上可以保留故事作为待办与优先级载体，把用例作为该故事的补充规格，验收条件引用用例中的关键路径，避免两套内容各写一遍。

用例写多细才算够，会不会写成设计文档？

用例的边界是参与者与系统之间的交互目标和响应，写到流程步骤与分支即可，不展开内部实现、数据结构或界面布局。判断标准是：读者能否据此判断某条路径是否完成、验收是否通过。如果某段内容只在说明系统内部怎么实现，就超出了需求表达的范畴，应放到设计文档中。

用户故事的验收条件与用例的异常流程，能否互相替代？

两者覆盖的范围不同。验收条件通常描述满足交付的若干场景，偏向结果判定；用例的异常流程按主流程节点逐一列出分叉及系统处理方式，偏向路径覆盖。交互简单的需求，验收条件足以支撑交付；分支多、失败路径影响大的需求，仅靠验收条件容易漏掉低频异常，此时用异常流程补齐更稳妥。

两种方法并行使用时，变更应该先改哪一侧？

建议以承载交付节奏的一侧为入口：变更先落到故事卡片或待办上，确认优先级与范围，再同步更新关联用例的流程步骤与异常路径。若变更直接影响交互路径，则先改用例，再回写故事的验收条件。关键是约定同步责任人与检查点，并在变更记录中写明原因、受影响的流程步骤或验收条件，避免只改一侧造成内容不一致。

小团队需求不复杂，是否还需要引入用例建模？

交互路径少、验收以业务结果为主的需求，单独使用用户故事并配合清晰的验收条件通常已经够用，额外维护用例会增加书写与评审成本。当团队开始出现外部系统对接、权限角色分化或验收条目需要逐条核对的情况，再针对这些需求局部引入用例，比整体切换方法更平稳。