确定项目范围，核心是把模糊需求转成可验收的交付物清单，明确哪些工作不在本次范围内，再由关键干系人确认形成范围基线。本文按“判断要素—五步操作—角色分工—完整示例—完成检查”展开，覆盖到范围基线建立为止；执行阶段的任务拆解和范围变更审批不在本文展开。
要点总览（TL;DR）
- 确定项目范围的核心动作是把模糊需求转成可验收的交付物清单，写明不交付什么，再由关键干系人确认形成范围基线。
- 操作上分五步：收集需求并区分业务目标与具体诉求、需求转为交付物并写验收标准、交付物分解、写排除项与假设约束、评审确认并建立基线，每步都有输入、输出和完成标志。
- 范围说明必须覆盖目标、交付物、验收标准、排除项、假设与约束五类要素；交付物写成可检查的成果，验收标准写到第三方能判断通过与否。
- 项目负责人组织内容并维护基线版本，业务方把关业务目标与验收标准，技术负责人评估可行性与技术约束，关键用户提供使用场景并验证验收标准。
- 完成检查以交付物完整性、验收标准覆盖、排除项明确、关键干系人确认、基线可追溯为阻断项，变更入口和假设责任方为一般项。
先明确范围要回答的三个问题
范围确定不是把需求文档写长，而是让项目团队和业务方对“做什么、不做什么、做到什么程度算完成”形成同一份可核对的约定。动手写范围说明之前，先用三个问题检验手头的信息是否够用：交付什么、不交付什么、凭什么算完成。三个问题都能给出具体答案，范围才有条件进入评审。
这三个问题分别对应范围说明中的不同要素。只写目标不写交付物，执行时容易各自理解；写了交付物却没有验收标准，交付后容易陷入“算不算做完”的争论；不写排除项，相关方会把相邻需求默认纳入，范围在不知不觉中膨胀。下表列出范围说明的必备要素及缺失后的典型后果，可作为起草时的对照。
| 要素 | 要回答的问题 | 缺失后的典型后果 |
|---|---|---|
| 项目目标 | 这次投入要解决什么业务问题，成功是什么状态 | 交付物清单缺少取舍依据，需求来者不拒 |
| 交付物 | 项目结束时具体交出哪些可检查的成果 | 各方对“做完”的理解不一致，验收反复 |
| 验收标准 | 每个交付物满足什么条件才算通过 | 交付后争议不断，返工范围无法界定 |
| 排除项 | 哪些相邻需求、场景、功能明确不在本次范围 | 范围被默认扩大，工期和资源被动承压 |
| 假设与约束 | 范围成立依赖哪些前提，受哪些条件限制 | 前提变化时无人预警，范围失效却未察觉 |
还需要区分范围与相邻管理动作的边界。需求回答“相关方想要什么”，范围回答“本次承诺交付什么”，任务拆解回答“由谁在什么时间完成哪些工作”，变更管理回答“基线确认后新增内容如何审批”。范围确定阶段只做到交付物清单和边界清晰，任务拆解放到执行计划中处理，变更审批放到基线确认之后处理。把这几件事混在一起写，范围说明会变成大杂烩，评审时反而抓不住重点。
从需求到交付物：确定范围的操作步骤
范围确定可以按五步推进，每一步都有明确的输入、动作、输出和完成标志。前一步的输出是后一步的输入，任何一步没有达到完成标志，都不建议跳到下一步，否则后面的评审会反复回到起点补信息。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：收集需求并区分层次 | 业务方诉求、用户反馈、合同或立项材料、现有系统现状 | 汇总需求来源，把每条需求标注为业务目标或具体诉求，合并重复项，标记相互冲突项 | 需求来源清单与需求分类记录 | 每条需求都有来源和提出人，业务目标与具体诉求分开列示 |
| 第二步：需求转为可交付成果 | 需求来源清单 | 把具体诉求归并成可检查的交付物，为每个交付物写出验收标准，标准尽量可观察、可测试 | 交付物清单及验收标准 | 每个交付物都有对应验收标准，且标准能由第三方按描述判断通过与否 |
| 第三步：交付物分解 | 交付物清单 | 按交付物、项目阶段或目标维度逐层分解，形成层级清单，检查是否有遗漏或重复 | 分层级的交付物分解清单 | 最底层条目均可直接安排工作，层级之间无交叉重复 |
| 第四步：写排除项与假设约束 | 交付物分解清单、评审中提出的相邻需求 | 逐条写明本次不交付的内容及原因，列出范围成立依赖的假设和外部约束 | 排除项清单、假设与约束说明 | 排除项具体到可识别的功能、场景或对象，假设与约束有对应责任方 |
| 第五步：评审确认并建立基线 | 范围说明草稿、交付物清单、排除项清单 | 组织关键干系人逐项评审，处理异议后定稿，记录确认人和确认时间，形成范围基线 | 经确认的范围说明书与范围基线 | 关键干系人完成确认，基线版本可追溯，后续新增内容有明确入口 |
第一步的关键动作是区分层次。业务方说“希望审批更快”，这是业务目标；说“把三级审批改成两级”，这是具体诉求。目标决定取舍方向，诉求决定交付内容。把两者混为一谈，容易出现为满足某条诉求而偏离整体目标的情况。收集时还要记录需求的提出人和使用场景，后续澄清和验收都需要回到这些信息。
第二步是范围确定中最容易做浅的环节。交付物要写成名词性的成果，例如“供应商准入审批流程配置”“对账单导出功能”，避免写成“优化流程”“提升体验”这类无法验收的表述。验收标准要写清判断条件，例如“审批节点由三级调整为两级，覆盖全部采购品类，抽检20笔历史单据可完整走通”。标准写到这个程度，评审时才能发现理解差异。
第三步的分解深度以“最底层条目能直接安排工作”为准，不必追求层数统一。分解完成后做一次反向检查：把最底层条目逐条对照项目目标，看是否都服务于目标；再对照需求来源清单，看是否有诉求没有落点。两个方向都过一遍，遗漏和冗余基本可以暴露出来。
第四步的排除项要写得具体。写“不含移动端”比写“暂不考虑其他终端”更有效，因为前者可以直接判断某个需求是否在范围内。假设与约束同样要落到具体条件，例如“范围基于现有审批引擎能力，若引擎升级则重新评估”。排除项和假设不是免责声明，而是边界说明，评审时应逐条向相关方确认。
第五步的评审重点是异议处理。评审中提出的新增内容，能纳入本次范围的当场更新交付物清单和验收标准，不能纳入的写入排除项或后续需求池。确认完成后，范围说明书、交付物清单和排除项清单共同构成范围基线。基线确认后的新增内容走变更流程，本文不展开审批细节。
谁参与确定范围：角色分工与交付物
范围确定涉及“谁来定内容”和“谁来确认边界”两类职责。内容主要由项目负责人组织业务方和技术负责人共同完成，确认由对范围和资源负责的关键干系人完成。角色不清时，常见结果是范围说明由项目负责人独自写完，评审时业务方第一次看到内容，异议集中爆发。
| 角色 | 主要职责 | 负责的交付物 |
|---|---|---|
| 项目负责人 | 组织需求收集与澄清，汇总交付物清单，主持范围评审，维护范围基线版本 | 范围说明书整体、交付物清单汇总、评审记录 |
| 业务方 | 说明业务目标与优先级，确认交付物是否覆盖核心诉求，参与排除项确认 | 业务目标说明、需求优先级、排除项确认意见 |
| 技术负责人 | 评估交付物在现有条件下的可行性，识别技术约束，参与验收标准中技术条件的制定 | 可行性评估意见、技术约束说明、验收标准中的技术条款 |
| 关键用户 | 提供实际使用场景，验证验收标准是否可操作，参与交付物试用或走查 | 使用场景说明、验收标准反馈 |
评审与签认环节建议由项目负责人组织，业务方和技术负责人共同参加，关键干系人对范围基线做最终确认。确认方式可以是会议纪要加签字，也可以是协作工具中的评审记录，关键是留下确认人、确认时间和确认版本。范围说明书的定稿责任在项目负责人，验收标准的业务部分由业务方把关，技术部分由技术负责人把关，排除项清单需要业务方和技术负责人双方确认。
范围基线建立后，交付物清单、验收标准和排除项需要在团队日常协作中可查、可追溯。以ONES为例，其瀑布项目管理方案支持用项目计划创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作；项目下可管理需求范围与研发任务；设置项目计划和里程碑基线后，可对比计划与执行的偏差。这些能力适合承载范围确定后的清单与基线，具体功能可用性以实际版本与套餐为准。范围确定阶段的方法和文档结构仍按本文步骤执行，工具承担的是记录、关联和追溯。
一个范围确定的示例：从模糊需求到范围基线
以下示例为演示情景，用于说明步骤如何落地，不对应真实项目。某制造企业的运营部门提出需求：“希望采购审批更快、更透明。”这是一个典型的模糊需求，直接进入开发会导致范围无法收敛。
第一步收集需求后，项目负责人访谈了运营、采购和财务三方，把诉求整理为：审批环节多导致周期长；申请人看不到审批进度；财务希望保留合规留痕。业务目标归纳为“缩短采购申请到审批完成的平均周期，同时保留完整审批记录”。具体诉求归并为审批节点精简、进度可见、记录可查三类。
第二步把诉求转成交付物并写验收标准，形成如下清单：
| 交付物 | 验收标准 |
|---|---|
| 采购审批流程配置 | 审批节点由三级调整为两级，覆盖全部采购品类；抽检20笔历史单据可完整走通 |
| 审批进度查询页面 | 申请人可查看当前节点、处理人和已停留时长；数据与实际审批记录一致 |
| 审批记录归档 | 每笔审批的节点、处理人、处理时间和意见完整留存，可按单据号检索 |
第三步按交付物维度分解，审批流程配置下再分流程设计、规则配置、历史单据适配三个子项；进度查询页面下分页面设计、数据接口、权限控制三个子项。分解后逐条对照业务目标，确认每个子项都服务于缩短周期或保留留痕，没有为“顺便优化界面”这类目标外内容安排工作。
第四步写排除项与假设约束。排除项包括：不含移动端审批；不含供应商侧门户；不含审批金额阈值规则的重新设计。假设与约束包括：范围基于现有审批引擎能力；历史单据适配仅覆盖近两年数据；流程调整需符合财务合规要求，由财务方确认。排除项逐条与运营和财务确认，避免后续把移动端需求默认带入。
第五步组织评审，运营、采购、财务和技术负责人参加。评审中财务提出审批记录需增加导出功能，经评估纳入本次范围，同步更新交付物清单和验收标准；运营提出的移动端需求写入排除项并转入后续需求池。确认完成后形成范围基线，记录确认人、确认时间和版本号。基线确认后的新增内容走变更流程。
范围确定后的完成检查
范围是否真正确定完成，可以用一张检查清单逐项核对。清单中的阻断项未通过时，不建议宣布范围基线建立；一般项未通过时，可以限期补充，但要在评审记录中注明。
| 检查项 | 通过标准 | 类型 |
|---|---|---|
| 交付物完整性 | 每个交付物均为可检查的成果表述，无“优化”“提升”类无法验收的条目 | 阻断项 |
| 验收标准覆盖 | 每个交付物都有验收标准，标准可由第三方按描述判断通过与否 | 阻断项 |
| 排除项明确 | 排除项具体到可识别的功能、场景或对象，并已向相关方确认 | 阻断项 |
| 关键干系人确认 | 业务方、技术负责人等关键角色完成确认，留有确认人和确认时间 | 阻断项 |
| 基线可追溯 | 范围说明书、交付物清单、排除项清单版本一致，可查到确认记录 | 阻断项 |
| 变更入口 | 团队知道基线确认后的新增内容从哪里提交、由谁评估 | 一般项 |
| 假设与约束责任方 | 每条假设和约束都有对应责任方，前提变化时有预警路径 | 一般项 |
检查时容易忽略的是基线可追溯。范围说明书改了但交付物清单没同步，评审确认的是旧版本，执行时就会出现两套口径。建议在确认前做一次版本一致性核对，确认后冻结基线版本，后续修改通过变更流程产生新版本。变更审批的具体流程不在本文范围，团队只需确保新增内容有明确入口，避免口头追加直接进入执行。
完成检查通过后，范围确定阶段结束，进入执行计划编制。此时交付物清单可以作为任务拆解的输入，验收标准可以作为测试和验收的依据，排除项清单可以在后续需求讨论中直接引用。范围基线建立得越具体，执行阶段的返工和争议越少。
常见问题
范围说明书写到什么程度可以进入评审？
判断标准是三个问题都能给出具体答案：交付什么、不交付什么、凭什么算完成。交付物要写成可检查的成果，验收标准要写到第三方按描述能判断通过与否，排除项要具体到可识别的功能、场景或对象。如果排除项还停留在“暂不考虑其他需求”这类表述，评审时无法判断某条新需求是否在范围内，建议先补充再评审。
评审时业务方临时提出新增需求，应该纳入本次范围还是拒绝？
先评估该需求是否服务于已确认的业务目标，以及纳入后对交付物清单和验收标准的影响。能纳入的，当场更新交付物清单和验收标准，并同步调整工期或资源安排；不能纳入的，写入排除项或转入后续需求池，并记录提出人和原因。两种处理都要留下记录，避免口头承诺在执行阶段变成争议。基线确认后的新增内容走变更流程。
范围基线建立后，交付物清单和验收标准放在哪里便于团队查阅？
关键是让交付物清单、验收标准和排除项清单保持同一版本、可追溯确认记录。以ONES为例，其瀑布项目管理方案支持用项目计划创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作；项目下可管理需求范围与研发任务；设置项目计划和里程碑基线后，可对比计划与执行的偏差。这些能力适合承载范围确定后的清单与基线，具体功能可用性以实际版本与套餐为准。
项目中途业务目标发生变化，原范围基线怎么处理？
先确认变化影响哪些交付物和验收标准，再判断是调整现有基线还是新开一轮范围确定。影响面小的，通过变更流程更新交付物清单和验收标准，产生新版本基线；影响面大到原目标不再成立时，建议重新走一遍需求收集和评审，避免在旧基线上反复打补丁。无论哪种情况，都要保留原基线版本和变更记录，便于后续追溯。
小团队或周期很短的项目，五步流程能否简化？
可以合并动作，但不要省略产出。周期短的项目可以把需求收集和交付物定义放在一次会议完成，排除项与假设约束随交付物清单一起写，评审与确认合并为一次短会。需要保留的是：每个交付物有验收标准、排除项写具体、确认人和确认时间有记录。这三项缺失时，项目后期出现“算不算做完”的争议概率明显上升。
