范围边界约定和范围说明书都用于界定项目范围，但回答的问题不同：前者说明“哪些在范围内、哪些在范围外”，后者说明“要交付什么、按什么标准验收”。本文按同一组维度比较两者的内容、颗粒度与使用时机，并给出配合顺序和常见写法示例，帮助你在项目文档中把这两份材料放对位置。
要点总览（TL;DR）
- 范围边界约定回答“在不在范围内”，用条目清单和排除项给出可判定的边界；范围说明书回答“交付什么、按什么标准验收”，描述项目整体轮廓。
- 两者按核心问题、主要内容、颗粒度、使用时机、责任人和变更方式六个维度区分：边界约定是条目级、可判定，范围说明书是成果级、可共识。
- 项目启动阶段先写范围说明书，明确目标与主要可交付成果；范围易蔓延、跨团队接口多时，再据此补充边界约定，并回填说明书中的引用位置。
- 边界约定要写清范围内事项、排除项、模糊地带判定规则和接口边界；范围说明书要写清项目目标、可交付成果、验收标准与假设制约条件。
- 常见写法偏差是把排除项塞进范围说明书、把边界约定写成任务清单；排除项集中放边界约定，任务拆解交给计划或工作分解结构。
两者分别回答什么问题
范围边界约定回答的是“在不在范围内”。它把项目涉及的事项逐条归类为纳入、排除或待定，并对容易混淆的地带给出判定规则。读者看完这份材料，应当能对某个具体需求或工作内容作出“做”或“不做”的判断。
范围说明书回答的是“交付什么、如何验收”。它描述项目目标、主要可交付成果、验收标准以及假设与制约条件，是项目团队与干系人对成果形态达成共识的基础文件。它不逐条列举排除项，而是把项目要达成的结果讲清楚。
在项目文档体系中，范围说明书通常位于范围管理的上游，界定项目的整体轮廓；范围边界约定更像一份补充说明，挂在范围说明书之下或与之并列，专门处理边界上的争议点。两者的关系可以理解为：范围说明书给出全景，边界约定标出围栏的具体位置和缺口。
同口径差异对照
下表按核心问题、主要内容、颗粒度、使用时机、责任人和变更方式六个维度对照两个对象。其中责任人一栏按通用实践给出常见角色，具体名称需结合组织实际确定；变更方式一栏中涉及审批环节的细节属于变更管理范畴，此处只说明两份材料各自如何被修改。
| 比较维度 | 范围边界约定 | 范围说明书 |
|---|---|---|
| 核心问题 | 哪些事项在范围内、哪些在范围外 | 要交付什么、按什么标准验收 |
| 主要内容 | 范围内事项清单、排除项、模糊地带判定规则、接口边界 | 项目目标与背景、主要可交付成果、验收标准、假设与制约条件 |
| 颗粒度 | 条目级，逐项列明，允许出现“待定”条目 | 成果级，描述可交付成果的整体形态与验收口径 |
| 使用时机 | 范围易蔓延、跨团队接口多、需求争议频繁时补充编制 | 项目启动阶段编制，作为范围基准的组成部分 |
| 责任人 | 通常由项目经理牵头，产品负责人与相关团队接口人共同确认（具体角色待核实） | 通常由项目经理组织编写，发起人与主要干系人评审确认（具体角色待核实） |
| 变更方式 | 边界条目增减需同步更新排除项与判定规则，并通知相关接口方 | 目标、可交付成果或验收标准变化时修订，修订后重新评审 |
从表中可以看出，两份材料的差异集中在“清单式”与“描述式”两种写法上。边界约定追求可判定，范围说明书追求可共识。实际使用时，两者共享同一套项目背景信息，避免出现边界条目与说明书描述互相矛盾的情况。
范围边界约定包含哪些内容
边界约定的价值在于把模糊地带写清楚，因此它的内容围绕“判定”组织，而不是围绕“任务”组织。一份可用的边界约定通常包含以下四部分。
范围内事项清单
列出项目明确承担的事项，每条写清对象和动作，例如“完成订单模块的下单、支付回调与退款三个子流程的接口开发”。清单条目应与范围说明书中的可交付成果对应，便于交叉核对。
范围外与排除项
这是边界约定最容易被忽略也最关键的部分。排除项要写到读者不会误以为“顺便也能做”的程度，例如“本次不包含历史订单数据迁移”“不包含第三方支付渠道的对账功能”。排除项写得越具体，后续争议越少。
边界模糊地带的判定规则
对无法提前穷举的事项，给出判断依据。例如“凡涉及外部系统字段变更的需求，需经接口负责人确认后纳入”“性能优化类需求仅覆盖本模块自身接口，不涉及网关层”。规则要能被执行人直接套用，避免写成原则性口号。
与相邻项目或团队的接口边界
当项目需要与其他团队协作时，写明各自负责的环节和交接物。例如“用户中心负责提供鉴权接口，本项目的职责是完成调用与异常处理，不修改用户中心内部逻辑”。接口边界应指明交接物的形态和确认方式。
范围说明书包含哪些内容
范围说明书描述项目的整体轮廓，是验收工作的依据。它的内容按“为什么做、做什么、做到什么程度、受什么限制”的顺序组织。
项目目标与背景
说明项目要解决的问题和期望达成的结果，交代立项背景。目标应可衡量，例如“将订单处理平均耗时从当前水平降低到约定阈值”，避免写成“提升用户体验”这类无法验收的表述。
主要可交付成果
列出项目产出的主要成果物，可以是系统模块、文档、流程或服务。每项成果说明其形态和范围，例如“订单管理模块，包含下单、支付回调、退款三个子流程”。这一部分与边界约定中的范围内清单形成对应关系。
验收标准
针对每项可交付成果给出可检验的验收条件，包括功能口径、质量要求和验收方式。验收标准要写到双方对“通过”有共同理解的程度，例如“三个子流程在测试环境完成端到端验证，异常场景覆盖率不低于约定比例”。
假设与制约条件
记录项目成立所依赖的前提和外部限制，例如依赖的第三方接口按期可用、预算或工期上限、合规要求等。假设条件一旦不成立，应触发范围或计划的重新评估。
与边界约定的衔接
范围说明书在描述可交付成果时，对容易产生歧义的部分标注“详见边界约定第几条”，把逐条判定交给边界约定承载。这样说明书保持整体可读，边界约定承担细节判定，两份材料各司其职。
什么情况下用哪一个，如何配合
两份材料并非二选一，多数项目需要同时使用，区别在于投入的先后与详略。选择时可以按以下条件判断。
- 项目刚启动、干系人尚未对成果形态达成共识时，先写范围说明书。此时最重要的是把目标、可交付成果和验收标准讲清楚，边界细节可以暂缓。
- 项目范围容易蔓延、需求方较多、跨团队接口复杂时，在范围说明书基础上补充边界约定。把争议高发的地带逐条划清，能减少执行期的反复确认。
- 项目规模小、参与方少、成果形态单一，可以只写范围说明书，在验收标准中顺带说明不包含的内容；若仍出现边界争议，再补一份简版边界约定。
两者同时使用时的顺序是：先完成范围说明书，明确项目目标与主要可交付成果；再据此编制边界约定，把可交付成果周边容易混淆的事项逐条归类；最后回填范围说明书中的引用位置，形成互相指向的关系。执行过程中，边界条目与说明书条目应保持同一套编号或命名，便于对照。
当范围发生调整时，两份材料都需要相应修订，并按项目变更管理的要求走审批与记录，本文不展开具体流程。需要强调的是，边界约定中标注为“待定”的条目应有明确的确认时点和确认人，避免长期悬空。
在文档与工作项需要联动管理的场景中，ONES 瀑布项目管理解决方案支持在项目下管理需求范围、研发任务与流水线，并可用「项目计划」按目标、交付物或项目阶段等维度创建工作分解结构。团队可以把范围说明书作为项目文档承载整体描述，把边界条目对应到具体工作项，通过计划与里程碑基线对比计划与执行的偏差，并在范围调整后追溯变更细节。这类承载方式适合采用瀑布管理方式的团队，具体文档模板与关联机制需结合实际部署确认。
常见误解与写法示例
两份材料在写法上最容易出现两类偏差：把排除项塞进范围说明书，以及把边界约定写成任务清单。下面分别说明，并给出一组对照示例。
误解一：把排除项写进范围说明书
范围说明书的主线是描述交付成果，若在其中大量罗列“不包含什么”，会削弱成果描述的清晰度，读者也难以判断哪些是真正的边界。更合适的做法是在说明书中用一句话指向边界约定，把排除项集中放在边界约定里逐条列明。
误解二：把边界约定写成任务清单
边界约定的每条内容应回答“在不在范围内”，而不是“谁在什么时候做什么”。例如“前端开发登录页”属于任务拆解，应放在计划或工作分解结构中；边界约定应写成“登录页的界面开发在范围内，短信验证码通道的采购与配置不在范围内”。前者描述执行动作，后者描述范围归属。
示例：某功能模块的条目对照
假设项目为订单模块改造，范围说明书中的条目可写为：“可交付成果：订单管理模块，包含下单、支付回调、退款三个子流程；验收标准：三个子流程完成端到端验证，异常场景按约定覆盖。”对应的边界约定条目则写为：“范围内：三个子流程的接口开发与联调；范围外：历史订单数据迁移、第三方渠道对账功能；判定规则：涉及外部系统字段变更的需求，经接口负责人确认后纳入；接口边界：用户中心提供鉴权接口，本项目负责调用与异常处理。”
对照可见，说明书回答“交付什么、怎么算通过”，边界约定回答“哪些做、哪些不做、拿不准时按什么规则判断”。把这两类内容分开放置，评审时也更容易分工：业务方重点确认说明书中的目标与验收标准，技术接口人重点确认边界约定中的排除项与接口边界。
常见问题
范围边界约定和范围说明书可以合并成一份文档吗？
可以合并，但需要保留两类内容的分工。合并后的文档中，前半部分按范围说明书的顺序写目标、可交付成果和验收标准，后半部分集中列范围内事项、排除项和判定规则，并用小标题或编号区分。合并适合参与方少、范围相对稳定的项目；当项目跨多个团队、接口边界复杂时，分开维护更便于不同角色分别评审和更新，避免一份文档被频繁改动而失去稳定性。
边界约定里标注为“待定”的条目应该怎么处理？
“待定”条目要同时写明确认时点、确认人和判定所需的信息，例如“在需求评审会后由接口负责人确认是否纳入”。待定条目不宜长期悬空，建议在项目计划的里程碑节点前集中清理一次，把能判定的转为纳入或排除，仍无法判定的升级到项目决策层。待定条目数量过多，通常说明前期信息不足或接口方未参与，需要补充沟通再定稿。
范围说明书里的验收标准写到什么程度算合适？
写到双方对“通过”有共同理解即可，不必细化到测试用例级别。可交付成果的验收标准通常包括功能口径、质量要求和验收方式三部分，例如子流程完成端到端验证、异常场景覆盖比例、由谁在什么环境确认。更细的测试设计和用例覆盖属于测试管理范畴，可以在验收标准之下另行引用，避免范围说明书变成测试文档。
项目执行中新增的需求，应该改边界约定还是走变更流程？
先判断新增需求是否落在已约定的范围内。落在范围内的事项，按边界约定的判定规则处理，同步更新条目即可；超出原范围的事项，属于范围调整，应按项目变更管理的要求评估影响、审批并记录，再相应修订范围说明书和边界约定。两份材料的修订都应保留版本，便于后续追溯哪次变更导致了哪条边界调整。
小团队项目是否也需要单独写范围边界约定？
项目规模小、参与方少、成果形态单一时，可以只写范围说明书，在验收标准附近用一小段说明不包含的内容。若执行中反复出现“这个要不要做”的争议，再补一份简版边界约定，重点列排除项和判定规则即可。判断依据是争议频率和接口方数量，而非项目预算或团队人数本身。
