需求表达规范要解决的问题很具体：让一条需求在评审会上能被逐项核对，而不是靠口头补充背景。本文给出一条完整填写的需求条目示例，覆盖背景、用户与场景、需求描述、验收标准、优先级、约束与待确认项，并逐字段解释写法依据。示例为演示情景，用于对照检查团队自己的需求条目；ONES 可作为承载这类结构化条目的工具。
要点总览（TL;DR）
- 一条可评审的需求条目应包含背景、目标用户与场景、需求描述、验收标准、优先级、约束与依赖、待确认项七类字段，缺项会让评审会变成口头补背景。
- 需求描述按“触发条件—系统行为—可观察结果”三要素书写，例如“存在30天内到期积分时，在到期日前第7天10:00生成一条站内信”，替代“优化提醒体验”这类无法判定的表述。
- 验收标准每条应能独立判定通过或不通过，覆盖正常触发、去重、页面展示、无数据边界等情形，并把实现方式留在约束或技术方案中。
- 填写顺序建议先场景与目标、再需求描述、最后验收标准；评审前用自查清单逐项核对，模糊形容词按“条件、动作、结果”改写。
- 这套写法适合有明确用户与场景的功能型需求；探索型需求宜先写问题与假设，需求内容是否成立归需求分析与澄清，架构设计与界面绘制不在本文范围。
示例目标：这条需求要示范什么
本文的示例是一条虚构的会员积分过期提醒需求，用于演示需求表达规范。它不对应任何真实客户、真实项目或实测结果，其中的业务规则、数值和角色均为说明写法而设定。读者可以把示例当作模板对照，检查自己团队的需求条目是否具备同样的信息完整度。
示例覆盖以下字段范围，这也是后文逐项解释的对象：
- 背景：为什么现在要做这条需求，触发问题是什么；
- 目标用户与使用场景：谁在什么情况下遇到问题；
- 需求描述：系统在什么条件下执行什么行为、产生什么结果；
- 验收标准：若干条可独立判定的检查项；
- 优先级：本条需求在待办中的相对位置及判断依据；
- 约束与依赖：实现时必须遵守的限制和需要其他团队配合的事项；
- 待确认项：当前尚未定论、需要在评审中澄清的问题。
对照使用时，重点看两件事：字段是否齐全，以及每个字段的表述是否能让评审人直接判断“写得对不对、做得完做不完”。
完整示例：一条会员积分过期提醒需求
以下为完整填写的需求条目。标题与摘要放在最前，便于在需求列表中快速识别；其余字段按评审时的阅读顺序排列。
| 字段 | 填写内容 |
|---|---|
| 需求标题 | 会员积分到期前 7 天站内信提醒 |
| 一句话摘要 | 对 30 天内即将过期的积分，在到期前第 7 天向会员发送一次站内信提醒，并在会员中心展示即将过期积分数量。 |
| 背景 | 会员积分按自然年清零。运营侧收到会员咨询，反映不清楚积分何时过期；客服在处理此类咨询时缺少统一口径。当前会员中心仅展示积分余额，不展示有效期信息。 |
| 目标用户 | 持有将在 30 天内过期积分的注册会员；运营人员（查看提醒发送情况）。 |
| 使用场景 | 会员登录会员中心查看积分时，能看到即将过期的积分数量与到期日期；在到期前第 7 天，会员收到一条站内信，提示即将过期积分数量与到期日期，并可点击进入积分兑换页。 |
| 需求描述 | 当会员账户存在 30 天内到期的积分时，系统在到期日前第 7 天 10:00 生成一条站内信，内容包含即将过期积分数量与到期日期，并附积分兑换页入口；同一会员同一到期批次仅发送一次。会员中心积分页在积分余额下方展示“即将过期积分”数量及最近到期日期。 |
| 验收标准 | 1. 构造一个 30 天内到期积分的会员账户，在到期日前第 7 天 10:00 后可在站内信列表看到一条提醒，内容含积分数量与到期日期。 2. 同一会员同一到期批次重复触发任务，站内信数量保持为 1 条。 3. 会员中心积分页展示“即将过期积分”数量，数值与该会员 30 天内到期积分之和一致。 4. 无 30 天内到期积分的会员，积分页不展示“即将过期积分”区块，也不收到提醒。 5. 站内信中的兑换页入口可跳转至积分兑换页。 |
| 优先级 | 中。依据：影响会员积分使用体验与客服咨询量，但不阻塞交易主流程；可与本期其他会员中心改版需求并行排期。 |
| 约束与依赖 | 约束：站内信模板需沿用现有消息中心模板规范；提醒时间点固定为 10:00，暂不提供会员自定义。依赖：积分到期批次数据由积分服务提供，需确认其是否已按到期日聚合；站内信发送能力复用消息中心现有接口。 |
| 待确认项 | 1. 积分到期批次数据是否已按到期日聚合，若未聚合由哪方提供聚合口径。 2. 到期日当天是否仍需展示提醒，需运营确认。 3. 站内信文案由运营提供还是产品提供，评审时确定责任人。 |
这份条目可以直接进入评审：评审人能看到问题背景、判断行为描述是否完整、逐条核对验收标准，并对“待确认项”逐项给出结论。
逐项解释：每个字段为什么这样写
下面按字段说明写法依据，并用正反例对照，帮助读者理解规则而不是照抄内容。
背景与场景：回答“为什么做”和“谁在什么时候遇到问题”
背景字段要回答的是问题从哪来、当前状态缺什么，而不是提前写解决方案。示例中写“会员中心仅展示积分余额，不展示有效期信息”，描述的是现状缺口；如果写成“需要新增一个即将过期积分模块”，就把方案塞进了背景，评审时反而看不清问题本身。
场景字段要把用户、时机和动作放在一起。示例写“会员登录会员中心查看积分时，能看到即将过期积分数量与到期日期”，评审人可以据此判断这个场景是否真实存在、是否覆盖了主要使用路径。
需求描述：用行为、条件、结果三要素表达
规范的需求描述通常包含三个要素：触发条件（什么时候）、系统行为（做什么）、可观察结果（产生什么）。示例中“当会员账户存在 30 天内到期的积分时”是条件，“在到期日前第 7 天 10:00 生成一条站内信”是行为，“内容包含即将过期积分数量与到期日期”是结果。三要素齐全，开发和测试才能各自推导出实现与验证方式。
对照反例：“优化积分提醒体验，让会员及时感知积分过期。”这句话没有条件、没有行为、没有可判定结果，评审时无法确认做到什么程度算完成。
验收标准：写成可独立判定的检查项
验收标准的作用是让“做完了”有统一判断依据。示例中的五条分别对应：正常触发、去重、页面展示、无数据时的边界、入口可用。每条都能通过构造数据或操作独立验证，且不描述实现方式。
常见反例是把实现方案写进验收，例如“使用定时任务扫描积分表并发送消息”。这属于技术实现，评审时应放在约束或技术方案中，验收标准只保留可观察的结果。
优先级与约束：保留判断条件，不替评审下结论
优先级字段写“中”并附依据，比只写一个等级更有用。示例给出两条依据：影响体验但不阻塞主流程、可并行排期。评审人若掌握其他信息，可以据此调整，而不是面对一个无法讨论的结论。
约束与依赖字段要把限制条件和外部依赖分开写。示例中“提醒时间点固定为 10:00”是约束，“积分到期批次数据由积分服务提供”是依赖，并进一步指出需要确认聚合口径。这样评审时能直接定位到需要协调的对象。
待确认项：把未知显式标注出来
需求填写过程中遇到尚未定论的问题，应集中写入待确认项，而不是在正文里用模糊表述带过。示例列出三条待确认项，并注明需要谁确认。评审会的任务之一就是逐条关闭这些项；未关闭的项应保留在条目中，避免后续被当成已确定事实执行。
可迁移规律：换一个需求怎么照样填
从示例中可以提炼出一套填写顺序和自查方法，适用于多数功能型需求。
按“先场景与目标，再描述，最后验收”的顺序填写
先写背景、目标用户和场景，是因为这三项决定了需求是否值得做、边界在哪里；场景清楚之后，需求描述的条件和行为才有依据；验收标准放在最后写，是因为它需要逐条对应描述中的行为和边界。若先写验收再补场景，容易出现验收项与真实使用路径脱节的情况。
把形容词改写为可观察行为
模糊形容词是评审中最常见的障碍。替换方法是追问三个问题：在什么条件下发生、系统或用户做什么动作、产生什么可观察结果。例如：
- “提醒要及时”改为“在到期日前第 7 天 10:00 发送”；
- “展示要清晰”改为“在积分余额下方展示数量与最近到期日期”；
- “避免重复打扰”改为“同一会员同一到期批次仅发送一次”。
改写后，每条表述都能对应一个测试动作或一次页面检查。
控制验收标准的条数与颗粒度
一条需求对应若干条验收项，数量以覆盖主要行为、关键边界和必要异常为准。颗粒度上，每条验收项应能独立判定通过或不通过；把多个行为塞进一条会导致部分通过时无法记录。示例中正常触发、去重、页面展示、无数据边界、入口跳转各占一条，就是按这个原则拆分的。
评审前的自查清单
- 背景是否只描述问题与现状，没有提前写方案；
- 目标用户与场景是否具体到角色和时机；
- 需求描述是否每条都具备条件、行为、结果；
- 验收标准是否可独立判定，且没有写入实现方式；
- 优先级是否附有判断依据；
- 约束与依赖是否注明需要协调的对象；
- 待确认项是否列出并注明确认人。
适用边界：哪些需求不适合这套写法
这套字段结构适合有明确用户与场景的功能型需求，例如页面展示调整、消息提醒、流程节点增减。此类需求的行为和结果可以事先描述清楚，验收标准也能逐条构造验证。
探索型或研究型需求需要调整写法。此类需求在开始时往往只知道要解决的问题和待验证的假设，行为与结果尚不确定。此时宜先写问题陈述、假设和验证方式，把“需求描述”替换为“本轮要验证什么、用什么信号判断”，验收标准相应改为验证结论的判定条件，而不是功能行为的检查项。
还需要区分本文的范围：需求内容本身是否成立、优先级是否合理，属于需求分析与澄清的工作；系统架构设计和界面绘制也不在本文讨论之内。本文只处理“一条已经确定要做的需求，如何写成可评审的条目”。
把示例规范落到协作流程里
填写规范只有进入流转才有价值。一条需求条目通常经历这样的过程：产品经理按字段填写并提交评审，评审人对描述与验收标准逐条核对，待确认项在会上逐项关闭或指派责任人，条目状态从“待评审”推进到“已确认”，随后拆分为开发任务并关联验收。
要让这个过程可追溯，需要三个承载点：条目字段本身保持统一，评审意见记录在条目上而不是散落在聊天记录里，待确认项有明确的关闭状态。这样后续开发、测试和验收都能回到同一条目核对原始约定。
ONES 可以作为承载这类条目的工具：需求以工作项形式管理字段与状态，评审意见和待确认项随条目留痕，拆分出的任务与验收项可关联回原需求。ONES Assistant 智能助手连接 ONES Project、ONES Wiki 与 ONES TestCase，能理解项目、工作项、迭代和 Wiki 页面等工作上下文，并可将自然语言指令转化为 ONES 中可追踪的工作，例如按页面展示的示例指令将 PRD 拆解为需求和任务并按模块分配负责人；实际效果取决于输入文档与项目配置。团队可据此把填写规范与评审流转放在同一处完成，减少条目信息在多个工具间搬运。
常见问题
需求条目里的“待确认项”在评审后应该怎么处理？
评审会上应逐条处理待确认项：能当场定论的，把结论写回对应字段并删除该条待确认项；需要外部信息的，指定确认人和时间点，条目保留该项并标注状态。未关闭的待确认项不要从条目中删掉，否则后续开发容易把它当成已确定事实执行。条目从“待评审”推进到“已确认”时，可以要求待确认项全部关闭或明确挂起。
一条需求拆成几条验收标准比较合适？
以覆盖主要行为、关键边界和必要异常为准，不以固定条数为目标。判断颗粒度的标准是每条能否独立判定通过或不通过：正常触发、重复触发去重、页面展示、无数据时的表现、入口跳转，各自占一条，部分通过时才能准确定位问题。把多个行为塞进一条，会让验收记录失去区分度；拆得过细，则增加维护成本。
探索型需求能不能直接套用这套字段？
可以保留字段框架，但内容需要调整。探索型需求开始时通常只有待解决的问题和假设，行为与结果尚不确定，此时“需求描述”宜改为本轮要验证什么、用什么信号判断，“验收标准”相应改为验证结论的判定条件。等验证结论明确、功能行为可以描述之后，再按标准字段补全，进入常规评审流程。
团队填写规范不统一，评审时怎么减少来回沟通？
先把字段清单和每类字段的写法要求固定下来，作为条目模板；再在评审前做一次自查，重点看背景是否混入方案、需求描述是否具备条件与结果、验收标准是否可独立判定。评审意见和待确认项记录在条目上，避免散落在聊天记录里。ONES 可作为承载这类条目的工具，需求以工作项形式管理字段与状态，评审意见随条目留痕；具体字段配置以团队实际部署为准。
需求描述里出现“及时”“清晰”“友好”这类词，怎么改？
对每个形容词追问三件事：在什么条件下发生、系统或用户做什么动作、产生什么可观察结果。例如“提醒要及时”改为“在到期日前第7天10:00发送”，“展示要清晰”改为“在积分余额下方展示数量与最近到期日期”，“避免重复打扰”改为“同一会员同一到期批次仅发送一次”。改写后每条表述都能对应一个测试动作或一次页面检查，评审时才有共同判断依据。
