需求建模的具体做法，是先判断这条需求要表达什么：用户要完成的任务、系统与参与者的交互、跨角色的业务流转，还是交付时的判定条件。对象不同，选用的模型也不同。接着按“输入—建模动作—产出物—完成标志”推进，让模型能被复述、估算和测试。本文按这一主线给出模型选择表、操作步骤、写法示例和完成检查清单，并说明需求条目、评审流转与验收条件如何在ONES中承载。
要点总览（TL;DR）
- 需求建模先判断表达对象：用户任务用用户故事或故事地图，系统交互用用例，跨角色流转用业务流程图，交付判定用验收条件；同一需求可组合多种模型，但要指定主模型。
- 按“收集输入—拆分场景—识别角色与主流程—补充异常分支与验收场景—组织评审定稿”五步推进，每一步都有可见产出物和完成标志。
- 故事卡写清角色、目标、价值三段；验收条件用“给定—当—则”描述前置状态、动作和可观察结果，一个故事对应多个场景覆盖正常、边界与失败路径。
- 用例需包含参与者、前置条件、主流程、备选流程和后置结果；流程图按角色分泳道，跨泳道连线标注交接物，驳回、超时、撤回等回退路径显式画出。
- 建模完成以检查清单判定：需求编号唯一并关联模型、验收条件可判定、异常路径已覆盖、干系人已确认、模型版本与变更同步，全部通过再进入开发。
先定建模对象：四类需求各用什么模型
需求建模的第一步是判断表达对象，再选模型。直接套模板容易出现两种偏差：用用户故事描述复杂的跨部门审批，遗漏分支；或用流程图承载单个角色的操作目标，读起来冗长。先分清对象，模型才有稳定的边界。
| 需求对象 | 要回答的问题 | 首选模型 | 适用条件 |
|---|---|---|---|
| 用户任务 | 谁在什么情况下要达成什么目标，价值是什么 | 用户故事、故事地图 | 需求以角色价值为主，交互细节可在后续补充 |
| 系统交互 | 参与者通过哪些步骤与系统完成一次完整交互 | 用例 | 存在明确参与者和系统边界，需要描述主流程与备选流程 |
| 跨角色流转 | 一项业务在多个角色或部门之间如何交接和推进 | 业务流程图（含泳道） | 涉及两个以上角色、系统或组织的交接 |
| 交付判定 | 做到什么程度算完成，如何验证 | 验收条件（场景描述） | 需要测试或业务方对结果做可判定确认 |
用户故事适合把角色、目标与价值写在一张卡片上，故事地图则把多条故事按用户活动顺序铺开，用于版本切分。用例适合描述一次完整交互的前置条件、主流程和备选流程。业务流程图标清角色之间的交接点和回退路径。验收条件把“完成”转成可判定的场景。
同一需求可以组合多种模型，但需要指定一个主模型。主模型决定评审时以哪份材料为准，其他模型作为补充。例如一条报销需求以业务流程为主模型，用户故事用于说明提交人的目标，验收条件用于定义审批通过和驳回的判定。主模型不明确时，评审容易在不同材料之间来回对照，结论难以收敛。
从原始需求到模型的操作步骤
建模不是一次写完，而是按固定顺序推进：先收集输入，再拆分场景，然后产出模型，最后用完成标志判断是否可以交给下游。每一步都应有可见的产出物，避免停留在讨论层面。
第一步：收集输入
输入包括需求来源（业务方提出的问题、用户反馈、制度要求）、干系人名单和现有流程材料。现有材料可以是旧版流程说明、表单、操作截图或历史工单。输入不完整时，先记录缺口，再进入建模，避免在建模过程中反复补背景。
完成标志：能说清这条需求由谁提出、影响哪些角色、当前做法是什么。
第二步：拆分场景
把一条笼统的需求拆成若干可独立描述的场景。拆分依据是触发条件和结果差异，例如“首次提交”“修改后重新提交”“超时未处理”。每个场景应能对应一个明确的开始状态和一个可观察的结果。
完成标志：场景清单没有重叠，每个场景能用一句话说明触发条件和期望结果。
第三步：识别角色与主流程
列出参与角色，区分直接操作者和受影响者。然后写主流程：从触发开始，按步骤写到结果产生。主流程只写正常路径，异常和回退放到下一步处理。
完成标志：每个角色都有明确动作，主流程步骤之间没有跳跃。
第四步：补充异常分支与验收场景
针对每个主流程步骤，问三个问题：输入不合法会怎样、权限不足会怎样、中途放弃会怎样。把答案写成备选流程或异常路径。随后为关键结果写验收场景，确保每个场景都有可判定的预期。
完成标志：开发能据此估算工作量，测试能据此设计用例。
第五步：组织评审并定稿
评审时让业务方复述场景，让开发指出实现上的不确定点，让测试确认验收条件是否可判定。评审记录与模型版本一并留档，后续变更在原模型上修订并标注版本。
完成标志：干系人能复述主要场景，评审意见已闭环，模型有明确版本。
用户故事与验收条件的写法
故事写得空泛，通常是因为缺少角色、目标或价值中的一项，或者把实现方式写进了故事。验收条件写得空泛，通常是因为只写“正常完成”，没有给出可观察的判定依据。
故事卡的三段式
一张故事卡包含三段：作为某类角色，我希望完成某个动作，以便获得某种价值。角色要具体到业务身份，动作要指向可观察的行为，价值要说明为什么值得做。示例：作为门店店长，我希望在提交补货申请后看到预计到货时间，以便安排货架陈列。
判断标准：去掉任意一段，故事都会失去评审依据。如果价值段写不出来，说明这条需求可能只是实现任务，需要回到上游确认目的。
验收条件的场景结构
验收条件用“给定—当—则”描述：给定某个前置状态，当发生某个动作，则产生某个可观察结果。示例：给定补货申请已提交且库存中心有可用数据，当店长打开申请详情，则显示预计到货日期和对应仓库。
一个故事通常对应多个验收场景，覆盖正常路径、边界条件和失败路径。场景数量以能判定完成为准，不必为每个字段单独写一条。多个场景之间应避免重复描述同一结果。
拆分过大的故事
故事过大时，按场景或角色拆分，保留每条故事的价值完整性。例如把“补货管理”拆成“提交补货申请”“查看预计到货时间”“撤回未受理申请”，每条都能独立交付和验证。按技术层次拆分容易产生无法独立验收的片段，应谨慎使用。
用例与业务流程图的建模要点
用例和流程图解决的是交互与流转的表达问题。两者的共同要求是粒度一致、边界清楚、异常可见。粒度以能支撑评审和测试为准，过细会增加维护成本，过粗则无法指导实现。
用例的组成
一个用例应包含参与者、前置条件、主流程、备选流程和后置结果。参与者是直接与系统交互的角色，不包括仅接收通知的旁观者。前置条件写系统或业务必须已满足的状态，后置结果写用例结束后可观察的变化。
主流程按交互顺序编号，每一步写清谁发起、系统如何响应。备选流程标明从主流程哪一步分叉、在什么条件下触发、最终回到哪一步或如何结束。备选流程需要显式写出，不能只在正文中一句“异常情况另行处理”。
业务流程图的泳道与交接
流程图按角色或系统划分泳道，每个步骤放在实际执行者的泳道内。跨泳道的连线就是交接点，应在连线上标注交接物，例如表单、审批单或状态变更。交接点是最容易产生误解的位置，标注清楚可以减少评审争议。
异常与回退路径必须画出，包括驳回、超时、撤回和重新提交。回退箭头应指向明确的步骤，避免出现无法判断回到哪里的循环。流程图的起止点各一个，分支汇合处标明条件。
粒度判断
如果评审时有人问“这一步谁做、做完交给谁”而图上无法回答，说明粒度过粗；如果图上出现大量只涉及单个字段的步骤，说明粒度过细。合适的粒度是每个步骤都能对应一个责任角色和一个可检查的产出。
角色分工与各环节交付物
需求建模需要多方参与，但主导责任应集中。需求负责人对模型的完整性和一致性负责，业务方对场景和验收条件负责，开发和测试从各自角度参与评审。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 需求负责人 | 组织输入收集、拆分场景、主导建模与评审 | 场景清单、主模型、评审记录 |
| 业务方 | 确认场景真实性、确认验收条件 | 场景确认意见、验收条件确认 |
| 开发 | 参与可行性评审，指出实现不确定点 | 技术可行性意见、估算结论 |
| 测试 | 依据验收条件设计用例，检查可判定性 | 测试用例草案、验收条件修改建议 |
评审记录应包含参与人、评审日期、提出的问题和处理结论。模型版本与需求条目关联，变更时保留历史版本，便于追溯某次修改的原因。需求条目、评审流转和验收条件的关联可以在ONES中承载：需求条目作为唯一编号的载体，评审意见随条目流转，验收条件与条目关联，变更后保留版本记录，方便开发和测试在同一处查看定稿内容。
一个完整示例：从需求描述到可评审模型
以下示例为演示情景，用于说明各模型的衔接关系。
原始需求描述：业务方提出“员工出差回来后报销太慢，希望能在线提交并看到审批进度”。
拆出的用户故事：作为出差员工，我希望在线提交报销单并查看审批进度，以便安排个人资金。作为财务审核员，我希望看到报销单对应的出差申请，以便核对费用范围。
验收场景一：给定员工已完成出差申请且报销单必填项完整，当员工提交报销单，则系统生成报销单号并显示“待审核”。验收场景二：给定报销单缺少发票附件，当员工提交，则提示缺少附件并阻止提交。验收场景三：给定审核员驳回报销单，当员工打开详情，则显示驳回原因和可修改入口。
用例主流程：员工创建报销单—上传附件—提交；系统校验必填项—生成单号—通知审核员；审核员查看关联出差申请—通过或驳回；系统更新状态—通知员工。备选流程包括附件缺失、金额超出出差申请范围、审核超时自动提醒。
流程图中的跨角色交接：员工泳道提交后交接给系统泳道校验，校验通过后交接给财务审核员泳道；驳回时从审核员泳道回退到员工泳道，交接物为驳回原因。
评审时提出的修改：业务方指出“审批进度”应包含当前处理人；测试指出驳回场景需要区分“可修改”和“需重新提交”两种状态；开发指出金额校验依赖出差申请数据，需明确数据不可用时的处理。修改后定稿，模型版本记为V1.1，需求条目关联故事、用例和验收场景。
建模完成检查清单
建模是否可以进入开发，用以下条目逐项核对。全部通过再交付下游，未通过项记录责任人和处理期限。
- 每个需求有唯一编号，并关联主模型和补充模型。
- 主模型已指定，评审以主模型为准。
- 每条验收条件可判定，包含前置状态、动作和可观察结果，没有“正常”“合理”等模糊表述。
- 异常路径已覆盖：输入不合法、权限不足、超时、驳回、撤回均有对应描述。
- 跨角色交接点在流程图中标注了交接物。
- 业务方已确认场景和验收条件，开发和测试已参与评审。
- 评审意见已闭环，未决问题有明确责任人和时间。
- 模型版本与需求变更同步，历史版本可追溯。
- 开发能据此估算，测试能据此设计用例，干系人能复述主要场景。
清单通过后，模型进入开发和测试环节。后续需求变更时，先更新需求条目和主模型，再同步验收条件，保持编号和版本一致，避免开发与测试依据不同版本的材料推进。
常见问题
一条需求既写了用户故事又画了流程图，评审时以哪个为准？
需要事先指定一个主模型，评审以主模型为准，其他模型作为补充材料。主模型的选择取决于这条需求的核心问题：如果重点是角色价值和版本切分，以用户故事或故事地图为主；如果重点是跨部门交接和回退路径，以业务流程图为主。主模型不明确时，评审容易在不同材料之间来回对照，结论难以收敛。补充模型的作用是解释主模型中没有展开的部分，例如用验收条件定义流程图中某个分支的判定结果。
场景拆分到什么程度算合适，拆得太细会不会增加维护负担？
拆分的判断依据是触发条件和结果差异，而不是步骤数量。每个场景应能对应一个明确的开始状态和一个可观察的结果，场景之间不重叠。如果两个场景的触发条件和期望结果相同，只是操作路径略有差异，可以合并为一个场景并在验收条件中补充分支。拆得过细会让场景清单膨胀，后续变更时难以同步；拆得过粗则无法支撑估算和测试。实际操作中，以“开发能据此估算、测试能据此设计用例”作为粒度参考。
业务方时间有限，无法全程参与建模，哪些环节必须由业务方确认？
业务方至少需要在两个节点参与：一是场景确认，确认拆分出的场景真实反映了业务实际做法，没有遗漏关键情况；二是验收条件确认，确认“给定—当—则”描述的判定结果符合业务预期。这两个节点决定模型是否表达了正确的业务意图，其他建模动作可以由需求负责人主导完成。评审记录中应写明业务方确认的范围和日期，后续需求变更涉及场景或验收条件时，需要再次确认。
需求变更后，已经定稿的模型怎么处理？
变更时先更新需求条目和主模型，再同步受影响的补充模型和验收条件，保持编号和版本一致。历史版本保留，标注修改原因和修改人，便于追溯。如果变更只影响某个分支，可以在原模型上修订并升版本号；如果变更改变了需求对象，例如从单个角色操作扩展为跨部门流转，则需要重新判断主模型是否仍然适用。开发和测试应依据同一版本的定稿材料推进，避免依据不同版本工作。
验收条件写多少条才算覆盖完整？
数量不是标准，覆盖范围才是。一个故事通常需要覆盖正常路径、边界条件和失败路径三类场景。正常路径验证主要结果能够产生；边界条件验证临界值、空值和数据不可用时的表现；失败路径验证输入不合法、权限不足、超时或驳回时的处理。每条验收条件都应包含前置状态、动作和可观察结果，避免“正常完成”“合理提示”这类无法判定的表述。场景之间有重复描述同一结果时，合并为一条即可。
