需求文档怎么写，关键在动笔前先定文档类型和读者，再按固定骨架填写，把每条需求写成可验证、可验收的条目，经评审确认后进入变更管理。本文给出一套可直接套用的章节结构、条目写法、编写评审流程与发布前检查清单，适合第一次负责需求文档的产品、业务或项目人员使用。
要点总览（TL;DR）
- 动笔前先定文档类型与读者：业务需求说明、产品需求文档、需求规格说明、迭代需求条目各有不同的粒度与维护方式。
- 按“背景与目标—范围与角色—流程与场景—功能需求—数据与规则—非功能要求—验收标准与待决问题”八章搭骨架，每章写清填写要点与常见遗漏。
- 每条需求只表达一个可独立验收的能力，用“角色＋场景＋动作＋结果＋约束”统一句式，并标注编号、来源、优先级与状态。
- 编写流程按收集输入、起草、自查、评审、定稿基线、变更管理推进，评审记录与版本记录作为交接证据。
- 发布前用检查清单逐项核对：章节齐全、条目可验收、编号唯一、非功能要求可度量、待决问题有归属、版本已基线。
先定文档类型与读者，再动笔
需求文档写不清楚，常见原因是一份文档同时承担多种用途：既要向业务方说明价值，又要给研发讲实现细节，还要给测试提供验收依据。动笔前先做定位判断，可以显著减少后续返工。
按用途区分，常见的四类文档承担不同任务：
- 业务需求说明：说明业务问题、目标与价值，读者是业务方和管理层，粒度到业务能力即可。
- 产品需求文档：描述产品功能、流程与规则，读者是研发、测试和设计，需要写到可实现的颗粒度。
- 需求规格说明：面向外部供应商或跨团队交付，强调接口、约束与验收条件的完整性。
- 迭代需求条目：进入开发排期的单条需求，粒度最小，要求可独立验收。
读者不同，关注点也不同。业务方关心目标、范围和优先级；研发关心流程、规则、数据与系统约束；测试关心验收标准和异常路径；外部供应商还需要明确的接口边界与责任划分。一份文档服务所有人，往往导致每类读者都找不到自己要的信息。
定位完成后，确定文档粒度与更新频率，并指定单一事实来源：同一需求只在一处维护正文，其他位置引用而非复制。可以用下表记录定位结论。
| 文档类型 | 主要读者 | 粒度 | 更新频率 | 维护责任人 |
|---|---|---|---|---|
| 业务需求说明 | 业务方、管理层 | 业务能力级 | 立项与目标调整时 | 需求负责人 |
| 产品需求文档 | 研发、测试、设计 | 功能与流程级 | 每个版本迭代 | 产品经理 |
| 需求规格说明 | 外部供应商、对接团队 | 接口与验收级 | 合同或交付节点 | 需求负责人 |
| 迭代需求条目 | 研发、测试 | 单条可验收需求 | 随迭代滚动 | 需求提出人与产品经理 |
需求文档的标准结构与各章写法
一份可评审、可验收的需求文档，通常包含八个部分。以下骨架适用于产品需求文档和需求规格说明，业务需求说明可裁剪功能与数据章节。
背景与目标
说明要解决什么问题、为什么现在做、业务价值是什么，以及如何判断做成了。成功判断要落到可观察的指标或业务结果，例如“订单人工录入环节从每单5分钟降到2分钟以内”，避免只写“提升效率”。
范围与角色
明确本次做什么、不做什么，列出涉及的角色及其权限。范围之外的内容单独列出，作为后续版本的输入，防止评审时反复拉扯边界。
流程与场景
先写主流程，再写分支和异常路径。每个场景说明触发条件、参与角色、操作步骤和结果状态。异常路径是测试用例的重要来源，不能省略。
功能需求
按功能模块组织，每条需求包含编号、描述、输入输出、业务规则与约束。编号规则在文档开头统一约定，例如“模块缩写-序号”。
数据与规则
列出关键字段、字段含义、类型与必填要求，说明状态流转和校验规则，以及计算口径。涉及统计或金额时，写清取数范围和精度。
非功能要求
性能、安全、兼容性、可用性等要求要写成可度量指标，例如“列表页在1万条数据下加载时间不超过2秒”“支持主流浏览器最近两个大版本”。
验收标准与待决问题
验收标准写可验证的通过条件，与功能需求逐条对应。待决问题单独成表，记录问题、责任人、期望关闭时间，评审前尽量收敛。
| 章节 | 填写要点 | 常见遗漏 |
|---|---|---|
| 背景与目标 | 问题、价值、成功判断 | 成功判断不可观察 |
| 范围与角色 | 做与不做、角色权限 | 未写范围外内容 |
| 流程与场景 | 主流程、分支、异常 | 异常路径缺失 |
| 功能需求 | 编号、描述、输入输出、规则 | 多条能力混在一条 |
| 数据与规则 | 字段、状态、校验、口径 | 计算口径含糊 |
| 非功能要求 | 可度量指标 | 只写“性能良好” |
| 验收标准与待决问题 | 通过条件、责任人 | 待决问题无归属 |
把需求写成可验证条目的方法
需求文档的整体结构解决“写哪些章”，条目写法解决“每条写到什么程度”。判断标准很简单：测试人员能否只读这一条就设计出通过与否的判断条件。
具体做法包括：
- 一条需求只表达一个可独立验收的能力。包含多个动作时拆成多条，便于分别排期和验收。
- 使用统一句式：角色＋场景＋动作＋结果＋约束。例如“仓库管理员在入库单审核页提交审核后，系统生成待上架任务，同一单据不可重复提交”。
- 标注唯一编号、来源、优先级和状态。来源写清业务方、用户反馈或合规要求，便于追溯；状态至少区分草稿、待评审、已确认、已变更。
- 用验收标准把需求转成判断条件。验收标准写成“给定……当……则……”的形式，覆盖正常与异常情况。
- 处理模糊词。把“快速”改为具体时长，把“友好”改为具体交互结果，把“尽量”改为明确的边界条件或直接删除。
条目写完后做一次自查：去掉上下文，单看这一条能否被独立理解和验收；编号是否连续唯一；验收标准是否覆盖了描述中的每个约束。
编写流程：从收集到评审确认
需求文档从起草到定稿是一串有交接的动作，每一步都有输入和输出，缺一环就容易在评审时暴露问题。
- 收集输入：汇总业务目标、用户反馈、现有流程与系统约束。输出是一份原始需求清单，暂不追求完整表述。
- 起草骨架：先按结构填背景、范围、流程与场景，再写功能条目。先场景后功能，能避免功能描述脱离实际使用。
- 自查：检查条目完整性、编号连续、待决问题是否收敛。输出是可供评审的初稿。
- 评审：业务、研发、测试共同确认范围与验收标准。评审要产出明确结论：通过、有条件通过或退回修改，并记录修改项。
- 定稿与基线：确认版本号，文档进入基线状态，后续修改走变更流程。
- 变更管理：需求调整时记录变更原因、影响范围（功能、排期、测试用例）和重新确认结果，避免口头变更导致文档与实现脱节。
在工具中承载这套流程时，需求条目与文档需要保持对应关系。ONES Wiki 支持文档关联项目任务，页面组可关联项目，使需求与文档互相对应；文档实时同步并记录页面版本，支持查看与回滚，便于基线后的变更追溯。ONES 通过统一的业务需求池与产品需求池联动业务反馈与产品开发，需求确认后可继续流转到任务与测试环节。具体字段配置与操作路径以实际环境为准。
角色分工与各阶段交付物
需求文档的责任要落到具体角色，避免“大家一起写”变成无人负责。下表给出常见分工，团队规模较小时可由一人兼任多个角色，但职责边界仍需明确。
| 角色 | 主要动作 | 阶段交付物 |
|---|---|---|
| 需求负责人 | 组织收集、起草文档、维护待决问题 | 需求文档初稿、待决问题清单 |
| 业务方 | 确认目标、范围与优先级 | 目标与优先级确认意见 |
| 研发 | 评估可行性、补充技术约束 | 可行性意见、约束说明 |
| 测试 | 确认验收标准可测性 | 验收标准补充与确认记录 |
| 评审组织者 | 召集评审、记录结论 | 评审记录、修改项清单 |
评审记录与版本记录是交接证据：评审记录说明谁在什么时间确认了什么，版本记录说明基线之后改了什么、为什么改。两者与需求文档放在同一处维护，后续追溯时不必再翻聊天记录。
示例：一条需求从描述到验收
以下为演示情景，用于说明写法，不代表真实项目案例。背景设定：某内部审批系统需要支持报销单撤回，角色为提交报销的员工和审批人。
改写前的描述：“员工提交报销后如果发现填错，可以快速撤回，体验要友好。”
这条描述存在三个问题：未说明撤回的时间或状态条件，“快速”和“友好”无法验收，未说明撤回后的审批状态如何处理。
改写后的可验证表述：
- 编号：EXP-012
- 需求描述：报销提交人在审批人未处理前，可在“我的报销”列表撤回该单据；撤回后单据状态变为“已撤回”，审批人待办中移除该单据，提交人可修改后重新提交。
- 约束：审批人已处理后不可撤回，页面给出提示说明当前状态。
- 来源：财务部反馈；优先级：高；状态：待评审。
对应验收标准：
- 给定一张待审批状态的报销单，当提交人点击撤回，则单据状态变为“已撤回”，审批人待办列表不再显示该单据。
- 给定一张审批人已通过的单据，当提交人尝试撤回，则系统拒绝操作并提示“单据已处理，无法撤回”。
- 给定一张已撤回单据，当提交人修改后重新提交，则生成新的待审批记录，原撤回记录保留可查。
这个示例可迁移的规律是：把模糊的体验要求转成状态条件和操作结果，把每个约束都对应到一条验收标准。适用边界在于，涉及金额计算、权限分级或跨系统同步的需求，还需要补充数据口径和接口约束章节，不能只靠条目描述。
完成检查：发布前的核对清单
文档是否可以交付，用清单逐项判断，比凭感觉判断更可靠。以下检查项全部通过，再进入评审或基线。
- 结构与必填章节齐全：背景与目标、范围与角色、流程与场景、功能需求、数据与规则、非功能要求、验收标准与待决问题均有内容。
- 每条需求可独立验收：单条需求只表达一个能力，去掉上下文仍可理解。
- 编号唯一且连续：编号规则在文档开头说明，无重复、无跳号。
- 验收标准与需求逐条对应：正常与异常情况均有判断条件。
- 非功能要求可度量：性能、安全、兼容性等写成具体指标和适用范围。
- 待决问题已关闭或明确责任人：未关闭项标注责任人与期望关闭时间。
- 评审已完成：评审记录包含结论与修改项，修改项已闭环。
- 版本已基线化：版本号、基线时间与变更入口明确。
清单中的每一项都能对应到前文的章节或流程动作，检查不通过时回到对应环节补充，而不是在评审会上临时解释。
常见问题
需求文档一定要写满八个章节吗？
不一定。八章骨架适用于产品需求文档和需求规格说明，业务需求说明可以裁剪功能需求、数据与规则等章节，只保留背景与目标、范围与角色、成功判断。判断依据是读者：如果文档主要给业务方和管理层看，写到业务能力级即可；如果要交给研发和测试排期实现，功能条目、数据规则、非功能要求和验收标准就需要补齐。
需求评审时业务方和研发对范围有分歧，怎么处理？
先把分歧落到具体条目上，而不是在整份文档层面争论。做法是：把争议内容拆成独立需求条目，分别标注来源、优先级和影响范围，由业务方确认优先级、研发评估可行性，评审组织者记录结论为“通过”“有条件通过”或“退回修改”。暂时无法达成一致的内容移入待决问题表，写明责任人和期望关闭时间，避免阻塞其余已确认条目的定稿。
需求文档定稿后业务方又要改，文档怎么维护？
定稿并基线化之后，修改走变更流程：记录变更原因、影响范围（涉及的功能条目、排期、测试用例）和重新确认结果，再更新文档版本。文档与需求条目保持对应关系，变更时同步更新两处，避免文档与实现脱节。ONES Wiki 的文档实时同步并记录页面版本，支持查看与回滚，可用于基线后的变更追溯；具体操作以实际环境为准。
非功能要求写到什么程度才算可度量？
每条非功能要求都要有指标、条件和适用范围。例如性能写成“列表页在1万条数据下加载时间不超过2秒”，兼容性写成“支持主流浏览器最近两个大版本”，安全要求写清需要控制的对象和验证方式。只写“性能良好”“体验流畅”无法在测试阶段判断通过与否，也无法在验收时形成结论。
小团队没有专职测试，验收标准由谁确认？
可以由需求负责人起草验收标准，再由实际执行验证的人确认可测性。团队规模小时一人可能兼任多个角色，但职责边界仍要写清：谁起草、谁确认、谁记录结论。评审记录中注明验收标准的确认人和确认时间，后续出现理解差异时有据可查。若确实无人承担测试职责，至少在文档中保留验收标准章节，作为交付时自查的依据。
