需求表达规范解决的是“一条需求写什么、怎么写、写到什么程度算合格”，让不同人写出的需求能被稳定理解和评审。本文给出一份可直接套用的文档结构、字段定义表、从草稿到入库的执行步骤，以及判断规范是否真正落地的检查清单，适合正在制定或修订规范的研发管理者、产品与需求负责人参考。
要点总览（TL;DR）
- 需求表达规范是一份团队级文档，约定一条需求写什么、怎么写、写到什么程度算合格，核心组成包括适用范围、表达对象与颗粒度、字段清单、写法规则、示例、评审检查项和维护责任。
- 字段划分以“缺少该字段是否导致评审无法判断需求可做、可验收”为依据：需求标识、标题、背景与目标、用户与场景、需求描述、验收标准、优先级、来源、状态设为必填，关联项设为选填。
- 执行按四步走：确定表达对象与颗粒度、按字段表填写、自检与补充、评审与入库，每步都应有明确的输入、输出与完成标志。
- 判断规范是否落地，可看文档齐备度、新需求必填字段完整率、评审退回原因分布以及规范版本与责任人是否明确，不达标时按原因定向调整。
一份需求表达规范应包含哪些内容
需求表达规范是一份团队级文档，核心是把“合格需求”的标准写清楚，让写的人有据可依、评审的人有尺可量。它应当包含七个部分，每部分承担不同职责，缺一块都会让规范退化成写作倡议。
| 组成部分 | 用途 | 最小内容 |
|---|---|---|
| 适用范围 | 说明规范约束哪些需求、哪些团队 | 适用的需求类型（如产品需求、内部改进需求）、生效范围与生效时间 |
| 表达对象与颗粒度 | 统一“一条需求”指什么 | 需求条目的划分原则、拆分与合并的判断依据 |
| 字段清单 | 规定每条需求必须填写的信息 | 字段名、必填或选填、填写口径 |
| 写法规则 | 规定关键字段怎么写 | 标题、描述、验收标准的写作要求与反例 |
| 示例 | 让规则可照着用 | 至少一组改写前后对照 |
| 评审检查项 | 让评审有统一依据 | 逐项可勾选的检查条目与退回原因分类 |
| 维护责任 | 保证规范持续有效 | 维护人、变更提出与确认路径、版本记录方式 |
需要划清边界：需求表达规范只约定“怎么写”，不规定“写什么内容才算对”。需求是否值得做、优先级如何排、业务规则如何取舍，属于需求分析与澄清的工作，应在规范之外单独约定，避免把两类问题混在一份文档里互相拖累。
需求字段怎么定：必填项、选填项与写法规则
字段表是规范中最常被直接使用的部分。划分必填与选填的依据是：缺少该字段是否会导致评审无法判断需求是否可做、可验收。会导致判断中断的字段设为必填，仅辅助理解的设为选填。
| 字段名 | 必填性 | 填写口径 | 合格示例 |
|---|---|---|---|
| 需求标识 | 必填 | 团队内唯一编号，入库时生成 | REQ-2024-0137 |
| 标题 | 必填 | 一句话说明谁在什么场景下获得什么结果，单一意图 | 支持运营按渠道导出近30天订单明细 |
| 背景与目标 | 必填 | 说明现状问题与期望达成的结果，目标可观察 | 运营目前需逐页手工汇总，目标是将单次汇总耗时从2小时降到10分钟内 |
| 用户与场景 | 必填 | 写明角色、触发时机、使用频次 | 运营专员，每月结账前，每月1次 |
| 需求描述 | 必填 | 描述期望行为与规则，不写实现方案 | 可按渠道、时间范围筛选并导出明细，导出字段包含订单号、渠道、金额、下单时间 |
| 验收标准 | 必填 | 逐条可验证，含输入条件与预期结果 | 选择渠道A与近30天，导出文件行数与页面统计一致，字段顺序与约定一致 |
| 优先级 | 必填 | 按团队统一分级填写，附一句理由 | 高：影响月度结账时效 |
| 来源 | 必填 | 记录提出方与原始诉求出处 | 运营部月度复盘会，2024-05-12 |
| 关联项 | 选填 | 关联的需求、缺陷、文档或上游依赖 | 关联 REQ-2024-0121（渠道字段改造） |
| 状态 | 必填 | 按团队状态流转填写，由流程自动推进 | 草稿 / 待评审 / 已入库 / 已退回 |
三类关键字段需要单独写规则。标题要求单一意图，一条标题只承载一个可交付结果，出现“并且”“同时”时通常意味着需要拆分。需求描述要求写期望行为与业务规则，把实现方案、技术选型留在设计环节，避免方案混入后掩盖真实诉求。验收标准要求可验证，每条标准都能通过一次具体操作判断通过或不通过，避免“体验流畅”“响应及时”这类无法判定的表述。
字段与需求类型需要对应。产品功能类需求通常必填用户与场景、验收标准；内部流程改进类需求可弱化用户与场景，强化背景与目标；缺陷修复类需求以复现条件替代场景描述。规范中应为每类需求标注字段适用情况，避免用一张表硬套所有类型。
从草稿到入库：需求表达的执行步骤
规范要落到动作上才有意义。以下四步给出每步的输入、做法、输出与完成标志，团队可按规模裁剪，但完成标志应保留。
步骤一：确定表达对象与颗粒度
输入是需求来源，包括会议记录、用户反馈、业务方提出的诉求。做法是判断这条诉求对应几个可独立验收的结果，按“一个可独立验收的结果对应一条需求”的原则拆分或合并。输出是需求条目划分清单。完成标志是每条需求都能用一句话说清交付结果，且条目之间不存在包含关系。
步骤二：按字段表填写
输入是字段表与规范中的示例。做法是逐字段填写，先写背景与目标、用户与场景，再写需求描述与验收标准，标题最后提炼。输出是一份字段完整的草稿。完成标志是所有必填字段均有内容，验收标准至少一条且可验证。
步骤三：自检与补充
输入是评审检查项。做法是提交前对照检查项逐条核对，重点检查标题是否单一意图、描述是否混入方案、验收标准是否可判定。输出是可提交评审的版本。完成标志是检查项全部通过，或未通过项已注明原因并确认可接受。
步骤四：评审与入库
输入是草稿。做法是评审人按检查项逐条给出通过或退回意见，退回时注明具体字段与原因分类。输出是通过结论或退回意见。完成标志是需求状态更新为已入库或已退回，退回意见已记录到对应需求上。
当需求条目数量增多，字段完整性与评审状态需要在同一处承载，避免规范停留在文档里、执行散落在各处。ONES 支持为需求工作项配置自定义字段与必填校验，需求从草稿到评审的状态流转可在系统中记录，评审退回意见与需求条目关联留存，便于后续统计字段完整率与退回原因分布。
角色分工与各环节交付物
规范无人执行，通常是因为角色不清。以下对照表明确谁写、谁审、谁维护，以及每个角色在各步骤中的产出。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 需求提出者 | 提供原始诉求、背景与期望结果，确认验收标准符合业务预期 | 需求来源记录、背景与目标初稿 |
| 需求负责人（产品角色） | 完成条目划分与字段填写，组织自检，回应评审意见 | 字段完整的需求草稿、自检记录、修订版本 |
| 评审人 | 按检查项评审，给出通过或退回意见并注明原因 | 评审结论、退回意见及原因分类 |
| 规范维护人 | 维护字段表、示例与检查项，处理变更提议，记录版本 | 规范版本记录、变更说明、常见问题补充 |
评审意见需要闭环：退回意见记录在需求条目上，需求负责人修订后重新提交，评审人确认关闭，未采纳的意见需注明理由。规范变更走固定路径：任何人可提出变更提议，说明触发场景与影响范围，由规范维护人确认后更新版本并通知团队，避免规范被个别项目私自修改后失去统一口径。
示例：一条需求按规范改写前后
以下为演示情景，用于说明改写方法，不代表真实项目。
改写前的文本：“希望订单页面能快一点，最好能支持导出，运营那边一直在催。”这条需求的问题在于：目标不可观察，“快一点”无法验收；颗粒度不清，页面性能与导出功能是两个可独立验收的结果；缺少用户、场景与验收标准，评审无法判断是否可做。
按字段表补齐后：标题为“支持运营按渠道导出近30天订单明细”；背景与目标为“运营每月结账需逐页手工汇总，单次约2小时，目标降至10分钟内”；用户与场景为“运营专员，每月结账前，每月1次”；需求描述为“可按渠道与时间范围筛选并导出明细，字段包含订单号、渠道、金额、下单时间”；验收标准为“选择渠道A与近30天，导出文件行数与页面统计一致；导出字段顺序与约定一致；无数据时导出空文件并提示”。页面性能诉求拆为另一条需求，单独写响应时间目标与测量条件。
可迁移的改写规律有三条：把模糊形容词换成可测量的结果与测量条件；把一条混合诉求拆成可独立验收的条目；把验收标准写成“给定输入、执行操作、检查结果”的结构，使评审人能直接判断通过与否。
规范落地后的完成检查
规范写完不等于被执行。以下清单从文档、执行、维护三个层面判断落地情况，每项给出可核对的判断标准。
| 层面 | 检查项 | 判断标准 |
|---|---|---|
| 文档 | 字段表、示例、检查项是否齐备 | 三部分均可在规范中找到，示例至少一组改写前后对照 |
| 文档 | 适用范围与需求类型对应关系是否明确 | 新成员阅读后能判断自己写的需求适用哪些字段 |
| 执行 | 新需求必填字段完整率 | 抽取近一个月入库需求，必填字段缺失比例可统计且呈下降趋势 |
| 执行 | 评审退回原因分布 | 退回意见可按原因分类统计，高频原因能对应到规范中的具体规则 |
| 维护 | 规范版本与责任人是否明确 | 文档标注当前版本、生效时间与维护人，变更留有记录 |
不达标时的调整方向应针对原因：字段完整率低，先检查字段是否过多或校验是否在提交环节生效；退回集中在验收标准，补充该类需求的验收标准示例与检查项；退回集中在颗粒度，补充拆分原则与拆分示例；规范长期未更新，明确维护人并约定复核周期。检查的目的是让规范持续贴合团队实际写法，而非一次性验收。
常见问题
团队规模较小，字段表可以精简吗？
可以精简，但要保留判断需求可做、可验收所必需的字段。常见做法是先保留需求标识、标题、背景与目标、需求描述、验收标准、状态这几项，把用户与场景、优先级、来源按需求类型设为条件必填。精简的依据是评审时是否真的会用到该字段，长期无人查看的字段可以移出必填，等团队规模扩大后再补回。精简后仍需保留至少一组改写示例，否则新成员难以判断填写口径。
需求提出者不熟悉字段表，规范怎么执行？
把填写责任和提出责任分开。需求提出者只需提供原始诉求、背景与期望结果，由需求负责人完成条目划分与字段填写，并在评审前与提出者确认验收标准符合业务预期。规范中可以附一份“提出者只需回答的问题”清单，例如现状是什么、期望达成什么结果、什么时候需要，降低提出者的填写负担，同时保证字段信息不缺失。
评审退回意见如何避免反复来回？
退回时注明具体字段与原因分类，例如“验收标准不可判定”“颗粒度需拆分”，让修订有明确方向。需求负责人修订后重新提交，评审人只针对退回项确认关闭，未采纳的意见注明理由。定期统计退回原因分布，若某一类原因反复出现，回到规范中补充对应的规则或示例，从源头减少同类退回。
规范定好后多久复核一次比较合适？
复核周期取决于团队需求量和变更频率。常见做法是按季度复核一次，或在出现以下信号时提前复核：某类退回原因连续集中出现、字段完整率持续偏低、团队新增需求类型无法套用现有字段表。复核由规范维护人组织，输出变更说明并更新版本记录，变更后通知团队，避免不同项目各自沿用旧版本。
需求表达规范和需求评审规范是同一份文档吗？
两者关注点不同。需求表达规范约定需求条目写什么字段、怎么写、写到什么程度算合格；需求评审规范约定评审何时发起、由谁参加、按什么流程给出结论。实践中可以把评审检查项放在表达规范里作为自检依据，把评审组织方式单独成文，两份文档互相引用，避免一份文档同时承载写作规则和会议流程而变得难以维护。
