需求文档编写从确定文档类型和读者开始，再按“背景与目标—范围与角色—流程与场景—功能与规则—数据与接口—非功能要求—验收标准—待定项”搭骨架，把每条需求写成可验证的条目，最后经过自查、评审和意见关闭后进入开发。本文给出可直接套用的章节结构、单条需求模板、编写步骤表、角色分工和完成检查清单，适合第一次写需求文档或希望统一团队写法的产品与业务人员参考。
要点总览（TL;DR）
- 先确定文档类型和读者：PRD讲清产品方案，需求规格说明承载逐条验证的条目，用户故事集拆分到迭代，三者可以组合使用。
- 按“背景与目标—范围与角色—流程与场景—功能与规则—数据与接口—非功能要求—验收标准—待定项”搭骨架，能引用通用规范就不在正文重复。
- 单条需求统一编号、描述、来源、优先级、状态和验收条件，描述用场景和规则表达，异常与边界至少覆盖空值、上下限、重复提交和外部依赖失败。
- 编写按收集输入、搭骨架、填主体、补验收标准、自查、同行评审、意见关闭七步推进，每步有明确完成标志。
- 评审前用完整性与一致性、可验证性、待定项与风险、评审与变更四组清单逐项核对，未通过项登记为待定项并跟踪。
先定文档类型和读者，再动笔
动笔前先回答两个问题：这份文档服务谁，要支撑什么决策。写给业务方确认范围，和写给研发、测试作为实现依据，详略和措辞差别很大。类型和读者定下来，后面每一节写到什么程度就有了标准。
常见三类需求文档的适用差别如下：
| 文档类型 | 主要用途 | 内容侧重 | 适用场景 |
|---|---|---|---|
| PRD（产品需求文档） | 说明产品要解决什么问题、做成什么样 | 背景、目标、用户场景、功能描述、交互与规则、优先级 | 面向业务方和研发对齐产品方案，偏产品视角 |
| 需求规格说明 | 作为开发、测试、验收的共同依据 | 功能条目、输入输出、业务规则、数据与接口、非功能要求、验收标准 | 需求较复杂、需要逐条验证，偏工程视角 |
| 用户故事集 | 按迭代拆分可交付的需求单元 | 角色、目标、价值、验收条件，粒度较小 | 敏捷迭代中持续补充，适合快速排期 |
三类文档可以组合使用：用PRD讲清整体方案，用需求规格说明承载需要逐条验证的条目，用用户故事集拆分到迭代。选择哪种为主，取决于团队当前的交付方式和需求的复杂程度。
读者决定详略。业务方关注目标、范围和业务规则是否覆盖了真实场景；研发关注流程、数据、接口、异常和边界；测试关注每条需求是否有可验证的验收条件。同一份文档要同时服务这三类读者，做法是把业务背景写短、把规则和验收条件写细，让不同读者各取所需。
动笔前需要确认三类输入：目标（这次要解决什么问题、成功怎么衡量）、范围（做什么、明确不做什么）、约束（时间、合规、既有系统限制、依赖的外部条件）。这三类输入没有确认，文档写到一半容易反复。输入不完整时，把缺口记入待定项，标注负责人和确认时间，不要用模糊表述掩盖。
需求文档的标准骨架与各节写法
下面这套骨架适用于大多数功能类需求，可按项目规模增减章节，但顺序建议保留，因为它对应读者从“为什么做”到“怎么验收”的理解路径。
| 章节 | 核心问题 | 写到什么程度 | 常见遗漏 |
|---|---|---|---|
| 背景与目标 | 为什么做、解决谁的什么问题、成功标准是什么 | 几段话说清现状、问题和目标，目标尽量可衡量 | 只写业务价值，没写当前问题如何产生 |
| 范围与角色 | 做什么、不做什么、涉及哪些角色 | 列出范围内功能和不做事项，列出角色及其权限差异 | 不做的部分没写，导致评审时反复确认 |
| 流程与场景 | 用户在什么场景下按什么步骤完成任务 | 主流程逐步描述，配关键分支场景 | 只写正常路径，异常和中断场景缺失 |
| 功能与规则 | 每个功能做什么、受什么规则约束 | 按功能模块拆条目，规则写成可判断的条件 | 规则用形容词描述，无法判断是否满足 |
| 数据与接口 | 涉及哪些数据、与哪些系统交互 | 说明关键字段、数据来源、接口的输入输出和失败处理 | 接口异常和超时处理没写 |
| 非功能要求 | 性能、安全、兼容、可用性有什么要求 | 给出可测量的指标和适用条件 | 写“响应要快”这类无法验证的表述 |
| 验收标准 | 怎样算做完、怎样算通过 | 每条需求对应可执行的验收条件 | 验收标准与功能描述脱节 |
| 待定项 | 还有哪些问题没定、谁负责、何时关闭 | 逐条列出问题、负责人、计划确认时间 | 口头约定没落文档，评审后无人跟进 |
各节写法上有两个原则。第一，能引用就不重复：公司级的术语表、权限模型、通用交互规范、既有接口文档，用引用方式指向来源，正文只写本次需求特有的差异，避免同一规则在多处维护、版本不一致。第二，每节只回答自己的核心问题：背景节不展开功能细节，功能节不重复背景论证，验收标准直接对应功能条目编号。
非功能要求容易被写成口号。可执行的做法是给出指标、测量条件和范围，例如“在常规网络条件下，列表页首屏加载时间不超过约定值”，具体数值由团队结合业务确定，写进文档后作为验收依据。
把一条需求写成可验证的条目
需求文档的可执行性最终落在单条需求上。一条需求应让开发知道做什么、测试知道怎么验、业务方知道对应哪个诉求。建议统一使用以下字段：
| 字段 | 填写要求 |
|---|---|
| 编号 | 全文档唯一，便于验收标准和变更记录引用 |
| 描述 | 一句话说明系统在什么条件下做什么、产生什么结果 |
| 来源 | 对应业务诉求、用户反馈或上游文档，便于追溯 |
| 优先级 | 按团队统一口径标注，说明排期依据 |
| 状态 | 草稿、待评审、已确认、已变更等，反映当前可信程度 |
| 验收条件 | 可执行的判断条件，覆盖正常、异常和边界情况 |
描述用场景和规则表达行为，避免形容词。对比下面两种写法：
- 模糊写法：提交订单时要给用户友好的提示。
- 可验证写法：用户提交订单时，若收货地址为空，系统阻止提交并在地址栏下方显示“请填写收货地址”；若库存不足，系统阻止提交并提示可购买数量。
异常与边界条件是单条需求最容易漏的部分。写每条需求时至少检查四类情况：输入为空或格式错误、数量或金额达到上下限、操作重复提交、依赖的外部服务失败或超时。每类情况写明系统行为，行为可以是阻止、提示、降级或记录，但要具体到用户看到什么、数据发生什么变化。
验收条件建议与需求条目一一对应，用“给定—当—则”的结构描述：给定某个前置状态，当用户执行某个操作，则系统产生某个可观察结果。这样测试可以直接转化为用例，验收时也有明确依据。
编写流程：从初稿到评审通过
把编写拆成有完成标志的步骤，能减少反复。下表给出各步骤的输入、动作、输出和完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 收集输入 | 业务目标、用户反馈、现有系统资料、约束条件 | 访谈业务方和研发，整理目标、范围、约束，列出待确认问题 | 输入清单与待确认问题列表 | 目标、范围、约束各有明确结论或已登记待定项 |
| 2. 搭骨架 | 输入清单、文档类型与读者 | 按标准骨架建章节，先写背景、范围、角色 | 文档目录与前三节初稿 | 范围中的“不做什么”已写明 |
| 3. 填主体 | 骨架、流程与场景信息 | 写流程、功能条目、规则、数据与接口、非功能要求 | 需求条目集合 | 每条需求具备编号、描述、来源、优先级、状态 |
| 4. 补验收标准 | 需求条目 | 为每条需求写验收条件，覆盖正常、异常、边界 | 验收标准 | 每条需求至少有一条可执行验收条件 |
| 5. 自查 | 完整初稿、检查清单 | 按清单逐项核对完整性、一致性、可验证性 | 修订稿与遗留问题记录 | 清单项全部通过或已登记待定项 |
| 6. 同行评审 | 修订稿、评审参与人 | 组织研发、测试、设计评审，记录意见 | 评审意见清单 | 意见逐条有处理结论 |
| 7. 意见关闭 | 评审意见清单 | 修改文档，对不采纳的意见说明理由，确认人复核 | 评审通过的文档版本 | 所有意见关闭，关键角色确认 |
第1步和第5步最容易被跳过。输入没收集全，主体部分会反复返工；自查没做，评审会把时间花在格式和遗漏上，而不是方案本身。评审意见要逐条记录处理结论，采纳的修改文档，不采纳的写明理由并由提出人确认，避免同一问题在后续评审中重复出现。
文档通过评审后进入开发，需求条目和文档状态需要持续维护。在ONES中，需求可以作为工作项承载编号、优先级、状态和验收条件，文档与需求条目关联，评审意见和变更记录随条目留存，编写、评审到开发的状态流转在同一处可见，减少文档版本与需求状态脱节的情况。
角色分工与交付物
需求文档通常由产品负责人主笔，但内容来自多个角色，评审也需要多方参与。明确谁提供什么、谁确认什么，能减少文档来回。
| 角色 | 在文档中的职责 | 交付物 |
|---|---|---|
| 产品负责人 | 确定文档类型与结构，主笔背景、目标、范围、功能与规则，维护待定项 | 需求文档主体、需求条目、待定项清单 |
| 业务方 | 提供业务目标、场景和规则依据，确认范围与优先级 | 业务诉求说明、范围确认意见 |
| 研发 | 参与可行性评估，补充数据、接口、约束条件，评审技术相关内容 | 技术约束说明、接口约定、评审意见 |
| 测试 | 评审验收标准的可验证性，提前识别不可测条目 | 验收标准评审意见、测试关注点 |
| 设计 | 确认流程与交互场景的一致性，指出场景缺口 | 交互场景意见、原型引用 |
评审参与角色建议覆盖业务方、研发、测试和设计，规模小的需求可精简，但业务确认和测试确认不宜省略。签署方式按团队习惯选择，可以是评审会结论记录，也可以是文档中的确认状态，关键是留下可追溯的确认记录。
文档负责人通常由产品负责人担任，负责版本和待定项的推进。变更责任人需要明确：评审通过后的需求变更，由谁评估影响、谁批准、谁更新文档和验收标准。变更责任人不明确，文档会在开发过程中逐渐与实现脱节。
示例：一个功能需求的文档片段
以下片段为演示情景，展示骨架与条目写法如何落地。
背景与目标：当前员工提交报销后，审批人需要线下询问单据是否齐全，平均处理周期较长。本次目标是让审批人在系统中直接看到单据完整性和校验结果，减少往返沟通。
范围与角色：范围为报销单提交校验、审批页展示校验结果两部分；本期不包含报销标准自动稽核。涉及角色为提交人、审批人、财务复核人。
主流程与规则条目：
- REQ-01 提交校验：提交人提交报销单时，系统校验必填字段和附件数量；校验不通过时阻止提交，并在对应字段旁显示具体缺失项。来源：财务反馈；优先级：高；状态：待评审。
- REQ-02 审批展示：审批人打开审批页时，系统展示该单据的校验结果和附件清单；单据在提交后被修改的，展示最新校验时间。来源：审批场景访谈；优先级：高；状态：待评审。
- REQ-03 异常处理：校验服务超时或不可用时，系统允许提交但标记“待复核”，并在审批页提示审批人人工核对。来源：研发评估；优先级：中；状态：待评审。
验收标准：REQ-01对应“给定必填字段为空，当提交人点击提交，则系统阻止提交并显示缺失字段名称”；REQ-02对应“给定单据已提交，当审批人打开审批页，则页面展示校验结果和附件清单”；REQ-03对应“给定校验服务超时，当提交人提交单据，则单据状态为待复核且审批页显示人工核对提示”。
待定项：校验结果的保留时长尚未确定，负责人为产品负责人，计划在评审前与财务确认；附件数量上限沿用现有规则，引用现有制度文档，不在本文重复。
写完怎么检查：完成检查清单
文档达到可评审、可开发状态，可以用下面四组清单逐项核对。每项不通过时，要么修改文档，要么登记为待定项并写明负责人和时间。
完整性与一致性
- 背景、目标、范围、角色、流程、功能与规则、数据与接口、非功能要求、验收标准、待定项各节齐全，或已说明省略理由。
- 范围中的“不做什么”已写明，与功能条目没有冲突。
- 每条需求有唯一编号，验收标准能对应到编号。
- 引用的术语、权限、接口文档指向明确来源，正文没有重复维护同一规则。
可验证性与歧义
- 需求描述中没有“友好、快速、尽量、适当”等无法判断的表述。
- 每条需求至少有一条可执行的验收条件。
- 异常和边界情况已覆盖：空值、上下限、重复操作、外部依赖失败。
- 非功能要求有指标、测量条件和适用范围。
待定项、依赖与风险
- 所有未决问题都在待定项中，标明负责人和计划确认时间。
- 外部依赖（其他系统、第三方服务、上游数据）已列出，并说明依赖失败时的处理。
- 影响范围较大的风险已记录，评审时已讨论应对方式。
评审通过与变更维护
- 评审意见逐条有处理结论，采纳的已修改，不采纳的已说明理由并确认。
- 业务方、研发、测试的关键确认已留下记录。
- 文档版本与需求状态一致，评审通过的版本已标记。
- 变更责任人和变更流程已明确，后续修改有记录可追溯。
清单全部通过，文档即可进入开发和验收环节；仍有未关闭项的，在待定项中保留并跟踪，避免带着模糊结论进入实现。
常见问题
需求文档写完之后，评审前还需要做哪些准备？
评审前至少完成三件事：按完成检查清单自查一遍，把格式、遗漏和无法验证的表述先改掉；把待定项整理成清单，标明负责人和计划确认时间；提前把文档发给评审参与人，让他们带着问题来。这样评审时间主要花在方案分歧和风险上，而不是基础错误。
如果自查发现某些输入还没确认，不必等全部确认再评审，可以把缺口作为待定项带入评审，请相关角色当场给出结论或确认时间。
需求文档里的待定项一直没人关闭，怎么处理？
待定项需要像需求条目一样被跟踪：每条写明问题、负责人、计划确认时间和当前状态，并在每次评审开始时先过一遍未关闭项。超过计划时间仍未关闭的，由文档负责人升级给对应决策人，明确是继续等待、缩小范围还是调整方案。
带着未关闭的待定项进入开发时，要在文档中标注该条目对应的实现范围，避免开发按假设推进、验收时才发现结论不同。
小团队或需求比较简单时，章节骨架可以精简吗？
可以精简，但建议保留背景与目标、范围与角色、功能与规则、验收标准、待定项这几节，它们分别回答为什么做、做到哪、做什么、怎么算完成、还有什么没定。流程与场景、数据与接口、非功能要求可以按实际涉及的内容合并或省略，省略时在文档中说明理由。
精简的是章节数量，不是可验证性：每条需求仍然要有编号和验收条件，否则开发和测试缺少共同依据。
需求评审通过后发生变更，文档应该怎么维护？
评审通过后的变更要有明确入口：由变更责任人评估影响范围，判断是否涉及验收标准、排期或已开发内容，批准后更新文档并记录变更原因和版本。受影响的验收标准同步修改，已完成的开发或测试工作标注需要回归的范围。
变更记录与需求条目关联保存，后续追溯时能看到某条需求从初稿到当前版本的结论变化，避免文档版本与实现状态脱节。
业务方和研发对同一条需求的理解不一致，文档怎么处理？
先把分歧落到具体条目上：是目标不同、范围不同，还是对规则和异常行为的预期不同。目标与范围的分歧由业务方确认；规则、数据和异常处理的分歧由研发给出可行方案，产品负责人综合后写入文档。
结论写进需求条目和验收条件，并在评审记录中留下确认人。口头达成的共识如果不落文档，后续开发和验收仍会各按各的理解执行。
