需求表达规范要解决的是同一条需求能否被开发估算、被测试验证、被评审挑出歧义。本文用一个演示情景——电商订单在待发货状态下修改收货地址——完整填写用户故事、用例、验收条件与故事地图位置，并逐项解释每个字段的写法依据，最后归纳可迁移到其他需求的步骤与适用边界。
要点总览（TL;DR）
- 一条合格的需求表达要同时交代角色、目标、业务规则和验收条件，让开发能估点、测试能写用例、评审能发现歧义。
- 用户故事写“谁在什么状态下想达成什么结果”，把交互方案留给设计环节；业务规则单独列出时间窗口、次数限制和状态前置条件。
- 验收条件用给定/当/那么写成可观察的断言，并与业务规则、异常分支一一对应；已发货、超出配送范围等分支要和主流程同批写完。
- 换一条需求可按五步套用：定角色与目标、补业务规则、写验收条件、同批写异常分支、放回故事地图检查重复与遗漏。
- 多角色长流程、方向未定的探索性需求、涉及系统间交互时，应改用用例、问题陈述或补充接口说明，单条用户故事难以承载。
示例目标：一份合格的需求表达要交代清楚什么
本文的示例情景设定为：买家在电商平台下单并完成支付，订单处于待发货状态，此时买家希望把收货地址改成另一个地址。这个情景足够小，可以在一页内写完整；又包含状态判断、业务规则和异常分支，能体现需求表达的典型难点。全文围绕这一条需求展开，不涉及订单系统的架构设计或页面交互稿。
判断一份需求表达是否合格，可以用下面五项清单逐条核对。这五项也是后文示例要验证的对象：
- 角色明确：能指出是谁提出诉求、在什么身份和状态下提出，而不是笼统写“用户可以修改地址”。
- 目标与方案分离：写清楚用户想达成什么结果，把“怎么实现”留给设计环节，避免需求条目提前锁死方案。
- 业务规则可枚举：时间窗口、次数限制、状态前置条件等规则单独列出，每条规则都能被追问和确认。
- 验收条件可测试：测试人员读完能直接写出测试用例，不需要再向产品经理口头确认预期结果。
- 异常分支有交代：已发货、地址超出配送范围等情况有明确处理方式，不留给开发自行推断。
这五项分别对应开发、测试、评审三个视角：开发能据此估点，测试能据此写用例，评审能据此发现歧义。任何一项缺失，需求条目在流转中就会产生返工。
完整示例：订单修改收货地址的需求条目
以下为演示情景下完整填写的需求条目，可直接作为填写样式的对照。示例中的规则数值仅用于说明写法，实际项目中应按业务约定确定。
用户故事
作为已下单且订单尚未发货的买家，我希望修改订单的收货地址，以便商品寄到我当前方便收货的新地址。
用例主流程
- 买家进入订单详情页，对处于待发货状态的订单发起“修改收货地址”。
- 系统展示当前收货地址，并允许买家选择或填写新地址。
- 买家提交新地址，系统校验地址是否在配送范围内、订单是否仍处于待发货状态、本次修改是否在允许的时间窗口与次数限制内。
- 校验通过后，系统更新订单收货地址，记录修改时间与操作人，并向买家展示修改成功的结果。
异常分支
- 订单已发货：系统不提供修改入口或提示订单已进入发货环节，引导买家联系客服协商处理，需求中写明该分支的提示文案归属与后续处理责任方。
- 新地址超出配送范围：系统提示该地址暂不支持配送，保留原地址不变，买家可重新选择地址。
验收条件
- 给定订单处于待发货状态且买家在允许修改的时间窗口内，当买家提交配送范围内的新地址，那么订单收货地址更新为新地址，并记录修改时间与操作人。
- 给定订单已发货，当买家尝试修改收货地址，那么系统不执行修改，并提示订单已发货及后续处理方式。
- 给定买家提交的新地址超出配送范围，当买家提交修改，那么系统提示地址不支持配送，订单收货地址保持原值。
故事地图中的位置
该需求位于“下单支付—履约准备—售后变更”这条用户活动序列的“履约准备”阶段，具体落在“发货前信息变更”这一任务下。把它放回故事地图，可以看清它与“取消订单”“修改发票信息”同属发货前的变更能力，评审时便于检查是否存在重复或遗漏。
逐项解释：每个字段为什么这样写
示例中的每个字段承担不同的验证任务，写法上的差异直接决定需求能否被下游直接使用。下表按字段说明作用与常见错误写法。
| 字段 | 作用 | 常见错误写法 |
|---|---|---|
| 角色 | 限定提出诉求的身份与订单状态，决定权限与入口设计 | 写“用户可以修改地址”，未限定“已下单未发货的买家”，导致已发货场景被默认包含 |
| 目标 | 说明用户想达成的结果，作为验收的价值依据 | 把方案写进目标，如“我希望点击修改按钮弹出地址选择弹窗”，锁死了交互方式 |
| 业务规则 | 把时间窗口、次数限制、状态前置条件等约束显式列出 | 规则散落在正文叙述中，或只写“按业务规则限制”，未给出具体条件 |
| 验收条件 | 用给定/当/那么把预期结果写成可执行断言 | 写成“地址修改功能正常”，无法判断什么算正常 |
| 异常分支 | 明确非正常路径的系统行为与责任方 | 只写主流程，异常情况留待开发“自行处理” |
| 故事地图定位 | 说明需求在整体流程中的位置，便于检查重复与缺失 | 不标注位置，导致同类变更能力在多处重复建设 |
角色与目标分开写，是为了让评审者能分别质疑“这个角色是否完整”和“这个目标是否值得做”。把方案塞进目标，会让需求在评审阶段就失去调整空间。业务规则单独成段，是因为规则最容易被隐含：时间窗口多长、允许修改几次、哪些订单状态可改，这些条件如果不写，开发和测试只能各自猜测，最终产生不一致的实现与用例。
验收条件采用给定/当/那么结构，价值在于每条都能对应一个可观察的结果。示例中三条验收条件分别覆盖正常修改、已发货拦截、超范围拦截，与业务规则和异常分支一一对应。异常分支必须与主流程同批写出，原因很实际：异常处理往往涉及提示文案、责任方和后续流程，这些信息在开发阶段补写成本更高，也容易遗漏。
故事地图定位看似与单条需求无关，实际是防止需求碎片化的手段。把“修改收货地址”放回“履约准备”阶段，评审时能立刻发现它与“取消订单”共享状态前置条件，从而复用同一套状态判断规则，而不是各写一套。
当这类需求条目进入协作平台，用户故事、业务规则与验收条件可以作为同一个工作项的描述与子项承载，评审意见、状态流转和测试关联都围绕同一条记录展开，减少文档与任务之间的信息脱节。ONES 支持在工作项中组织需求描述、验收条件与评审记录，适合把上述字段固定为团队可复用的填写结构。
可迁移规律：换一个需求怎么套用
把示例中的写法抽象出来，可以按以下五步处理任何一条新需求。每一步都有明确的产物，完成标志是产物能被下游直接使用。
- 先定角色与业务目标：写出“谁、在什么状态下、想达成什么结果”，产物是一句不含方案的用户故事。完成标志是评审者能据此判断需求边界。
- 补业务规则：逐条列出状态前置条件、时间窗口、数量限制、权限约束。完成标志是每条规则都能被追问“具体是多少”并得到答案。
- 写验收条件：按给定/当/那么为每条规则和每个关键分支写断言，规则与验收条件数量对应。完成标志是测试人员能直接据此编写用例。
- 同批写异常分支：在主流程定稿的同一轮里列出异常情况及处理方式，标注责任方。完成标志是没有“待补充”的异常项。
- 放回故事地图检查：确认需求在用户活动序列中的位置，检查是否与已有能力重复、是否遗漏相邻环节。完成标志是位置明确且无重复建设。
套用过程中可以用以下问题自查：角色是否限定了状态？目标里是否混入了交互方案？业务规则是否还有“按规则处理”这类模糊表述？每条验收条件是否都能观察到一个确定结果？异常分支是否都指定了处理方？故事地图上是否已有同类能力？这些问题覆盖了示例中每个字段的验证意图，换一个需求时同样适用。
需要强调的是，一条需求只承载一个可独立验收的目标。如果一条用户故事同时要求“修改地址”和“修改发票信息”，验收条件会相互纠缠，估点和测试都无法独立完成。遇到这种情况，应拆成两条需求，再在故事地图上确认它们同属“发货前信息变更”任务。
适用边界：哪些情况需要换一种表达
用户故事加验收条件的写法适合目标单一、状态清晰、可独立验收的需求。遇到下列情况，机械套用会损失信息，应换用或补充其他表达方式。
| 情况 | 更合适的表达 | 原因 |
|---|---|---|
| 多角色、多系统参与的长业务流程 | 用例或流程描述 | 单条用户故事难以承载多个参与者的交互顺序与状态流转 |
| 方向未定、需要先验证的探索性需求 | 问题陈述与假设 | 此时预期结果尚不确定，过早写验收条件会固化错误假设 |
| 涉及系统间交互 | 补充接口与数据字段说明 | 验收条件描述的是可观察结果，接口契约和数据格式需要单独交代 |
| 需求内容本身的合理性与优先级判断 | 需求分析与澄清 | 属于“该不该做、先做哪个”的判断，与“怎么写清楚”是两项工作 |
复杂业务流程更适合用例或流程描述，因为用例能显式表达多个参与者之间的交互顺序，而用户故事天然以单一角色为中心。探索性需求先写问题与假设，等方向收敛后再补验收条件，可以避免把未经验证的判断写成硬性断言。涉及系统间交互时，验收条件只能说明外部可观察的行为，接口字段、数据映射和错误码需要单独的说明文档承载。
本文示例为演示情景，用于说明填写样式，不代表任何真实客户案例或实施效果。示例中的规则数值、提示文案归属等细节，在实际项目中应按团队约定和业务确认结果填写。
常见问题
需求条目里业务规则和验收条件需要一一对应吗？
建议保持对应关系。每条业务规则至少对应一条验收条件，验收条件覆盖正常路径和该规则被触发拦截的情况。这样测试人员可以按规则逐条核对用例覆盖度，评审时也能发现“写了规则却没有验收条件”或“验收条件找不到规则依据”的缺口。规则数量较多时，可以按状态、时间、权限分组，再逐组对应验收条件。
一条用户故事里能不能同时写修改地址和修改发票信息？
不建议合并。两个目标各自有独立的业务规则和验收结果，合并后验收条件会相互纠缠，估点和测试都难以独立完成。更稳妥的做法是拆成两条需求，再在故事地图上确认它们同属“发货前信息变更”这一任务，共享状态判断规则，但分别验收。
探索性需求还没想清楚结果，也要先写验收条件吗？
可以先写问题陈述与假设，说明要验证什么、判断依据是什么，等方向收敛后再补验收条件。过早写给定/当/那么，容易把未经验证的判断固化成硬性断言，后续调整成本更高。方向明确后，再按本文示例的结构补齐用户故事、业务规则和验收条件。
异常分支由谁负责补充，什么时候补？
异常分支应与主流程在同一轮需求编写中完成，由提出需求的产品角色牵头列出，开发与测试在评审时补充遗漏项。每条异常分支要写明系统行为、提示文案归属和后续处理责任方。留到开发阶段再补，往往涉及跨角色协调，遗漏概率更高。
需求条目写好后，放在文档里还是工作项里更合适？
取决于团队协作方式。需求需要频繁评审、拆分任务并关联测试时，放在工作项中更便于状态流转和追溯；用户故事、业务规则与验收条件可作为同一条记录的描述与子项承载，评审意见和测试关联围绕同一记录展开。ONES 支持在工作项中组织需求描述、验收条件与评审记录，可把示例中的字段固定为团队复用的填写结构。以文档为主、变更较少的团队，用结构化模板同样可行。
