需求建模的核心任务，是把来源分散、表述不一的原始需求，转换成可评审、可追溯、可验证的模型表达。它通常从明确建模目的和读者开始，再选择场景、流程、数据、状态或规则等视图，为模型元素建立与需求条目、验收标准的对应关系，最后通过评审定版并纳入变更维护。下面按“选视图—六步流程—角色分工—示例—完成检查”的顺序展开。
要点总览（TL;DR）
- 需求建模先定目的和读者：沟通对齐优先场景视图，规格说明补流程与数据视图，验证验收看状态机与规则表，影响分析靠追溯关系。
- 按六步推进：收集编号原始需求、选视图定规范、绘制并挂接需求条目、补验收标准与异常分支、组织评审记录结论、定版入库并建立变更维护机制。
- 每个模型元素都要能指回需求条目，每条关键需求也要能找到承载它的模型元素，双向追溯是定版的前提。
- 定版前按完整性、一致性、可读性、追溯性四类逐项检查，任一阻断条件未消除就不定版。
- 模型随需求一起维护：需求变更时由需求负责人触发复查，建模者更新元素，测试同步确认验收标准是否仍有效。
需求建模先定目的：选对视图再动手
动手画图之前，先回答一个问题：这个模型给谁看、用来解决什么判断。建模目的不同，需要突出的信息也不同。用于业务与研发沟通对齐时，重点是让双方对同一场景的理解一致；用于规格说明时，重点是边界、输入输出和处理规则写清楚；用于验证验收时，重点是异常分支和状态转换可被测试；用于影响分析时，重点是模型元素能回溯到需求条目，变更时知道会牵动哪些部分。
常见视图各有擅长的表达对象。用例或场景视图描述谁在什么条件下做什么、得到什么结果，适合澄清业务目标和主流程；业务流程视图描述跨角色、跨环节的活动顺序与交接，适合说明协作关系；数据模型描述业务对象、属性和关系，适合规格说明和后续设计衔接；状态机描述对象在生命周期内的状态与迁移条件，适合订单、工单、审批等有明确状态的需求；规则表把判断条件与结果成组列出，适合折扣、权限、计费等规则密集的需求。
选择视图可以用三个判断问题：第一，读者最需要确认的是“做什么”还是“怎么做”，前者优先场景视图，后者补充流程与规则；第二，需求中是否存在明显的状态流转，如果有，状态机应纳入最小组合；第三，是否存在大量条件组合，如果有，用规则表替代散落在文字里的判断句。多数需求不需要画全所有视图，一个可评审的最小组合通常是：一张场景或流程视图说明主线和角色，一张状态视图或规则表覆盖关键分支，再配一份模型元素与需求条目的对应表。
| 建模目的 | 主要读者 | 优先视图 | 需要回答的问题 |
|---|---|---|---|
| 沟通对齐 | 业务代表、产品、开发 | 用例/场景、业务流程 | 谁在什么场景下完成什么目标 |
| 规格说明 | 开发、测试、设计 | 业务流程、数据模型、规则表 | 输入输出、对象关系、处理规则是否明确 |
| 验证验收 | 测试、业务验收人 | 状态机、规则表、场景 | 异常分支和状态迁移是否可被用例覆盖 |
| 影响分析 | 需求负责人、开发负责人 | 追溯关系、流程与数据视图 | 变更会牵动哪些模型元素和需求条目 |
六步建模流程：每步的输入、动作与输出
把建模拆成六步，目的是让每个环节都有明确的进入条件和完成标志，避免模型画到一半才发现需求来源不清或验收标准缺失。以下步骤可按项目规模裁剪，但输入、动作、输出和完成标志这四项建议保留。
步骤一：收集并编号原始需求
输入是需求来源材料，包括业务方提出的诉求、访谈记录、现有系统的问题清单、合同或制度约束。动作是逐条整理成可独立识别的需求条目，赋予稳定编号，标注来源、提出人和适用范围。输出是一份编号后的原始需求清单。完成标志是每条需求都能找到来源，范围边界有明确说明，重复和冲突条目已被标记待澄清。
步骤二：选定视图并约定粒度与命名规范
输入是步骤一的需求清单和S1中的目的—视图对照。动作是根据建模目的确定使用哪些视图，约定模型粒度（例如流程细化到角色活动还是系统操作）、元素命名规则（统一使用业务术语，避免同一对象多个叫法）和图例。输出是一份建模约定说明。完成标志是参与建模的人对视图范围、命名和粒度达成一致，后续新增元素有据可依。
步骤三：绘制模型并逐元素挂接需求条目
输入是建模约定和需求条目。动作是按视图绘制模型，每新增一个模型元素，同步记录它来源于哪条需求、服务于哪个业务目标。输出是模型初稿和元素—需求对应表。完成标志是模型中每个元素都能指回至少一条需求条目，没有无来源的元素，也没有完全未被模型承载的关键需求。
步骤四：补充验收标准与异常分支
输入是模型初稿和需求条目中的业务规则。动作是为主流程补充可验证的验收标准，为状态迁移、规则判断补充异常和边界条件，检查模型是否覆盖了需求中提到的失败、超时、取消、重复提交等情况。输出是带验收标准和异常分支的模型版本。完成标志是每条关键需求至少对应一条可执行的验收标准，主要异常路径在模型中有明确表达。
步骤五：组织评审并记录问题与结论
输入是待评审模型、需求条目和验收标准。动作是组织业务代表、开发、测试共同评审，逐项核对模型是否准确表达需求、验收标准是否可测、异常分支是否遗漏，评审中提出的问题和结论逐条记录，明确修订责任人和期限。输出是评审记录和修订后的模型。完成标志是所有评审问题都有处理结论，未关闭问题有明确责任人和计划。
步骤六：定版、入库并建立变更维护机制
输入是评审通过的模型和评审记录。动作是将模型定版，与需求条目一起纳入统一管理，约定需求变更时模型同步更新的触发条件和责任人。输出是定版模型、版本记录和变更维护约定。完成标志是模型版本可查、变更路径清晰，后续需求调整能触发对应模型元素的复查。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、收集编号 | 来源材料、访谈记录、问题清单 | 整理条目、编号、标注来源与范围 | 编号后的原始需求清单 | 每条需求可溯源，冲突已标记 |
| 二、选视图定规范 | 需求清单、目的—视图对照 | 确定视图、粒度、命名和图例 | 建模约定说明 | 参与者对范围和命名达成一致 |
| 三、绘制并挂接 | 建模约定、需求条目 | 绘制模型，逐元素记录来源需求 | 模型初稿、元素—需求对应表 | 元素与需求双向可指认 |
| 四、补验收与异常 | 模型初稿、业务规则 | 补验收标准、异常和边界分支 | 带验收标准的模型版本 | 关键需求均有可执行验收标准 |
| 五、组织评审 | 待评审模型、验收标准 | 逐项核对，记录问题与结论 | 评审记录、修订后模型 | 问题均有结论或明确责任人 |
| 六、定版维护 | 评审通过的模型、评审记录 | 定版入库，约定变更触发与责任人 | 定版模型、版本记录、维护约定 | 版本可查，变更路径清晰 |
角色分工与各环节交付物
建模不是一个人的工作。需求负责人对需求条目的完整性和优先级负责，业务代表提供业务规则和验收判断，建模者负责视图表达和元素挂接，开发和测试从可实现、可测试的角度参与评审，评审者对结论负责。角色可以兼任，但职责要写清楚，否则容易出现模型画完没人认、评审问题没人跟的情况。
| 角色 | 主要职责 | 输入 | 输出/交付物 |
|---|---|---|---|
| 需求负责人 | 组织需求收集、编号、范围确认和变更管理 | 业务诉求、来源材料 | 编号需求清单、变更记录 |
| 业务代表 | 提供业务规则、确认场景和验收判断 | 业务制度、实际操作经验 | 业务规则说明、验收意见 |
| 建模者 | 按约定绘制模型，维护元素与需求条目的对应 | 需求清单、建模约定 | 模型初稿、元素—需求对应表 |
| 开发 | 评估模型的可实现性，指出边界和接口问题 | 模型初稿 | 技术可行性意见、评审问题 |
| 测试 | 检查验收标准和异常分支是否可测 | 模型、验收标准 | 可测性意见、补充用例建议 |
| 评审者 | 组织评审、确认结论、跟踪问题关闭 | 待评审模型、评审记录 | 评审结论、问题跟踪记录 |
追溯关系建议由需求负责人和建模者共同维护：需求负责人保证需求条目编号稳定，建模者保证模型元素挂接准确。评审时由评审者抽查双向追溯是否成立，即从模型元素能找到来源需求，从需求条目能找到承载它的模型元素。需求变更发生后，由需求负责人触发模型复查，建模者更新对应元素，测试同步检查验收标准是否仍然有效。
当需求条目、模型和评审记录分散在不同工具中时，追溯维护成本会明显上升。ONES 的需求管理相关产品可以把需求条目、工作项和评审记录放在同一套项目数据中管理，便于在变更时定位受影响的条目；ONES Assistant 智能助手能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，基于相关项目数据和团队知识回答问题，并直接执行后续操作。例如在整理阶段，可以将 PRD 拆解为需求和任务并按模块分配负责人，这一能力在官方页面以示例指令形式展示，实际效果以产品实际使用为准。模型视图本身的原生绘制能力，需结合具体产品版本确认。
一个订单需求建模示例：从原始需求到可评审模型
以下示例为演示情景，用于说明步骤如何落到模型元素，不代表真实项目数据。
原始需求条目示例：REQ-001，客户提交订单后，系统需在库存充足时生成待支付订单；REQ-002，订单支付超时后自动取消并释放库存；REQ-003，客户可在待支付状态下主动取消订单；REQ-004，已支付订单不允许客户自行取消，需走退款流程。四条需求分别标注来源为业务方访谈和现有系统问题清单。
按S1的判断，这组需求存在明显的状态流转，最小组合选择场景视图加状态视图。场景视图描述“客户提交订单—系统校验库存—生成待支付订单—客户支付或取消”的主线，标注客户和系统两个角色；状态视图定义订单状态为“待支付、已支付、已取消、退款中”，迁移条件分别对应支付成功、支付超时、客户取消和退款申请。
| 模型元素 | 来源需求 | 验收标准 |
|---|---|---|
| 场景：提交订单并校验库存 | REQ-001 | 库存充足时生成待支付订单；库存不足时给出明确提示且不生成订单 |
| 状态迁移：待支付→已取消（超时） | REQ-002 | 超过约定支付时限后订单状态变为已取消，库存数量恢复 |
| 状态迁移：待支付→已取消（客户取消） | REQ-003 | 客户在待支付状态取消后订单关闭，重复取消不产生二次释放 |
| 状态约束：已支付不可直接取消 | REQ-004 | 已支付订单取消入口不可用，只能发起退款申请 |
评审中常见的问题及修订：一是REQ-002的“支付超时”未说明时限来源，修订为在需求条目中补充时限配置项，并在状态迁移上标注条件引用；二是REQ-003未说明重复取消的处理，修订为在场景中补充幂等要求并写入验收标准；三是状态视图初稿遗漏“退款中”状态，评审发现后补充该状态及其迁移条件，并回挂到REQ-004。修订完成后，四条需求均有模型元素承载，每个模型元素也能回溯到对应需求条目。
建模完成检查：定版前逐项核对
定版前用一份检查清单逐项判断，比凭印象确认更可靠。以下检查项按完整性、一致性、可读性和追溯性四类组织，每项给出通过标准和阻断条件。
| 检查类别 | 检查项 | 通过标准 | 阻断条件 |
|---|---|---|---|
| 完整性 | 需求条目是否都有模型承载 | 每条在范围内的需求至少对应一个模型元素 | 存在关键需求无任何模型表达 |
| 完整性 | 异常分支是否覆盖 | 需求中提到的失败、超时、取消、重复提交在模型中有表达 | 主要异常路径缺失且无说明 |
| 一致性 | 模型与需求描述是否一致 | 模型中的角色、对象、条件与需求文字表述一致 | 模型与需求存在相互矛盾的规则 |
| 一致性 | 验收标准是否可执行 | 每条关键需求对应至少一条可判断通过与否的标准 | 验收标准只有“正常可用”等无法判断的表述 |
| 可读性 | 命名与粒度是否统一 | 同一对象使用同一术语，同类元素细化程度一致 | 同一对象出现多个名称导致理解歧义 |
| 可读性 | 图例与说明是否齐全 | 符号、颜色、缩写有统一说明 | 读者无法独立理解模型含义 |
| 追溯性 | 模型元素能否回溯需求 | 每个元素可指认来源需求条目 | 存在无来源元素且无法说明用途 |
| 追溯性 | 需求条目能否找到模型 | 从需求条目可定位承载它的模型元素 | 关键需求无法定位对应模型 |
完成条件建议设为：完整性、一致性、追溯性三类检查全部通过，可读性问题已记录并有处理计划；评审问题全部关闭或有明确责任人和期限；模型版本与需求条目版本对应关系已记录。任一阻断条件未消除时，模型不定版，避免把问题带入后续设计和测试环节。定版后，需求变更触发模型复查的约定同步生效，模型随需求一起维护。
常见问题
需求建模一定要把所有视图都画一遍吗？
不需要。视图是表达工具，按建模目的和读者取舍即可。多数需求的最小组合是：一张场景或流程视图说明主线和角色，一张状态视图或规则表覆盖关键分支，再配一份模型元素与需求条目的对应表。只有当需求同时涉及跨角色协作、状态流转和大量条件组合时，才需要组合更多视图。视图越多，维护成本越高，定版后同步更新的负担也越重。
原始需求本身写得含糊，还能开始建模吗？
可以先做标记，不宜直接建模。步骤一要求每条需求能溯源、范围边界清楚，含糊或冲突的条目应标记为待澄清，交由需求分析与澄清环节处理，再进入建模。如果强行把含糊需求画成模型，评审时往往只能确认“图画得对”，无法确认“需求本身对不对”，问题会被推迟到开发和测试阶段才暴露。
模型和需求条目分别放在不同工具里，追溯怎么维护？
分散存放时，追溯靠人工对照表维护，需求一多就容易失效。可行的做法是让需求条目、模型说明和评审记录共享同一套编号，并在变更时由需求负责人触发复查。ONES 的需求管理相关产品可以把需求条目、工作项和评审记录放在同一套项目数据中管理，便于在变更时定位受影响的条目；ONES Assistant 智能助手能够理解项目、工作项、迭代和 Wiki 页面等真实工作上下文，基于相关项目数据和团队知识回答问题，并直接执行后续操作。模型视图本身的原生绘制能力，需结合具体产品版本确认。
评审通过了但后续需求变更频繁，模型怎么跟得上？
把变更触发条件写进定版约定：需求条目发生范围、规则或状态变化时，由需求负责人发起模型复查，建模者更新对应元素，测试确认验收标准是否仍有效。变更记录与模型版本对应保存，便于回溯。若变更长期高频，可以缩短复查周期，或把模型粒度调整到只保留对判断有影响的部分，减少同步工作量。
小团队人手少，六步流程可以合并吗？
可以裁剪步骤，但输入、动作、输出和完成标志这四项建议保留。常见做法是把步骤一和步骤二合并为一次建模准备会，把步骤五评审与步骤四的验收标准补充合并进行；步骤六的定版与变更约定即使简化，也要明确谁触发复查。角色可以兼任，但职责要写清楚，避免模型画完没人认、评审问题没人跟。
