需求建模是把业务意图转成可评审、可开发、可验收的表达。做法是先明确这次建模要回答什么问题，再按场景选择用户故事、用例、故事地图、业务流程或验收条件，补齐角色、触发条件、规则与异常，最后通过评审和验收条件核对完成质量。本文覆盖从原始需求到可评审模型的步骤、表达方式选择、验收条件写法、角色分工与完成检查，需求内容本身的取舍归需求分析与澄清，系统架构设计与界面绘制不在本文范围。需求模型与验收条件在工具中的承载和追踪，可借助ONES的需求池、任务看板与测试管理完成。
要点总览（TL;DR）
- 需求建模先定目的与范围：要支撑价值判断、交互说明还是流程梳理，决定选哪种表达方式和详略程度。
- 从原始需求到可评审模型分五步：收集背景、拆角色场景、填表达模板、补规则异常、输出评审版本，每步都留产物。
- 用户故事适合迭代内表达价值，用例适合分支多的交互，故事地图用于切版本，业务流程用于端到端梳理，验收条件贯穿始终。
- 验收条件按给定条件、操作、预期结果编写，覆盖正常与异常路径，每条都应能转化为测试步骤。
- 完成标准是可评审、可开发、可验收：开发能据此估算提问，测试能据此写用例，业务方能据此确认意图。
先定建模目的：这次需求要回答什么问题
动笔之前先回答一个问题：这份模型要支撑哪个决策。是要判断一个想法值不值得做，还是要说清一个功能怎么交互，或是要梳理跨部门流程的衔接点。目的不同，表达方式、详略程度和参与人都不同。目的没定就开写，常见结果是模型写得很全，评审时却没人能据此做出判断。
需求建模处理的是“怎么表达”，需求分析与澄清处理的是“内容对不对、要不要做”。本文聚焦前者：把已经初步确认的业务意图，转成结构化、可核对的形式。内容层面的取舍，例如某个规则是否合理、某个场景是否值得支持，应在建模前或建模中与业务方对齐，但不作为本文的展开重点。
按目的选择表达方式，可以用下面的对应关系做起点：
- 要快速表达一个用户价值点、支撑迭代排期，用用户故事。
- 要说清一个功能在多个角色、多个分支下的交互，用用例。
- 要规划多个版本的范围与优先级，用故事地图。
- 要梳理跨角色、跨系统的端到端流转，用业务流程。
- 要让上述任何一种表达可被验证，补验收条件。
同时要划定范围。建议在建模说明中写清三件事：本次覆盖的业务环节与角色、明确不纳入的内容及原因、依赖的外部条件（如上游系统提供的数据、线下审批规则）。范围写出来，评审时才有边界可讨论，后续变更也有对照基准。
本节的产物是一份简短的建模目的与表达方式选择说明，包含：建模目的、覆盖范围、不纳入内容、选用的表达方式及理由。这份说明不必长，一页以内即可，但它决定了后面所有工作的方向。
核心操作步骤：从原始需求到可评审的模型
下面五步构成一条可重复的流程。每一步都说明输入、动作、输出和完成标志，便于按序执行，也便于中途检查进度。
第一步：收集原始需求与业务背景
输入是业务方的原始描述、相关工单或反馈记录、已有的流程文档。动作是把原始描述整理成“谁、在什么情况下、想达成什么、目前怎么处理”四要素，并标注信息来源。输出是一份原始需求清单，每条附背景说明。完成标志是每条需求都能追溯到提出人和使用场景，没有来源不明的条目。
第二步：拆分角色、场景与主流程
输入是上一步的原始需求清单。动作是识别涉及的角色（操作者、审批者、被影响方），按角色列出使用场景，再从场景中提炼主流程的起点、关键步骤和终点。输出是角色清单与场景列表，每个场景标注触发条件和期望结果。完成标志是每个场景都能对应到至少一个角色和一个明确的触发条件，主流程可以按顺序讲通。
第三步：选择并填写对应表达模板
输入是角色与场景列表。动作是按第一节确定的目的选择表达方式，并填入模板。用户故事写成“作为某角色，我希望做某动作，以便获得某价值”；用例写清参与者、前置条件、主成功场景与扩展场景；业务流程按泳道画出角色与步骤的交接。输出是填写完成的模型草稿。完成标志是每个场景都有对应的表达条目，条目中的角色与场景列表一致。
第四步：补充规则、异常与边界条件
输入是模型草稿。动作是逐条追问：有哪些业务规则约束这个动作（额度、权限、时限、状态流转）？哪些环节可能失败，失败后系统或人应如何处理？边界情况包括空数据、重复提交、并发操作、超时和权限不足。输出是附在模型上的规则清单与异常清单。完成标志是每条主流程都配有至少一组异常或边界说明，规则能指明适用对象和触发条件。
第五步：输出可评审的需求模型
输入是完整的模型草稿、规则与异常清单。动作是统一术语、检查条目之间的引用关系、补齐版本与变更说明，形成评审版本。输出是一份可评审的需求模型，包含目的说明、角色与场景、表达条目、规则与异常、验收条件初稿。完成标志是模型可以发给未参与建模的开发和测试人员阅读，对方能据此提出具体问题，而不是只能回复“再看看”。
这五步不必严格串行。场景拆分与模板填写常来回迭代，规则补充也可能反过来修正场景划分。关键是每一步的产物都留痕，便于评审时定位分歧出在哪一层。
常用表达方式怎么选：用户故事、用例、故事地图与业务流程
几种表达方式解决的是不同颗粒度的问题，实际项目中常组合使用。选择时看两个维度：要表达的是单个价值点还是完整交互，要服务的是迭代排期还是端到端梳理。
| 表达方式 | 适用场景 | 写法要点 | 产出形态 |
|---|---|---|---|
| 用户故事 | 迭代内快速表达用户价值，支撑排期与优先级讨论 | 角色、动作、价值三要素齐全；附验收条件；控制在一张卡片能说清的范围 | 故事卡片加验收条件 |
| 用例 | 交互分支多、涉及多个角色或系统参与的功能 | 写清参与者、前置条件、主成功场景、扩展场景与后置条件 | 用例说明，含主流程与扩展流程 |
| 故事地图 | 规划多个版本的范围，讨论先做哪些、后做哪些 | 按用户活动横向铺开，纵向按必要性分层，切出版本线 | 二维地图加版本切分 |
| 业务流程 | 跨部门、跨系统的端到端流转梳理 | 按角色分泳道，标出触发事件、判断分支、交接物与系统边界 | 流程图加步骤说明 |
用户故事的优势是轻、易讨论，适合需求还在演进、需要快速对齐价值的阶段。它的局限是容易丢失分支细节，因此每个故事都应配验收条件，复杂故事再下沉为用例。
用例适合把交互讲透。当同一个功能存在多种触发方式、多个角色权限差异或大量失败分支时，用例的主成功场景加扩展场景结构能把遗漏暴露出来。写用例时，扩展场景要写处理结果，而不只是列出异常名称。
故事地图解决的是范围与顺序问题。它把用户活动横向排列，把每个活动下的故事按必要程度纵向分层，再画出版本切线。这样讨论“第一版做到哪”时，依据是用户完成任务的完整程度，而不是单个故事的大小。
业务流程适合在建模早期建立全局认识，也适合在多个功能之间找衔接缺口。它的表达重点是角色交接处：谁把什么交给谁、以什么形式、失败时退回哪里。流程图上每个判断分支都应有明确的条件说明。
组合使用的常见关系是：业务流程定全局，故事地图切版本，用户故事承载迭代内交付，用例展开复杂交互，验收条件贯穿始终。不必每种都用，按目的取舍即可。
验收条件怎么写：让需求可验证
验收条件是需求模型的可验证部分，它把“做完”变成可判断的陈述。每条验收条件应对应模型中的一个具体条目，例如一个用户故事或一个用例的主成功场景，避免出现与任何条目都对不上的孤立条件。
推荐采用给定条件、操作、预期结果的结构：
- 给定：执行前的状态与前提，包括角色权限、数据状态、所处环节。
- 当：用户或系统执行的具体操作，一次只写一个动作或一组不可分的动作。
- 那么：可观察的预期结果，包括界面反馈、数据变化、状态流转和通知对象。
覆盖面上，正常路径与异常路径都要写。正常路径对应主成功场景；异常路径至少覆盖输入不合法、权限不足、重复操作、依赖服务不可用和超时五类中与本需求相关的部分。边界条件如数量上限、时间临界点、空数据，也应转化为具体的验收条件。
下面是一个填写模板，可直接套用：
| 字段 | 填写要求 | 示例（演示情景） |
|---|---|---|
| 关联条目 | 指向故事或用例编号 | 故事 S-012 提交报销单 |
| 给定 | 角色、权限、数据与环节状态 | 员工已登录，报销单处于草稿状态，金额为 800 元 |
| 当 | 一个具体操作 | 点击提交 |
| 那么 | 可观察结果 | 单据状态变为待审批，审批人收到待办，员工看到提交成功提示 |
| 类型 | 正常路径或异常路径 | 正常路径 |
验收条件与测试的衔接在于：每条验收条件应能直接转化为至少一个测试用例，测试用例的步骤对应“当”，断言对应“那么”。评审时可以用这个标准反向检查：一条验收条件如果写不出对应的测试步骤，说明它还不够具体，需要回到模型补充细节。
需求模型与验收条件需要在工具中承载、评审和追踪。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，形成需求—任务—测试—缺陷的闭环；测试管理支持用例库的结构化组织与自定义属性，并可自动生成多维度测试报告，便于把验收条件落到用例与测试结果上。具体字段与模板配置以实际使用环境为准。
角色分工与交付物：谁建模、谁评审、谁确认
需求建模常见的失效方式是职责空转：模型有人写，但没人对内容负责，评审变成通读，确认没有明确时点。下面按角色列出职责与对应交付物。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 业务方 | 提供原始需求与业务背景，说明规则来源，确认业务意图 | 原始需求说明、业务规则清单、确认意见 |
| 需求分析人员 | 组织建模，拆分角色与场景，选择表达方式，编写模型与验收条件 | 建模目的说明、需求模型、验收条件、变更记录 |
| 开发 | 参与评审，评估可实现性与技术约束，反馈模型中的歧义 | 评审意见、技术约束说明 |
| 测试 | 参与评审，检查验收条件的可验证性，转化为测试用例 | 验收条件评审意见、测试用例 |
评审时点建议设两个：模型初稿完成后做一次范围与场景评审，重点确认目的、范围和角色场景是否遗漏；验收条件补齐后做一次可验证性评审，重点确认每条条件能否转化为测试步骤。两次评审的参与人略有差异，业务方在第一次评审中的权重更高，测试在第二次评审中的权重更高。
确认环节要落到具体的人和版本。确认意见应记录在模型版本上，注明确认人、确认时间和确认范围。后续发生变更时，变更记录应说明改了什么、为什么改、影响了哪些条目和验收条件，避免模型与口头共识脱节。
团队规模与交付节奏不同，角色可以合并，例如小团队中需求分析人员同时承担测试用例的初稿。合并时仍应保留职责边界，明确谁对内容确认负责，避免出现“都参与了、没人拍板”的情况。
完整示例：一个需求从描述到验收条件
以下为演示情景，用于说明建模过程，不代表真实客户案例。
原始需求来自业务方口述：“员工报销太慢，希望能在线提交，领导审批后财务直接处理。”这条描述包含角色、动作和期望，但缺少规则、异常和边界。
第一步整理四要素：提出人是财务负责人；使用场景是员工出差后报销；期望是缩短提交到处理的时间；现状是纸质单据线下流转。第二步拆角色与场景：角色有员工、直属领导、财务；场景包括员工填写并提交、领导审批、财务复核与打款、驳回后修改重提。主流程从员工创建单据开始，到财务完成处理结束。
第三步选择表达方式。整体流转用业务流程梳理，按员工、领导、财务三条泳道画出交接；迭代内交付用用户故事表达，例如“作为员工，我希望在线填写并提交报销单，以便不用再跑线下签字”；审批环节分支较多，用用例展开，写清主成功场景和金额超限、票据缺失等扩展场景。
第四步补规则与异常。规则包括：单笔金额上限、审批层级随金额变化、票据附件必填、提交后不可直接修改只能撤回。异常包括：审批人离职或长期不在岗时的转交、重复提交、附件上传失败、财务复核发现金额不符时的退回。每条规则和异常都标注适用对象。
第五步输出模型并编写验收条件。以“员工提交报销单”为例，验收条件可写为：给定员工已登录且单据处于草稿状态、金额 800 元、附件已上传，当点击提交，那么单据状态变为待审批、对应审批人收到待办、员工看到提交成功提示。异常路径可写为：给定单据金额超过审批阈值，当点击提交，那么系统按规则流转至上一级审批人，并在单据上显示当前审批层级。
示例中的取舍说明：本次未纳入打款环节的银行接口细节，因为该部分依赖外部系统，另行建模；未展开界面布局，因为本文聚焦需求表达；审批层级的阈值以业务方提供的规则为准，建模阶段只记录来源，不在模型中自行设定。
完成检查：需求模型是否可用
进入评审或开发前，用下面的清单逐项核对。每一项都应有明确结论，存疑项要标注并在评审中解决。
- 完整性：每个场景都有对应的表达条目；每条主流程都有起点、步骤和终点；目的说明中的范围与实际条目一致。
- 一致性：同一角色、同一对象在不同条目中的名称和定义一致；规则之间没有相互冲突；业务流程与故事、用例的衔接处对得上。
- 角色覆盖：所有涉及的角色都已识别，包括审批者、被通知方和外部系统；每个角色的权限边界有说明。
- 规则覆盖：业务规则能指明适用对象、触发条件和结果；规则来源可追溯。
- 异常覆盖：主流程配有异常与边界说明；异常处理写明了处理结果和退回路径。
- 验收条件可验证：每条条件都能转化为测试步骤；正常路径与异常路径均有覆盖；预期结果可观察。
- 评审与变更：评审意见已记录并处理；确认人和确认时间已登记；变更记录说明了改动内容与影响范围。
这份清单的判定标准是可评审、可开发、可验收：未参与建模的开发能据此估算和提问，测试能据此写出用例，业务方能据此确认意图。三项中有一项不满足，说明模型还需补充，不宜直接进入开发。
模型进入执行阶段后，需求、任务、测试与缺陷之间的追踪关系会影响变更响应速度。ONES 提供业务、产品经理与研发团队三个视角，通过统一需求池、工单与任务看板同步状态，支持 Scrum、Kanban 等模式的迭代计划与看板管理；测试管理支持用例库组织、测试报告生成与缺陷关联迭代。团队可据此把模型条目、验收条件与测试结果串起来，在需求变更时快速定位受影响的范围。具体能力与配置以实际使用环境为准。
常见问题
需求建模和需求分析是什么关系，先做哪个？
两者交替进行。需求分析判断内容对不对、要不要做，需求建模负责把已初步确认的意图表达成结构化、可核对的形式。实践中常见做法是先做一轮分析形成初步结论，再进入建模；建模过程中追问规则和异常时，往往会发现内容层面的疑问，这时回到分析环节对齐，再继续完善模型。本文只展开表达方法，内容取舍不在范围内。
团队小、需求变化快，还需要写用例和业务流程吗？
按目的取舍，不必每种都用。变化快、以迭代交付为主的团队，可以用户故事加验收条件为主，复杂交互再下沉为用例；跨部门衔接多、涉及外部系统时，补一张业务流程帮助对齐交接点。关键是保留验收条件这一层，否则故事容易丢失分支细节，测试阶段才发现歧义。
验收条件写到什么程度算够？
判断标准是能否直接转化为测试步骤：步骤对应“当”，断言对应“那么”。如果一条条件写不出具体操作和可观察结果，说明还停留在目标描述，需要回到模型补充角色、数据状态和预期反馈。正常路径之外，与本需求相关的异常和边界也要各写一条，避免只覆盖顺利情况。
评审时业务方和测试的关注点不同，怎么安排？
建议分两次评审。初稿完成后先做范围与场景评审，业务方权重更高，重点确认目的、范围和角色场景有无遗漏；验收条件补齐后做可验证性评审，测试权重更高，重点确认每条条件能否转化为用例。两次评审意见都记录在模型版本上，注明确认人和确认范围，后续变更时对照影响条目。
需求模型和验收条件在工具里怎么承载和追踪？
模型条目、验收条件与测试结果需要在同一套工具中关联，变更时才能快速定位受影响范围。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，形成需求—任务—测试—缺陷的闭环；测试管理支持用例库的结构化组织与自定义属性，并可自动生成多维度测试报告，便于把验收条件落到用例与测试结果上。具体字段与模板配置以实际使用环境为准。
