需求文档编写的核心是先明确文档要回答的问题和读者，再按“背景与目标—范围与角色—流程与场景—功能与规则—数据与接口—非功能要求—验收标准—变更记录”的顺序组织内容，让每条需求都能追溯到来源，并可直接被开发和测试使用。落地时按“收集输入—搭骨架—逐条写需求—自检—评审定稿—变更维护”推进，产品经理主笔，业务方确认规则，研发与测试参与评审。
要点总览（TL;DR）
- 需求文档先定读者和要回答的问题，再按背景目标、范围角色、流程场景、功能规则、数据接口、非功能要求、验收标准、变更记录搭骨架。
- 每条需求统一字段：编号、描述、来源、优先级、验收条件、状态，并按业务需求、功能需求、非功能需求分层编号。
- 编写按六步推进：收集输入、搭骨架定粒度、逐条撰写、补验收与优先级、自检交叉核对、评审定稿与版本记录。
- 产品经理主笔，业务方确认场景与规则，研发评估可行性，测试从验收条件反查完整性，评审结论和待办必须书面留痕。
- 定稿前用完整性、一致性、可测试性、可追溯性、歧义与术语五类检查项核对，出现阻断项先返工再评审。
需求文档先写什么：核心结构与必备字段
动笔之前先回答两个问题：这份文档给谁看，要支撑什么决策。给业务方看的文档侧重场景和规则，给研发测试看的文档侧重流程分支和验收条件。读者不同，详略取舍就不同。确定读者后，再按下面的骨架搭章节，可以避免写到一半发现缺内容。
文档章节骨架
| 章节 | 要回答的问题 | 常见内容 |
|---|---|---|
| 背景与目标 | 为什么做这件事 | 业务现状、问题描述、目标与衡量指标 |
| 范围与角色 | 做到哪里、涉及谁 | 本期范围、不在范围内的事项、用户角色与权限 |
| 流程与场景 | 用户在什么情况下做什么 | 主流程、分支流程、异常场景 |
| 功能与规则 | 系统要提供什么能力 | 功能清单、业务规则、校验条件、状态变化 |
| 数据与接口 | 数据从哪来、到哪去 | 关键字段、数据来源、上下游系统交互 |
| 非功能要求 | 性能、安全、兼容性有什么约束 | 响应时间、并发量、权限控制、终端适配 |
| 验收标准 | 怎样算做完、做对 | 按需求逐条给出可验证的验收条件 |
| 变更记录 | 改过什么、为什么改 | 版本号、变更内容、变更原因、确认人 |
章节顺序可以按团队习惯调整，但背景目标、功能规则、验收标准、变更记录四部分建议保留，它们分别对应“为什么做”“做什么”“怎么验”“改了什么”，缺一项都会在后续环节产生返工。
单条需求的必备字段
文档骨架解决整体结构，单条需求还需要统一字段，否则同一份文档里会出现有的需求写了优先级、有的没写验收条件的情况。建议每条需求至少包含以下字段：
| 字段 | 填写要求 |
|---|---|
| 需求编号 | 全文档唯一，便于评审、任务和测试用例引用 |
| 需求描述 | 一句话说明要解决的问题或要提供的能力 |
| 来源 | 业务方、用户反馈、合规要求或内部规划，注明提出人 |
| 优先级 | 按团队统一口径标注，如必须、应该、可选 |
| 验收条件 | 可观察、可判断通过与否的具体表述 |
| 状态 | 草稿、待评审、已确认、开发中、已验收等 |
按需求类型分层组织
一份文档里往往混着不同层次的需求。业务需求描述业务目标和价值，功能需求描述系统行为，非功能需求描述质量约束。建议在文档中用层级编号区分，例如业务需求用 BR 前缀、功能需求用 FR 前缀、非功能需求用 NFR 前缀，并在功能需求下挂对应的业务需求编号。这样评审时业务方可以只看业务层，研发测试可以顺着编号下钻到具体功能，讨论不会混在一起。
从输入到定稿：需求文档编写的操作步骤
编写过程拆成六步，每步都有明确的输入、动作和完成标志，可以按顺序推进，也可以在评审返工时回到对应步骤补充。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、收集输入 | 业务目标、用户反馈、现有流程说明、约束条件 | 访谈业务方，梳理现状流程，记录待解决的问题和限制 | 输入清单与问题列表 | 每个待写需求都能对应到至少一个输入来源 |
| 二、搭骨架定粒度 | 输入清单、文档模板 | 确定章节结构，划分需求层级，明确本期范围 | 文档目录与需求清单 | 目录覆盖全部输入，范围边界写清楚 |
| 三、逐条撰写 | 需求清单、流程与规则说明 | 按字段逐条写场景、主流程、规则和异常分支 | 需求条目初稿 | 每条需求都有编号、描述、来源和场景说明 |
| 四、补验收与优先级 | 需求条目初稿 | 为每条需求写验收条件，按统一口径标优先级 | 带验收条件的需求条目 | 每条需求都能被测试转化为用例 |
| 五、自检与交叉核对 | 完整初稿 | 对照检查清单逐项核对，与研发测试预沟通可行性 | 修订稿与问题记录 | 检查清单无阻断项，明显歧义已消除 |
| 六、评审定稿与版本记录 | 修订稿、评审参与人 | 组织评审，记录结论和待办，更新版本号和变更记录 | 定稿文档与评审记录 | 评审结论明确，待办有责任人和时间 |
第三步是最容易写偏的环节。写功能规则时，除了正常路径，要把校验失败、权限不足、数据为空、重复提交等异常分支一并写出来，并说明系统如何提示、流程如何继续。异常分支写得越具体，开发和测试在实现阶段回头找产品经理确认的次数越少。
第五步的自检建议在评审前完成，把能自己发现的问题先改掉。与研发测试的预沟通可以只针对可行性存疑或技术约束较多的条目，不必等全文写完再统一沟通，避免评审会上出现方向性推翻。
谁写谁审：角色分工与交付物
需求文档的质量取决于分工是否清楚。主笔只有一个，确认和评审可以多人参与，但每个角色的职责和交付物要提前约定。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 产品经理/需求负责人 | 主笔撰写，保证全文结构和口径一致，汇总评审意见并修订 | 需求文档初稿、修订稿、定稿 | 评审前提交初稿，评审后提交定稿 |
| 业务方 | 提供业务场景和规则，确认业务目标与优先级 | 场景说明、规则确认意见 | 编写前提供输入，评审时确认 |
| 研发 | 评估技术可行性，指出约束和实现风险 | 可行性意见、技术约束说明 | 自检阶段预沟通，评审时给出结论 |
| 测试 | 从验收条件反查需求完整性，提前识别不可测条目 | 验收条件补充意见、可测性问题清单 | 评审前审阅验收标准，评审时提出 |
| 评审组织者 | 确定评审范围、参与人和时间，控制评审节奏 | 评审通知、议程 | 评审前发出，评审时主持 |
| 记录人 | 记录评审结论、待办事项和责任人 | 评审记录、待办清单 | 评审结束后一个工作日内发出 |
评审组织者和记录人可以由产品经理兼任，但评审结论和待办必须落到书面，否则会后容易出现“当时说改但没人跟进”的情况。测试参与评审的价值在于提前暴露验收条件写不清的条目，这类问题在评审阶段改成本最低。
示例：一条需求从草稿到可验收的写法
以下为演示情景，用于说明写法，不代表真实项目。
背景：某内部系统需要支持员工提交报销单，业务方希望减少财务人工核对。需求来源为财务部门反馈。
草稿版
“系统支持员工提交报销单，财务可以审批。”
这条描述的问题在于：没有说明谁在什么条件下提交、提交时校验什么、审批有哪些分支、怎样算通过。开发和测试拿到后只能各自理解。
完善版
需求编号 FR-012，来源为财务部门反馈，优先级为必须。
场景：员工在报销单页面填写金额、费用类型和发票附件后提交；财务人员在待审批列表中处理。
主流程：员工填写必填项并上传附件，系统校验金额大于零、费用类型已选择、附件格式符合要求，校验通过后生成报销单并进入待审批状态。
异常分支：金额为空或小于等于零时提示“请输入有效金额”并阻止提交；附件格式不符时提示支持的格式；同一员工重复提交相同金额和费用类型的单据时，提示可能存在重复报销，由员工确认后继续。
验收条件：必填项缺失时无法提交并给出对应提示；校验通过的单据状态为待审批且出现在财务待审批列表；重复提交提示在满足条件时出现，员工确认后可正常生成单据。
可迁移的写作规律
完善版把一条模糊描述拆成了场景、主流程、异常分支和验收条件四部分，每部分都能被不同角色直接使用：业务方看场景是否符合实际，研发看规则是否可实现，测试看验收条件是否可验证。写其他需求时可以沿用这个结构，先写谁在什么情况下做什么，再写系统怎么响应，最后写怎样判断做对了。
编写完成检查：定稿前的核对清单
定稿前按清单逐项核对，发现阻断项先返工，再进入评审。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 完整性 | 章节骨架是否齐全，范围边界是否写明 | 背景目标、范围、功能规则、验收标准、变更记录均有内容 |
| 一致性 | 术语、角色名称、状态名称全文是否统一 | 同一概念只有一种叫法，前后引用编号对得上 |
| 可测试性 | 每条需求是否都有验收条件 | 测试可以据此写出至少一条用例，无需再向产品经理确认 |
| 可追溯性 | 每条需求是否有来源，变更是否有记录 | 需求编号可回溯到输入来源，版本变更写明原因和确认人 |
| 歧义与术语 | 是否存在“尽快”“适当”“友好提示”等模糊表述 | 模糊词已替换为具体条件、数值或明确行为 |
阻断项通常包括：核心功能缺少验收条件、范围边界缺失导致评审无法判断取舍、关键业务规则存在两种以上理解。出现阻断项时返工对应章节，修订后重新自检。评审通过的判定标准建议定为：参与角色对范围、主要规则和验收标准无未决异议，待办事项均有责任人和时间，评审记录已发出。
文档定稿后的维护与协作衔接
定稿不是终点。需求进入开发后，变更、澄清和状态更新会持续发生，维护动作要跟着走。
变更记录方面，每次修改需求内容都要在变更记录中写明改了什么、为什么改、由谁确认，并评估对已排期任务和测试用例的影响。版本与状态维护方面，建议给文档设置明确的状态，如已确认、开发中、已验收，避免有人拿旧版本做依据。需求与任务的关联方面，每条需求编号应能对应到开发任务和测试用例，需求变更时能快速找到受影响的任务和用例。跨角色评审与交接方面，评审结论、待办和确认意见要留痕，交接时以书面记录为准。
当需求条目增多、参与角色变多时，可以用工具承载这些管理动作。ONES 提供统一的需求池，业务、产品经理与研发团队可以在同一处查看需求来源、规划状态和落地进展，需求、任务、测试与缺陷形成闭环，便于追溯。ONES Wiki 可用于沉淀产品需求文档，页面组可关联项目，使需求与文档互相对应，文档支持嵌入任务进度和报表；文档记录所有页面版本，支持查看与回滚，便于在变更后对照历史版本。评审结论和变更说明可以随文档一并留存，交接时有据可查。
常见问题
需求文档写多细才算合适？
粒度取决于读者和后续用途。给业务方确认的文档，场景和业务规则写到能判断是否符合实际即可；给研发测试使用的文档，主流程、异常分支和验收条件要写到能被直接实现和验证。一个实用的判断标准是：测试拿到这条需求，能否在不追问产品经理的情况下写出至少一条用例。如果写不出，说明粒度还不够；如果开始描述具体实现方案，说明已经越过了需求文档的边界。
评审会上业务方和研发意见不一致，怎么处理？
先区分分歧属于哪一类。如果是业务规则本身没定清楚，由业务方给出明确结论并记录；如果是技术实现存在约束，由研发说明约束条件和可选方案，产品经理评估对业务目标的影响后调整需求或缩小范围。评审组织者要把结论、待办、责任人和时间写进评审记录，避免会后口头传达。无法当场达成一致的条目，标记为待定并约定下次确认时间，不带着未决分歧进入开发。
需求文档定稿后发生变更，需要改哪些地方？
至少同步四处：需求条目本身、变更记录、关联的开发任务与测试用例、受影响的验收条件。变更记录写明改了什么、为什么改、由谁确认；关联任务和用例要评估是否需要调整排期或补充用例。如果变更影响已排期范围，还需要通知评审参与角色。文档版本状态同步更新，避免有人继续引用旧版本作为依据。
小团队也需要完整的文档骨架和评审流程吗？
骨架可以裁剪，关键部分建议保留。背景目标、功能规则、验收标准、变更记录这四块分别对应为什么做、做什么、怎么验、改了什么，缺一项都容易在后续返工。评审可以简化形式，比如研发和测试提前看文档、用一次短会确认结论，但结论和待办仍要落到书面。团队规模小、需求变化快时，可以把评审和需求澄清合并进行，减少会议次数。
需求文档和需求池里的条目是什么关系？
文档承载完整的背景、场景、规则和验收说明，需求池条目承载可跟踪的状态和流转。常见做法是文档中每条需求有唯一编号，需求池中对应一条记录，两者通过编号关联，开发任务和测试用例再挂到这条记录上。这样需求变更时，可以从编号快速找到受影响的文档段落、任务和用例。ONES 提供统一的需求池，业务、产品经理与研发团队可以在同一处查看需求来源、规划状态和落地进展，需求、任务、测试与缺陷形成闭环，便于追溯。
