项目范围说明书回答“这次交付什么、做到什么程度算完成”，需求文档回答“相关方需要什么、成果要满足哪些具体条件”。两份文件在范围管理中前后衔接：需求文档为范围定义提供输入，范围说明书确认边界后成为范围基准的组成部分，再由WBS把可交付成果分解为可管理的工作包。本文按这一顺序说明两者的分工、差异与落地方式。
要点总览（TL;DR）
- 项目范围说明书锁定本次交付边界与验收标准，是范围基准的组成部分；需求文档记录相关方需要什么及具体条件，是范围定义的输入。
- 两者的产出顺序是：需求文档支撑范围说明书，范围说明书确认边界后进入基准，WBS再把可交付成果分解为工作包。
- 需求条目描述“要满足什么条件”，范围边界描述“本次交付哪些成果、哪些明确排除”，验收标准可分需求级与交付物级两层书写。
- 需求变更触及已确认的交付边界时，应同步修订范围说明书并重新确认，再调整受影响的WBS工作包。
- 需求不确定性高的项目侧重需求文档，交付边界争议多的项目侧重范围说明书；小型项目在边界与需求仍可分别识别的条件下可合并简化。
两者在范围管理中的分工
项目范围说明书的核心任务是锁定交付边界。它描述项目要产出的产品、服务或成果，明确主要可交付成果，写明验收标准与范围除外事项，并记录假设条件和制约因素。项目经理、发起人和客户依据这份文件确认“做完什么算完成”，后续的范围控制也以它为参照，判断新增内容属于范围内工作还是范围外请求。
需求文档的核心任务是承载相关方的需要。它记录业务需求、相关方需求、功能需求与非功能需求，说明每项需求的来源、优先级和验收条件。业务分析师、产品负责人和相关方围绕它开展需求收集、分析与确认，开发与测试人员据此理解要实现的细节。需求文档处在需求收集与分析环节，是范围定义的直接输入。
两者的产出关系可以概括为一条链路：先通过需求收集与分析形成需求文档，再从确认的需求中提炼出项目要交付的范围，写成范围说明书；范围说明书经确认后进入范围基准，与WBS、进度计划共同构成范围管理的参照；最后由WBS把范围说明书中的可交付成果逐层分解为工作包，作为估算、排期和控制的单元。需求文档回答“需要什么”，范围说明书回答“本次交付什么、边界在哪”，WBS回答“交付物由哪些工作组成”。
这条链路也决定了两份文件不能互相替代。只有需求文档，团队知道要满足哪些条件，却缺少对本次交付边界的正式确认，范围蔓延时没有判断依据；只有范围说明书，边界清楚但需求细节不足，开发和验收容易在具体条件上产生分歧。
同口径差异对照
下表按核心问题、主要读者、内容构成、在范围管理中的位置和变更关注点五个维度对照两份文件，便于在同一口径下比较。
| 对照维度 | 项目范围说明书 | 需求文档 |
|---|---|---|
| 核心问题 | 本次交付什么，做到什么程度算完成，哪些内容不在范围内 | 相关方需要什么，成果要满足哪些具体条件和质量要求 |
| 主要读者 | 项目发起人、客户、项目经理、范围控制与验收相关角色 | 业务分析师、产品负责人、开发、测试及相关方 |
| 内容构成 | 项目目标、产品范围描述、主要可交付成果、验收标准、范围除外事项、假设条件与制约因素 | 业务需求、相关方需求、功能与非功能需求、需求优先级、需求来源与验收条件 |
| 在范围管理中的位置 | 范围定义的输出，范围基准的组成部分，范围控制与验收的参照 | 需求收集与分析的载体，范围定义的输入 |
| 变更关注点 | 交付边界是否变化，验收标准是否调整，是否触发范围基准更新 | 需求条目是否新增、修改或删除，优先级与验收条件是否变化 |
WBS是范围分解的产物，位置在范围说明书之后。它把范围说明书中的可交付成果分解为可管理的工作包，本身不承担确认边界或记录需求细节的职责。三者的顺序是：需求文档支撑范围说明书，范围说明书确认边界后进入基准，WBS在基准范围内完成分解。
边界如何划分：常见混淆与判断方法
最常见的混淆是把需求条目直接当作范围边界。需求条目描述的是“要满足什么条件”，一条需求可以对应多个交付物，一个交付物也可能承载多条需求。范围边界描述的是“本次交付包含哪些成果、哪些明确排除”，它从需求中提炼而来，但经过取舍和确认。判断方法是：如果一句话在说某项功能应具备什么行为，它属于需求文档；如果一句话在说本次项目交付哪些成果、哪些不做，它属于范围说明书。
验收标准的归属也容易混。可行的做法是分层书写：需求文档为每条需求写验收条件，说明该需求怎样算满足；范围说明书写项目级或交付物级的验收标准，说明整体交付通过验收的依据。两层标准相互引用，需求级条件支撑交付物级标准，避免同一句话在两份文件中重复维护。
范围蔓延与需求变更的区分，看变化是否触及已确认的交付边界。需求文档内部条目的细化、澄清或优先级调整，属于需求变更，按需求管理流程处理；新增交付物、扩大交付范围或改变验收标准，触及范围说明书确认的边界，属于范围变更，需要走范围基准的变更评估。实际操作中，需求变更累积到影响交付边界时，应同步更新范围说明书，而不是让边界停留在旧版本。
范围分解本身属于范围管理的工作，本文只说明WBS在链路中的位置；具体如何分解交付物、如何组织执行任务，属于范围分解与任务拆解主题；范围调整的审批流程属于变更管理主题，本文不展开。
在文档与工作项中落地两份文件
落地时先解决承载问题：需求文档需要支持多人协作编写、评审留痕和版本回溯；范围说明书需要支持正式确认和基线化，便于后续对比偏差。ONES Wiki 支持富文本编辑、Markdown 语法和代码块，成员可以在线添加注释与评论，并使用模板库创建文档；页面组可关联项目，使需求与文档互相对应；页面版本会被记录，支持随时查看与回滚，并可为不同角色配置读写权限。这些能力适合承载需求文档的编写、评审讨论与版本管理。
一条可执行的流程如下：
- 在文档空间中建立需求文档，按业务需求、功能需求、非功能需求分节编写，每条需求标注来源、优先级和验收条件；组织相关方在线评论，评审结论回写到文档中，形成确认版本。
- 从确认的需求中提炼交付边界，编写范围说明书，写明主要可交付成果、验收标准与范围除外事项；由发起人和客户确认后，将确认版本作为后续对照的基准。
- 在项目计划中按交付物或项目阶段建立WBS，把范围说明书中的可交付成果分解为工作包，并关联研发任务与迭代。ONES 瀑布项目管理解决方案支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，项目经理可以在项目计划中关联迭代和研发任务。
- 执行过程中设置项目计划和里程碑基线，对比计划与执行的偏差；通过版本对比追溯变更细节。ONES 瀑布项目管理支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过对比版本细节追溯变更细节。
- 发生变更时联动更新：需求条目变化先更新需求文档，若影响交付边界，再修订范围说明书并重新确认，随后调整WBS中受影响的工作包，保持三份内容一致。
这条流程中，文档承担需求与边界的记录和确认，工作项承担分解后的执行跟踪，两者的衔接点是范围说明书确认后的WBS分解与任务关联。
适配场景与选择建议
需求不确定性高的项目，投入应侧重需求文档。此类项目的交付边界在早期难以一次确定，需要先通过需求收集、原型验证和迭代澄清把需求摸清，再逐步收敛范围。建议保持需求文档的持续更新，按优先级分层管理，范围说明书可以先用较粗的交付物清单加除外事项，待需求稳定后细化验收标准。
交付边界争议多、相关方众多的项目，投入应侧重范围说明书。此类项目的风险集中在“算不算完成”“这项做不做”的争论上，需要尽早把可交付成果、验收标准和范围除外事项写清楚并获得正式确认，把边界作为后续沟通的依据。需求文档仍需维护，但重点放在支撑边界确认的关键需求上。
小型项目在交付内容简单、相关方少、变更影响可控的条件下，可以把两份文件合并简化：用一份文档分节写需求与交付边界，验收标准集中在一处。合并的前提是边界和需求仍能分别识别，变更时能判断影响的是需求细节还是交付范围。
无论采用哪种侧重，两份文件都需要维护的最低要求是：需求条目有来源和验收条件，交付边界有明确的可交付成果与除外事项，两者之间有可追溯的对应关系，变更发生后同步更新而不是只改其中一份。做到这几点，范围说明书与需求文档就能各司其职，并在WBS分解与执行跟踪中保持衔接。
常见问题
需求文档里的验收条件和范围说明书里的验收标准，写重了怎么办？
建议分层书写，避免同一句话在两处重复维护。需求文档为每条需求写验收条件，说明该需求怎样算满足；范围说明书写项目级或交付物级的验收标准，说明整体交付通过验收的依据。两层之间相互引用，需求级条件支撑交付物级标准。评审时重点检查两处是否口径一致，而不是追求文字完全相同。
需求变更频繁时，范围说明书是不是要跟着每次改动都更新？
看变更是否触及已确认的交付边界。需求条目的细化、澄清或优先级调整，属于需求变更，更新需求文档即可；新增交付物、扩大交付范围或改变验收标准，触及范围说明书确认的边界，需要走范围变更评估并修订范围说明书。实际操作中，当需求变更累积到影响交付边界时，应同步更新范围说明书，避免边界停留在旧版本。
项目很小、人手有限，两份文件可以合并成一份吗？
在交付内容简单、相关方少、变更影响可控的条件下可以合并，用一份文档分节写需求与交付边界，验收标准集中在一处。合并的前提是边界和需求仍能分别识别：变更发生时，团队能判断影响的是需求细节还是交付范围。如果项目后续扩大或相关方增多，再拆分为两份文件。
范围说明书确认后，WBS分解出来的工作包和需求文档怎么对应？
常见的做法是建立可追溯的对应关系：每个工作包标注它支撑的可交付成果，并关联到对应的需求条目。这样在执行中，需求变化能定位到受影响的工作包，工作包延期也能回溯到它承载的需求。ONES 瀑布项目管理支持在项目计划中按目标、交付物或项目阶段等维度分解计划和工作，并关联迭代与研发任务，可作为承载分解结果的工具之一。
两份文件都维护，最低要做到什么程度才算够用？
最低要求有三点：需求条目有来源和验收条件；交付边界有明确的可交付成果与除外事项；两者之间有可追溯的对应关系。此外，变更发生后要同步更新，而不是只改其中一份。做到这几点，范围说明书与需求文档就能各司其职，并在WBS分解与执行跟踪中保持衔接。
