项目范围确认的依据以经批准的范围基准为核心，包括项目范围说明书、工作分解结构（WBS）和WBS词典，再配合需求文件与需求跟踪矩阵、验收标准与质量要求、可交付成果的实际完成状态与核验记录，以及干系人登记册和确认权限约定。确认的对象是已经完成的可交付成果，动作是逐项比对并由有权确认的干系人书面签认；发现偏差转入变更流程，不在确认环节直接修改范围。
要点总览（TL;DR）
- 范围确认的核心依据是经批准的范围基准：项目范围说明书、WBS和WBS词典，再配合需求文件与需求跟踪矩阵、验收标准与质量要求、可交付成果完成状态与核验记录、干系人登记册与确认权限约定。
- 确认对象是已完成的可交付成果，按四步推进：核对依据版本与批准状态、逐项比对验收标准、组织确认会议记录结论、签认或登记偏差转入变更。
- 项目经理负责组织依据汇总与确认安排，技术或业务负责人提供核验结论，客户或发起人行使确认权，记录人与配置管理员负责归档留痕。
- 确认完成的判断标准包括依据为最新批准版本、每项成果有比对结论、签字人权限匹配、偏差已登记转入变更、记录可追溯。
- 偏差在确认环节只登记、不直接改范围，范围调整走变更流程，保证签认记录与批准基准一致。
范围确认要拿哪些文件作为依据
范围确认不是一次口头汇报，而是拿一套有版本、有批准状态的依据，与已完成的可交付成果做逐项比对。依据准备得是否齐全，直接决定确认会能否一次开完、签认结果是否站得住。下面这张清单可以作为会前材料准备的对照表。
| 依据名称 | 典型来源 | 在确认中的作用 | 是否必需 |
|---|---|---|---|
| 项目范围说明书 | 项目章程、批准的规划文件 | 界定项目边界、主要可交付成果和验收条件，判断某项成果是否属于本次确认范围 | 必需 |
| 工作分解结构（WBS） | 范围管理计划、规划过程输出 | 提供可交付成果的层级结构，确定本次确认覆盖到哪个工作包 | 必需 |
| WBS词典 | 与WBS配套编制 | 说明各工作包的详细内容、完成标准和责任人，是逐项比对的直接口径 | 必需 |
| 需求文件 | 需求收集与分析过程 | 记录功能与非功能需求，核对可交付成果是否覆盖已承诺的需求条目 | 必需 |
| 需求跟踪矩阵 | 需求管理过程 | 把需求条目与WBS组件、测试或核验活动对应起来，支撑“需求—成果—验证”的追溯 | 必需 |
| 验收标准与质量要求 | 范围说明书、质量计划、合同或技术协议 | 给出“合格”的判定尺度，避免确认会上对标准各说各话 | 必需 |
| 可交付成果完成状态与核验记录 | 执行过程的检查、测试、评审记录 | 证明成果已实际完成并经过内部核验，是确认的前置事实 | 必需 |
| 干系人登记册与确认权限约定 | 干系人管理过程、授权文件或会议决议 | 明确谁有权代表客户或发起人签认，避免确认结果因签字人无权而失效 | 必需 |
这八项依据中，前三项构成范围基准，是确认工作的主依据；需求文件与跟踪矩阵解决“成果是否覆盖了承诺”的问题；验收标准与质量要求解决“做到什么程度算合格”的问题；完成状态与核验记录解决“是否真的做完了”的问题；干系人登记册与权限约定解决“谁来签字算数”的问题。缺少任何一类，确认结论都会留下可被质疑的口子。
准备材料时有两个容易忽略的细节。一是版本，范围说明书和WBS在项目推进中可能经过变更，确认会上引用的必须是当前有效的批准版本，历史版本只能作为对照。二是范围对应关系，确认对象应能通过WBS词典和需求跟踪矩阵回溯到具体条目，无法回溯的成果先查清归属，再决定是否纳入本次确认。
按四步完成一次范围确认
依据齐备之后，确认本身是一组有先后顺序的动作。下面四步把输入、动作、输出和完成标志对应起来，可以按序执行，也可以作为会议议程的骨架。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 核对依据版本与批准状态 | 范围基准、需求文件、验收标准、权限约定 | 逐份检查文件版本号、批准人和批准日期，确认与当前项目状态一致；标记已失效或被变更替代的条目 | 本次确认适用的依据清单（含版本号） | 每份依据都能说明版本与批准来源，无待定文件 |
| 2. 逐项比对可交付成果与验收标准 | 依据清单、核验记录、成果实物或演示环境 | 按WBS工作包逐项对照验收标准，记录“符合”“不符合”“待补充证据”三类结论，并注明引用的依据条目 | 逐项比对表 | 每个纳入确认的成果都有明确比对结论，无空白项 |
| 3. 组织确认会议并记录结论 | 比对表、参会人名单、确认权限约定 | 由项目经理主持，技术或业务负责人说明核验情况，确认权人逐项表态；记录人对结论、保留意见和待办事项现场记录 | 会议记录与结论清单 | 确认权人对每项成果给出接受、有条件接受或拒绝的意见 |
| 4. 签认或提出偏差并转入变更 | 结论清单、签认模板、变更管理入口 | 对接受的成果完成书面签认；对拒绝或有条件接受的成果登记偏差，说明差距与影响，提交变更流程处理 | 签认记录、偏差登记单 | 签认记录有确认权人签字，偏差均有登记编号和后续处理人 |
第二步是整个确认里最耗时的环节，建议把比对表提前发给确认权人，会上只处理有争议或证据不足的条目。第三步要控制会议性质：确认会是核对事实并形成结论，范围调整的讨论应另走变更评审，避免在会上临时扩大或缩减范围，导致签认记录与批准基准脱节。
谁提供依据、谁做确认：角色与交付物分工
范围确认出问题，常见原因不是依据不存在，而是没人对“材料是否齐、签字是否有效”负责。把职责和交付物提前定清楚，确认过程会顺畅很多。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目经理 | 组织依据汇总，核对版本与批准状态，安排确认会议议程，跟踪偏差处理 | 依据清单、会议议程、确认结论汇总、偏差跟踪表 |
| 技术或业务负责人 | 对可交付成果完成内部核验，提供测试、评审或检查结论，解释技术口径 | 核验记录、比对表中的技术结论、遗留问题说明 |
| 客户或发起人（确认权人） | 依据授权对成果作出接受、有条件接受或拒绝的决定，完成书面签认 | 签认记录、确认意见 |
| 记录人 | 现场记录确认过程、结论和保留意见，保证记录与发言一致 | 会议记录、结论清单 |
| 配置管理员 | 归档签认记录与依据版本，维护版本对应关系，保证后续可追溯 | 归档记录、版本台账 |
确认权的归属要在项目早期就写清楚。客户方有多位接口人时，应明确由谁签字、是否需要会签，以及授权范围是否覆盖本次确认的全部成果。项目经理负责组织确认，签字权仍在确认权人手中，这一区分能避免确认记录因主体不适格而返工。
一个范围确认的填写示例
以下为演示情景，用于说明依据如何被引用和比对，不代表任何真实项目。
背景与确认对象：某内部管理系统项目进入第一期交付确认，确认对象为WBS 2.3“用户权限管理模块”下的三个工作包：角色配置、权限分配、操作日志查询。
引用的依据条目：范围说明书V1.2第4.2节“第一期交付范围”；WBS词典条目2.3.1至2.3.3；需求文件REQ-021至REQ-027；需求跟踪矩阵中上述需求与测试用例的对应关系；验收标准“角色配置支持不少于五类预设角色，权限变更实时生效，日志可查询最近90天记录”；测试组出具的核验记录TR-018。
比对结果与偏差处理：角色配置与权限分配两项对照验收标准逐条符合，核验记录完整；操作日志查询仅保留最近30天记录，与验收标准的90天不符。会上将该工作包结论记为“有条件接受”，偏差登记为DEV-006，注明差距、影响范围和补充开发所需时间，转入变更流程评估是否调整验收标准或补充开发。
签认记录内容：确认会日期与参会人；确认对象清单及各自结论；引用依据的版本号；偏差编号及处理去向；确认权人签字与日期；记录人与归档位置。签认记录只覆盖本次确认的成果，未纳入本次确认的工作包在记录中明确标注“不在本次范围”。
确认完成前逐项检查
确认会开完不等于确认完成。下面几项可以逐条判断，任何一项不满足，确认结果都应视为未闭环。
- 依据齐全且为最新批准版本：范围说明书、WBS、WBS词典、需求文件、跟踪矩阵、验收标准均在有效期内，版本号在记录中可查。
- 每项可交付成果有比对结论：纳入确认的每个工作包都有“符合”“不符合”或“待补充证据”的明确结论，没有空白或笼统表述。
- 确认人具备相应权限：签字人身份与授权文件一致，授权范围覆盖本次确认的全部成果。
- 偏差已登记并转入变更：所有“不符合”和“有条件接受”的条目都有偏差编号、影响说明和后续处理人。
- 记录已归档可追溯：签认记录、比对表和依据版本一并归档，能与WBS条目和需求编号相互回溯。
其中“偏差已登记并转入变更”是最容易被跳过的一项。确认会上形成的口头承诺如果没有进入变更流程，后续既无法跟踪，也容易在下次确认时重复出现。把偏差登记作为签认的前置条件，可以保证确认结论与项目实际状态一致。
把依据与签认记录放进同一个协作空间
范围确认的依据分散在文档、测试记录、会议纪要和邮件里时，最常出现的问题是会上找不到最新版本、签认后说不清当时依据的是哪一版。把依据、核验结论和签认记录放在同一处流转，可以让确认过程本身留下完整痕迹。
在ONES中，项目范围说明书、WBS词典和需求条目可以集中存放在项目文档与需求工作项中，需求跟踪矩阵通过需求与工作项的关联关系体现，验收标准随工作项一并维护。技术或业务负责人在完成核验后，将核验结论和测试记录更新到对应工作项，确认状态随工作项流转，项目经理据此汇总出本次确认的成果清单。确认会结束后，签认记录作为文档归档，与依据版本建立对应关系，后续查阅时能同时看到当时引用的范围基准版本、比对结论和签字信息。偏差则登记为独立工作项，进入变更处理流程，与确认记录相互关联。
这样安排的价值在于，范围确认不再依赖个人手里的文件夹，而是形成一条从依据到核验、从签认到偏差处理的连续记录。项目后期复盘或接受审计时，可以直接按工作包回溯整个确认过程。
常见问题
范围确认会上发现某项可交付成果只完成了一部分，应该怎么处理？
把该项成果的结论记为“不符合”或“有条件接受”，在比对表中写明已完成部分、差距内容和影响范围，登记偏差编号并指定后续处理人，转入变更流程评估是补充开发还是调整验收标准。确认记录中保留该条目的原始结论，不要因为双方口头同意就跳过登记，否则下次确认时同一问题会重复出现。
客户方有多位接口人时，确认权应该怎么约定？
在项目早期通过授权文件或会议决议明确由谁签字、是否需要会签，以及授权范围是否覆盖本次确认的全部成果。确认会上由授权代表逐项表态并签认，其他接口人的意见作为输入记录，不替代签认。如果授权范围只覆盖部分成果，其余成果应另行取得对应授权后再确认，避免签认记录因主体不适格而返工。
范围说明书在项目中途发生过变更，确认时以哪个版本为准？
以当前有效的批准版本为准，历史版本只作对照。会前核对每份依据的版本号、批准人和批准日期，把已失效或被变更替代的条目在依据清单中标注出来。签认记录中写明所引用的版本号，后续复盘或审计时才能说明当时的确认是基于哪一版范围基准作出的。
确认会开完、双方口头认可，是否就算范围确认完成？
不算。确认完成需要同时满足几个条件：依据齐全且为最新批准版本，每项成果有明确比对结论，签字人具备相应权限，偏差已登记并转入变更，签认记录与依据版本一并归档可追溯。口头认可缺少书面签认和偏差登记，后续既无法跟踪，也难以在争议时作为依据。
范围确认和范围变更的边界在哪里？
范围确认是拿已完成的可交付成果与批准的范围基准比对，形成接受或拒绝的结论；范围变更是在确认中发现差距后，对范围基准本身作出调整的审批过程。确认环节只登记偏差、说明差距与影响，不直接修改范围说明书或WBS。把这两件事分开，签认记录才能与批准基准保持一致。
