需求建模与表达是把用户需要、业务规则和期望结果，转成团队能共同理解、能评审、能验证的需求描述形式。它回答的是“用什么形式把需求说清楚”，常见载体有用户故事、用例、故事地图、业务流程和验收条件。本文只讨论需求表示这一层，需求值不值得做、优先级如何判断，属于需求分析与澄清的范围。
要点总览（TL;DR）
- 需求建模与表达是把用户需要、业务规则和期望结果转成可共同理解、可评审、可验证的需求描述形式，回答“用什么形式把需求说清楚”。
- 它包含识别需求对象、选择表达载体、补充约束与验收条件三个核心动作，典型产出有用户故事、用例、故事地图、业务流程和验收条件。
- 范围限定在需求表示层：需求是否值得做、优先级如何归需求分析与澄清，系统模块划分归架构设计，界面原型归界面设计。
- 用户故事关注角色与价值，用例关注交互流程，故事地图关注需求全景，业务流程关注跨角色交接，验收条件关注可判定的完成标准，实际使用中常组合出现。
- 常见误解是把表达形式当成分析结论、把验收条件写成功能清单、只写故事不写判定标准，三者都会让评审反复。
需求建模与表达到底指什么
需求建模与表达是一项把“想法”变成“可讨论材料”的工作。原始需要往往来自用户访谈、业务方口述、工单记录或会议纪要，内容零散、口径不一。建模与表达的任务，是识别其中涉及的角色、事件、规则和期望结果，再选择合适的形式写下来，使产品、研发、测试和业务方看到同一份描述时能得出相近理解，并能据此评审和验证。
这项工作包含三个核心动作：
- 识别需求对象：明确谁在使用、在什么业务事件下使用、受哪些规则约束、涉及哪些数据和状态变化。
- 选择表达载体：根据需求的复杂度和沟通对象，决定用用户故事、用例、故事地图、业务流程还是验收条件来承载，或组合使用。
- 补充约束与验收条件：把边界、例外、前置条件和完成标准写清楚，让需求从“描述”变成“可判定”。
典型产出包括：以角色和价值为中心的用户故事、描述参与者与系统交互的用例、按用户活动顺序铺开的故事地图、跨角色跨环节的业务流程，以及可逐条核对的验收条件。这些产出共同构成一份可评审的需求表达，而不是单一文档。
它管什么、不管什么：范围与边界
需求建模与表达的范围是“需求以什么形式呈现、如何组织”，它处理表示层的问题。需求内容本身是否成立、是否值得投入、优先级排第几，属于需求分析与澄清；系统如何分层、用什么技术实现，属于架构设计；页面长什么样、交互怎么走，属于界面设计。把这几件事混在一起，容易让“建模”变成包罗万象的口号。
| 事项 | 是否属于需求建模与表达 | 说明 |
|---|---|---|
| 选择用用户故事还是用例来描述需求 | 纳入 | 属于表达形式的选择与组织 |
| 把跨角色交接整理成业务流程 | 纳入 | 属于需求的组织与呈现 |
| 为需求补充验收条件 | 纳入 | 让需求可判定，是表达的一部分 |
| 判断这个需求是否值得做、优先级高低 | 排除 | 归需求分析与澄清 |
| 确认业务规则本身是否正确 | 排除 | 归需求澄清与业务确认 |
| 设计系统模块划分与技术方案 | 排除 | 归系统架构设计 |
| 绘制界面原型与交互细节 | 排除 | 归界面设计与交互设计 |
边界判断可以用一个例子说明：同一个“订单取消”需求，写成“作为买家，我希望取消未发货订单，以便调整购买计划”是表达；讨论“取消后库存和优惠券如何回退才合理”是分析；决定“取消逻辑放在订单服务还是库存服务”是架构设计。三者相邻，但归属不同。表达做得好，能让后两者讨论有共同基础；表达本身不替代后两者的判断。
需求建模由哪些部分组成
需求建模的结构可以理解为“对象—载体—粒度—一致性”四层。对象是素材，载体是容器，粒度决定展开程度，一致性保证各载体之间不打架。
需求对象
建模先要识别需求中反复出现的要素：用户角色（谁）、业务事件（什么时候触发）、业务规则（受什么约束）、数据与状态（哪些信息发生变化）。这些对象是后续所有表达的原材料。对象识别不清，写出来的故事和用例就会缺角色、缺条件，评审时只能靠口头补充。
表达载体与分工
不同载体承载不同信息。用户故事承载角色、目标与价值；用例承载参与者与系统之间的交互步骤和异常分支；故事地图承载需求全景与优先级顺序；业务流程承载跨角色、跨环节的活动与交接；验收条件承载可判定的完成标准。载体之间是互补关系，一份需求可以同时有故事、流程和验收条件。
表达粒度
粒度指描述展开到什么程度。概览层用故事地图或业务流程说明整体范围和环节；中间层用用户故事或用例说明单个场景；细节层用验收条件说明边界和判定标准。分层组织的好处是不同读者各取所需：业务方看概览，研发看场景，测试看判定标准。
一致性
多个载体并存时，需要互相引用与校验。用户故事应能对应到业务流程中的某个环节，验收条件应覆盖故事中承诺的价值，用例的异常分支应与业务规则一致。常见做法是给需求条目编号，在故事、流程和验收条件之间建立引用关系，评审时逐条核对，避免同一需求在不同文档里出现两种说法。
用户故事、用例、故事地图与验收条件怎么区分
这几种形式经常被混用，区别主要在关注点和适用场合。选择时先问：这次沟通要解决的是“为什么做”“系统怎么响应”“整体范围在哪”“怎样算完成”还是“跨角色怎么交接”。
| 表达形式 | 关注点 | 适用场合 | 主要产出 |
|---|---|---|---|
| 用户故事 | 角色、目标与价值 | 需求相对简单、需要快速对齐价值时 | 一句式描述加讨论要点 |
| 用例 | 参与者与系统的交互流程 | 交互步骤多、异常分支需要写清时 | 主流程、备选流程、异常流程 |
| 故事地图 | 用户活动顺序与需求全景 | 需要规划版本范围、梳理需求全貌时 | 按活动排列的故事骨架 |
| 业务流程 | 跨角色、跨环节的活动与交接 | 涉及多部门协作、审批或状态流转时 | 流程步骤、角色分工、交接物 |
| 验收条件 | 可判定的完成标准 | 任何需要明确“做到什么程度算完成”的需求 | 若干条可核对的判定语句 |
实际使用中，这些形式常组合出现。一个中等复杂度的需求，可以用故事地图确定范围，用用户故事描述单个场景，用业务流程补充跨角色交接，再用验收条件约束完成标准。用例则在交互复杂、分支较多时替代或补充用户故事。选择依据是沟通对象和风险点，而非形式本身是否“标准”。
一个具体例子：从原始需要到可评审的需求表达
以下为演示情景，用于说明建模与表达的过程。
背景与原始需要：某内部审批系统收到反馈——“报销单提交后经常不知道卡在谁那里，催办也不知道找谁”。原始需要混杂了问题描述和期望，尚未形成可评审的需求。
第一步，识别对象：角色有提交人、审批人、财务复核人；业务事件是报销单提交与流转；规则包括审批层级和超时提醒；数据与状态包括单据状态、当前处理人、流转时间。
第二步，选择载体并写出用户故事：
- 作为提交人，我希望看到报销单当前停留在哪个环节和哪位处理人，以便判断是否需要催办。
- 作为审批人，我希望在待办中看到超时未处理的单据，以便优先处理。
第三步，补充验收条件：
- 提交人打开单据详情时，能看到当前环节名称和当前处理人姓名。
- 单据每次流转后，详情页的环节与处理人信息在刷新后更新为最新状态。
- 审批人待办列表中，超过约定时限未处理的单据带有超时标识。
第四步，用业务流程补充跨角色交接：把“提交—直属审批—财务复核—归档”画成流程，标注每个环节的输入、输出和交接物，说明超时提醒在哪个环节触发。这样，故事中的“当前环节”有了明确所指，验收条件也能对应到流程节点。
常见误解纠正：
- 把表达形式当成分析结论：写完用户故事不等于需求已经想清楚。故事只是载体，规则是否合理、优先级如何，仍需分析确认。
- 把验收条件写成功能清单：“增加状态展示字段、增加超时标识”是功能罗列，不是验收条件。验收条件应描述可观察的判定结果，例如“能看到当前处理人姓名”。
- 只写故事不写判定标准：故事说明价值和意图，缺少验收条件时，测试和研发对“做到什么程度算完成”理解不一，评审容易反复。
当这些表达需要被团队持续使用和评审时，可以把需求条目、验收条件和评审记录放在同一处管理。在ONES中，需求可以作为工作项承载，验收条件以字段或检查项的形式随条目维护，评审意见和状态变更留在同一条记录上，方便后续追溯需求从提出到完成的表达演变。
常见问题
需求建模与表达和需求分析是什么关系，先做哪一个？
两者是相邻但不同的工作。需求分析回答“这个需求是否成立、值不值得做、优先级如何”，需求建模与表达回答“用什么形式把它写清楚”。实际项目中两者往往交替进行：先用分析确认问题与范围，再用故事、流程或验收条件把结论表达出来；表达过程中发现规则不清，又回到分析环节澄清。把表达当成分析的替代，容易写出形式完整但内容未经确认的需求。
小需求也需要建模吗，直接写一句话不行吗？
表达形式的繁简应与需求复杂度和沟通风险匹配。角色单一、规则简单、团队理解一致的小需求，一句用户故事加一两条验收条件通常足够。涉及多角色交接、状态流转或异常分支的需求，仅靠一句话容易在评审和测试阶段产生分歧，这时补充业务流程或用例更划算。判断标准是：参与方能否仅凭现有描述得出一致理解并判定完成。
验收条件和测试用例是一回事吗？
两者处于不同阶段。验收条件属于需求表达的一部分，用可观察的判定语句说明“做到什么程度算完成”，例如“提交人能看到当前处理人姓名”；测试用例是测试设计产物，描述具体操作步骤、输入数据和预期结果。验收条件为测试用例提供依据，测试用例则把验收条件展开为可执行的验证过程。验收条件写得含糊，测试用例就容易偏离需求本意。
用户故事和用例应该二选一，还是可以同时使用？
可以同时使用，取决于要表达的信息。用户故事适合快速对齐角色、目标与价值，篇幅短、便于讨论；用例适合把参与者与系统的交互步骤、备选流程和异常分支写清楚。交互复杂、分支较多的需求，可以在用户故事之下补充用例；交互简单的需求，用户故事加验收条件即可。关键是避免同一信息在两处出现不一致，必要时用需求编号建立引用关系。
团队对同一需求的理解总是不一致，该从哪一步改起？
先检查表达是否覆盖了角色、触发事件、业务规则和完成标准这四类信息。常见缺口是只写了功能意图，没写谁在什么条件下使用、异常情况如何处理、怎样判定完成。可以先用业务流程把跨角色交接画清楚，再为每个环节补用户故事和验收条件，并在评审时逐条核对故事与流程节点是否对应。表达一致之后，理解分歧通常会明显减少。
