需求评审和变更管理选用例建模还是用户故事，取决于需求本身的复杂度、变更频率与影响面，以及评审参与角色和追溯要求。用例建模把参与者、前置条件、主流程、异常流程和结果写成可逐项核对的场景，适合规则复杂、异常分支多、跨系统交互的需求；用户故事用角色、目标价值和验收条件表达，颗粒度小、便于排序和迭代调整，适合需求边界尚在探索、交付节奏快的场景。两者是需求表达方式，可以组合使用。
要点总览（TL;DR）
- 用例建模与用户故事是两种需求表达方式，评审和变更管理更依赖表达是否可核对、可追溯，两者可以组合使用。
- 规则复杂、异常分支多、跨系统交互多、变更影响面大的需求，用例建模更利于逐项核对和评估连锁影响。
- 需求边界尚在探索、交付节奏快、变更以范围和优先级调整为主时，用户故事的小颗粒更便于排序和迭代调整。
- 常见组合是用户故事承载待办与优先级，用例补充关键场景、异常分支和跨系统交互的细节。
- 可选取一类代表性需求按两种表达各写一遍，比较评审问题数与变更返工情况，再确定团队的主用方式。
同一口径下，两种表达在评审与变更上的差异
用例建模与用户故事都会影响评审和变更管理的效率，但影响方式不同。把两者放在同一组维度下对照，可以看清差异来自表达单元的设计，而非流程制度的差别。评审和变更管理真正依赖的是需求表达是否可核对、可追溯：评审者能否逐项确认信息完整，变更发生时能否快速定位改动范围和影响对象。
| 对照维度 | 用例建模 | 用户故事 |
|---|---|---|
| 表达单元与颗粒度 | 以用例为单位，一个用例覆盖一个参与者目标下的完整交互，包含主流程与多条异常流程，颗粒度较大、结构完整 | 以故事为单位，一条故事描述一个角色、一个目标和一个价值点，颗粒度小，便于拆分和排序 |
| 评审可核对的内容 | 参与者是否齐全、触发条件与前置条件是否明确、主流程步骤是否完整、异常分支是否覆盖、后置结果是否定义 | 角色与目标是否清晰、价值是否成立、验收条件是否可验证、优先级是否合理 |
| 变更的定位与影响分析 | 按场景和流程步骤定位改动点，沿参与者、异常分支和关联用例展开影响面，适合评估连锁影响 | 按故事和验收条件定位改动点，沿待办列表和迭代范围展开影响面，适合快速调整优先级和排期 |
| 追溯与覆盖 | 用例与参与者目标对应，覆盖关系体现在场景与分支的完整性上，适合检查异常路径是否遗漏 | 故事与业务价值对应，覆盖关系体现在待办与验收条件的对应上，适合检查价值交付是否完整 |
| 参与角色与沟通成本 | 结构化程度高，业务方、开发、测试可围绕场景逐项讨论，前期编写成本较高 | 表达轻量，业务方容易参与讨论和排序，细节需要额外补充，跨角色对齐成本可能后移 |
用例建模在异常流程和前置条件上的表达优势最明显。一个用例会把“什么条件下触发、正常路径怎么走、哪些分支会偏离、最终达到什么状态”写在同一结构里，评审者可以逐条追问，变更时也能顺着分支判断哪些环节受影响。用户故事的优势在价值表达和排序：每条故事回答“谁要什么、为什么值得做”，团队可以按优先级排列待办、按迭代调整范围，适合需求还在探索、边界尚未稳定的阶段。
两种方式可以组合。常见做法是用用户故事承载待办列表和优先级，让团队按迭代节奏推进；对规则复杂、异常分支多或跨系统交互的关键需求，再用用例补充场景细节。这样评审时既有价值判断的依据，也有场景核对的材料，变更时既能按故事调整范围，也能按用例评估影响。
评审时各自能核对什么、核对不了什么
评审现场的核心问题是：评审者能否依据现有表达逐项确认需求信息完整。用例建模和用户故事提供的核对材料不同，需要补充的内容也不同。
用例评审可逐项核对的要素
- 参与者：谁触发这个用例，是否覆盖所有相关角色，是否存在遗漏的外部系统。
- 触发条件与前置条件：什么情况下进入这个场景，进入前必须满足哪些状态或数据条件。
- 主流程：正常路径的每一步是否清晰，步骤之间的先后关系是否明确。
- 异常流程：哪些分支会偏离主流程，每个分支的处理结果是否定义。
- 后置结果：场景结束后系统状态、数据状态和通知对象是否明确。
这套结构让评审者可以按清单逐项打勾，尤其适合业务规则多、异常处理要求高的需求。评审提出的问题通常集中在分支遗漏和条件不清，容易定位到具体步骤。
用户故事评审可核对的要素
- 角色：故事描述的是哪类用户或干系人，是否与实际使用场景一致。
- 目标价值：这条故事解决什么问题、带来什么结果，是否值得排进当前迭代。
- 验收条件：完成标准是否可验证，验收条件是否覆盖主要成功路径。
- 优先级：与其他故事的相对顺序是否合理，是否与当前交付目标一致。
用户故事评审擅长确认“做不做、先做哪个、做完算不算完成”，对价值判断和排序效率高。它的表达缺口在于细节：非功能约束（性能、权限、审计要求）、界面交互细节、复杂业务规则通常不在故事正文里，需要以验收条件、补充说明或单独的场景文档承载。如果这些内容没有另行补充，评审容易停留在价值层面，开发阶段才暴露规则冲突。
用例建模同样有表达缺口。界面布局、视觉细节、非功能指标一般不在用例结构中展开，需要借助界面说明、非功能需求条目或质量属性描述补充。评审参与角色也会影响选择：业务方和产品负责人参与度高、关注价值和优先级的评审，用户故事更易沟通；开发、测试、业务多方参与、需要逐条确认异常处理的评审，用例结构的核对效率更高。
无论采用哪种表达，评审记录都应保留“提出了什么问题、对应哪条需求、由谁确认”的信息。需求条目、评审意见和确认结论放在同一处管理，后续变更时才能回看当时的判断依据。ONES 的工作项与文档可以承载需求条目、评审记录和变更说明，让评审结论与需求条目保持关联；具体字段和流程需按团队实际配置。
变更管理中的定位、影响分析与追溯
变更管理的难点在于快速回答三个问题：改的是哪一条需求、还有哪些地方受影响、改动后如何确认没有遗漏。用例建模和用户故事提供的定位路径不同，适合的变更形态也不同。
用例建模下的变更定位
用例以场景和流程步骤组织，变更发生时可以先定位到具体用例，再定位到具体步骤或分支。影响面沿参与者、异常分支和关联用例展开：修改一个前置条件，可能影响所有依赖该条件的场景；调整一个异常分支的处理结果，可能牵动下游系统的交互约定。这种定位方式适合评估连锁影响，尤其在跨系统交互多、规则相互依赖的需求中，能帮助团队判断改动是否会波及其他场景。
用户故事下的变更定位
用户故事以故事和验收条件组织，变更发生时先定位到具体故事，再检查验收条件是否需要同步调整。影响面沿待办列表和迭代范围展开：一条故事的范围变化会影响当前迭代的排期和后续故事的顺序，团队可以据此重新排序、拆分或移出迭代。这种定位方式适合高频小改动和范围调整，响应速度快，但需要额外确认改动是否影响其他故事共享的业务规则。
变更频率与影响面是选择表达的重要条件。变更频繁、以范围和优先级调整为主的需求，用户故事的小颗粒更便于快速重排；变更影响面大、一次改动牵动多个场景和系统交互的需求，用例建模的结构更利于完整评估影响。追溯链的建立方式也随之不同：用例通过参与者目标、场景分支和关联用例建立追溯，适合检查异常路径覆盖；用户故事通过故事、验收条件和迭代范围建立追溯，适合检查价值交付进度。团队可以把需求条目、变更记录和评审结论关联在同一工作项下，使追溯不依赖个人记忆。
适配场景与选择建议
选择哪种表达，先看需求特征，再看团队协作方式。以下条件可以作为判断起点。
优先用例建模的条件
- 业务规则复杂，异常分支多，评审需要逐条确认处理逻辑。
- 需求涉及多个参与者或跨系统交互，改动容易产生连锁影响。
- 变更影响面大，需要按场景评估影响范围并检查覆盖完整性。
- 评审参与角色多，开发、测试、业务方需要围绕同一场景结构对齐。
优先用户故事的条件
- 需求边界尚在探索，优先级和范围需要频繁调整。
- 交付节奏快，团队按迭代推进，需要小颗粒的需求单元便于排序。
- 评审以价值判断和排期为主，业务方参与度高。
- 变更以范围增减和顺序调整为主，影响面相对可控。
组合使用的分工方式
多数团队不需要二选一。可行的分工是：用用户故事承载待办列表、优先级和迭代范围，让团队按价值排序推进；对规则复杂、异常分支多、跨系统交互的关键需求，用用例补充场景细节，作为评审和变更影响分析的依据。故事负责回答“做什么、先做哪个”，用例负责回答“具体怎么走、异常怎么处理”。两者通过需求条目关联，变更时先按故事调整范围，再按用例检查影响。
试点与验证方式
在全面推行前，可以选一类有代表性的需求做小范围验证：同一批需求分别用用户故事和用例建模各写一遍，组织相同角色的评审者分别评审，记录评审提出的问题数量和类型；进入开发后跟踪变更次数、变更返工范围和返工耗时。比较两组数据后，再决定团队的主用方式和组合比例。试点时保持评审角色和需求范围一致，结论才有可比性。验证结果应落到团队的需求管理约定中，明确哪类需求用哪种表达、由谁维护、变更时如何关联记录。
常见问题
团队已经用用户故事管理待办，还有必要补用例吗？
看需求类型。如果待办里以规则简单、边界清晰的功能为主，用户故事加验收条件通常够用。当某条需求涉及多个参与者、异常分支多或跨系统交互时，验收条件很难把每条分支写全，评审和变更时就容易漏项。这类需求可以单独补一份用例，作为场景核对的材料，待办和优先级仍由用户故事承载。
用例建模前期编写成本高，小团队怎么控制投入？
可以只对关键需求写用例，不必覆盖全部待办。判断标准是异常分支数量、跨系统交互和变更影响面：满足其中两项以上的需求再展开用例结构，其余需求用用户故事加验收条件表达。用例也不必一次写全，先写主流程和已知异常分支，评审中补充遗漏分支，把编写成本分摊到评审过程中。
评审时两种表达都用了，评审者应该先看哪个？
建议先看用户故事确认价值、范围和优先级，再看用例核对场景细节。顺序反过来容易陷入流程细节，忽略这条需求是否值得做。评审记录中把故事层面的结论（做不做、排在哪）和用例层面的问题（哪条分支不清、哪个条件缺失）分开记录，后续变更时能快速找到对应依据。
变更频繁时，用例维护会不会成为负担？
变更频繁且以范围增减、顺序调整为主时，用例的维护成本确实较高，因为一次范围变化可能牵动多个场景。这种情况下可以让用户故事承担变更定位，用例只保留在影响面大的关键需求上，并在变更时检查受影响的用例分支。变更记录与需求条目关联保存，能减少靠记忆判断影响范围的情况。
试点验证需要观察多久、记录哪些数据？
建议覆盖至少一个完整迭代周期，让需求从评审走到开发验证。记录三类数据：评审提出的问题数量和类型、变更次数与返工范围、返工耗时。两组试点保持评审角色和需求范围一致，结论才有可比性。试点结束后把结果写入团队的需求管理约定，明确哪类需求用哪种表达、由谁维护。
