确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用是，使验收过程具有客观性；同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。

确认范围是由利益相关者对已界定的项目范围进行的正式确认。这一确认通常由客户检查完成，然后由关键利益相关者来收尾。为获得项目范围的正式验证，项目团队必须建立有关项目产品和程序的文档存储，以评价项目团队在产出产品和遵守程序上是否正确及令人满意。

在范围管理中，范围定义、范围确认和范围控制又是最核心的三项活动，缺一不可。范围定义是基础的活动，不进行范围定义就不能进行范围确认和范围控制。范围确认则是基线化已定义的范围，是范围控制的依据。下面是一个没有进行范围确认而失败的项目例子。

A公司（CSAI）刚刚和M公司签订了一份新的合同，合同的主要内容是处理公司以前为M公司开发的信息系统的升级工作。升级后的系统可以满足M公司新的业务流程和范围。由于是一个现有系统的升级，项目经理张工特意请来了原系统的需求调研人员李工担任该项目的需求调研负责人。在李工的帮助下，很快地完成了需求开发的工作并进入设计与编码。由于M公司的业务非常繁忙，M公司的业务代表没有足够的时间投入到项目中，确认需求的工作一拖再拖。张工认为，双方已经建立了密切的合作关系，李工也参加了原系统的需求开发，对业务的系统比较熟悉，因此定义的需求是清晰的。故张工并没有催促业务代表在需求说明书中签字。进入编码阶段后，李工因故移民加拿大，需要离开项目组。张工考虑到系统需求已经定义，项目已经进入编码期，李工的离职虽然会对项目造成一定的影响，但影响较小，因此很快办理好了李工的离职手续。在系统交付的时候，M公司的业务代表认为已经提出的需求很多没有实现，实现的需求也有很多不能满足业务的要求，必须全部实现这些需求后才能验收。此时李工已经不在项目组，没有人能够清晰地解释需求说明书。最终系统需求发生重大变更，项目延期超过50%，M的业务代表也因为系统的延期表示了强烈的不满。(www.daowen.com)

这是一个失败的软件项目，与很多失败的软件项目一样，在系统需求上栽了跟头。开发与定义软件系统的需求在整个软件开发过程中是最重要的一环，这是每个从事信息系统建设的项目经理都清楚的事情，但往往又因为一时的疏忽而造成需求的重大缺陷，最终导致项目的失败。从项目管理的角度来说，项目范围直接决定了工作量和工作目标，所以项目经理必须管理项目的范围。在软件系统的开发中，系统需求就是项目的范围。从软件诞生至今的几十年中，人们探索出了很多获取系统需求的方法，但是熟悉软件开发的人都知道，无论哪种方法都不可能定义出完美无误的需求，需求中的缺陷必然存在，无法完全避免。因此需求确认或者说是范围确认就显得更为重要。有人可能会说，很难说服客户在需求上签字，很难让客户为需求的缺陷负责。以现在软件行业的情况，这种说法是不无道理的。让客户在需求上签字很困难，但并不等于就不需要进行范围确认，而且范围确认的方法也不仅仅只有需求签字这一种方法。召集客户的业务代表对需求进行评审，详细记录最原始的调研材料，让客户确认调研报告，采用迭代开发逐步确认系统需求，都是可以采用的方法。这些方法虽然没有直接确认需求分析报告，但至少可以让现有需求在项目组和客户之间达成一致，提供范围控制的基准，一样可以达到范围确认的目的。再回到这个案例，项目经理张工乐观认为李工开发的需求没有什么问题，也误认为双方已经有良好的合作，再紧逼要求客户代表签字显得不近人情，于是就抱着侥幸信息进入了开发。然而最终的结果是，项目延期严重，业务代表反而更不满意，张工也要承担项目延期造成的成本增加的责任。

对于软件项目而言，确认范围可以理解为：根据项目管理计划、需求文件等定义规则的文档，由项目团队和各个干系人对定义的功能模块进行检查确认的过程。对于未通过检查的部分，分析原因，提出变更请求。