5.1 范围管理概述
项目范围管理需要做以下三个方面的工作：
（1）明确项目边界，即明确哪些工作是包括在项目范围之内的，哪些工作是不包括在项目范围之内的。
（2）对项目执行工作进行监控，确保所有该做的工作都做了，而且没有多做。对不包括在项目范围内的额外工作说“不”杜绝做额外工作。
（3）防止项目范围发生蔓延。范围蔓延是指未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大。
5.1.1 产品范围与项目范围
1、产品范围是指产品或者服务所应该包含的功能，项目范围是指为了能够交付产品，项目所必须做的工作。
2、产品范围是项目范围的基础，产品范围的定义是产品要求的描述；而项目范围的定义是产生项目管理计划的基础。
3、项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。
4、判断项目范围是否完成，要以范围基准来衡量。而产品范围是否完成，则根据产品是否满足了产品描述来判断。
5、产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目的范围。
5.1.3 范围管理的过程
1、项目范围管理主要是通过规划范围管理、收集需求、定义范围、创建WBS、确认范围和控制范围六个过程来实现的。
2、范围管理各过程
3、范围管理各过程输入、输出、工具和技术
5.2 规划范围管理
1、规划范围管理是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，其主要作用是在整个项目中对如何管理范围提供指南和方向。
2、规划范围管理过程的输入有项目管理计划、项目章程、事业环境因素和组织过程资产，使用的工具与技术有专家判断和会议，输出有范围管理计划和需求管理计划。
5.2.1 范围管理计划
1、范围管理计划是制订项目管理计划过程和其他范围管理过程的主要输入，包含如下内容
（1）如何制订项目范围说明书。
（2）如何根据范围说明书创建WBS。
（3）如何维护和批准WBS。
（4）如何确认和正式验收已完成的项目可交付成果。
（5）如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。
2、项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的。
5.2.2 需求管理计划
1、需求管理贯穿于整个过程，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
2、需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。主要包括以下内容。
（1）如何规划、跟踪和汇报各种需求活动。
（2）需求管理需要使用的资源。
（3）培训计划
（4）项目干系人参与需求管理的策略
（5）判断项目范围与需求不一致的准则和纠正规程
（6）需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求
（7）配置管理活动
5.3 收集需求
5.3.1 需求的分类
（1）业务需求：整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
（2）干系人需求：是指干系人或干系人群体的需要。
（3）过渡需求：从当前状态过渡到将来状态所需的临时能力，例如，数据转换和培训需求。
（4）质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求。
5.3.2 收集需求的工具与技术
1、收集需求的工具与技术主要有访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析等。
2.焦点小組：将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比一对一的访谈更加热烈。焦点小组是一种群体访谈而非一对一访谈，可以有以有6~10个被访谈者参加。针对访谈者提出的问题，被访谈者之间开展互动式讨论，以求得到更有有价值的意见。
3、引导式研讨会：通过邀请主要的跨职能干系人一起参加会议。引导式研讨会对产品需求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。该技术的另一个好处是，能够比单项会议更快地发现和解决问题。
4、群体创新技木是指可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。
（1）头脑风暴：各抒己见
（2）名义小组技术：通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法
（3）德尔菲技术：可以防止个人的观点被不正确的放大
（4）概念/思维导图：是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。
（5）亲和图又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。亲和图的核心是头脑风暴法，是根据结果去找原因。
（6）多标准决策分析是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
5、群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。
（1）一致同意。所有人都同意某个行动方案。
（2）大多数原则。获得群体中50%以上的人的支持，就能做出决策。参与决策的人数定为奇数，防止因平局而无法达成决策。
（3）相对多数原则。根据群体中相对多数者的意见做出决定，即便未能获得一部分人的支持。通常在候选项超过两个时使用该原则，例如，某个软件构件的功能有3种实现方案（标记为A、B、C）在群体决策时，同意A方案的人有40%，同意B方案的人有35%，同意C方案的人有25%，则最终确定采用A方案。
（4）独裁。由某一个人（例如，项目经理）为群体做出决策。
6、原型法是一种根据干系人初步需求，利用产品开发工具，快速地建立一个产品模型展示给干系人，在此基础上与干系人交流，最终实现干系人需求的产品快速幵发的方法。
7、标杆对照将实际或计划的做法与其他类似组织的做法（例如，流程、操作过程等）进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的“类似组织”可以是内部组织，也可以是外部组织。
8、系统交互图是对产品范围的可视化描述，显示系统（过程、设备、信息系统等）与参与者（用户、独立于本系统之外的其他系统）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
9、文件分析就是通过分析现有文档，识别与需求相关的信息来挖掘需求。可供分析的文档很多，包括商业计划、营销文档、协议、投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等。
5.3.3 需求文件
1、收集需求过程的主要输出有需求文件和需求跟踪矩阵。需求文件描述各种单一的需求将如何满足与项目相关的业务需求。
2、需求文件的内容包括（但不限于）以下几个方面：
（1）业务需求
（2）干系人需求
（3）解决方案需求
（4）项目需求
（5）过渡需求。
（6）与需求有关的假设条件、依赖关系和制约因素。
5.3.4 需求跟踪
1、需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。
2、可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件，以及帮助文件等。
3、每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品（成果）中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。具体来说，需求跟踪涉及五种类型。如图：
4、箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程。
5、从用户原始需求可向前追溯到需求文件，这样就能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求文件中包括所有用户需求。同样，可以从需求文件回溯到相应的用户原始需求，确认每个需求的出处。
6、由于在项目实施过程中，产品需求转变为设计和测试等实现元素，所以通过定义单个需求和特定的产品元素之间的联系链，可以从需求文件追溯到产品元素。这种联系链使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因。如果不能将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。
7、第五类联系链是需求文件之间的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。
8、表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。
9、应在需求跟踪矩阵中记录每个需求的相关属性这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）和状态日期。
5.4 定义范围
定义范围是制定项目和产品详细描述的过程，其主要作用是明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界。
5.4.1 定义范围的工具和技术
1、定义范围过程的主要工具与技术有专家判断、产品分析、备选方案生成和引导式研讨会。
2、产品分析是一种有效的工具。通常，针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述。
3、备选方案生成是一种用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。
5.4.2 项目范围说明书
1、作为定义范围过程的主要成果，项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。项目范围说明书记录了整个范围，包括项目范围和产品范围，详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。
2、项目范围说明书包括如下内容。
（1）产品范围描述。
（2）验收标准。定义可交付成果通过验收前必须满足的一系列条件，以及验收的过程。
（3）可交付成果。
（4）项目的除外责任。通常需要识别出什么是被排除在项目之外的。明确说明哪些内容不属于项目范围，有助于管理干系人的期望。
（5）制约因素。列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素。
（6）假设条件。
3、项目范围说明书的主要作用如下。
（1）确定范围
（2）沟通基础。
（3）规划和控制依据。
（4）变更基础。
（5）规划基础。
5.5 创建工作分解结构（WBS）
创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。
5.5.1 WBS的层次
1、里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里程碑是基线。
2、工作包是位于WBS每条分支最底层的可交付成果或项目工作组成部分，工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。工作包的大小需要遵循8/80原则。
3、控制账户是一种管理控制点。是WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。如果是后一种情况，一个控制账户中就包括若干个工作包，但一个工作包仅属于一个控制账户。项目管理团队在控制账户上考核项目的执行情况，即在控制账户的相应要素下，将项目执行情况与计划情况进行比较，以便评价执行情况好坏，并发现与纠正偏差。
4、规划包是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分。是在控制账户之下、工作包之上的WBS要素是暂时用来做计划的。随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。
5、WBS词典，在制作WBS的过程中，要给WBS的每个部分赋予一个账户编码标志符，它们是成本、进度和资源使用信息汇总的层次结构。需要生成一些配套的文件，这些文件需要和WBS配套使用，称为WBS词典。WBS词典也称为WBS词汇表，它是描述WBS各组成部分的文件。
5.5.2 分解
1、创建WBS过程的工具与技术主要有分解和专家判断，要将整个项目工作分解为工作包，通常需要开展以下活动：
（1）识别和分析可交付成果及相关工作。
（2）确定WBS的结构和编排方法。
（3）自上而下逐层细化分解。
（4）为WBS组件制定和分配标识编码。
（5）核实可交付成果分解的程度是恰当的。
2、分解的原则
（1）功能或者技术原则。在创建WBS时，需要考虑将不同人员的工作分开。
（2）组织结构。对于职能型的项目组织而言，WBS也要适应项目的组织结构形式
（3）系统或者子系统。总的系统划分为几个主要的子系统，然后对每个子系统再进行分解
3、在进行WBS分解时，可以有如下三种方式
（1）将项目生命周期的各阶段作为分解的第二层
（2）主要可交付成果作为分解的第二层
（3）子项目作为分解的第二层
4、WBS不是某个项目团队成员的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。
5、较常用的WBS表示形式主要有分级的树型结构（组织结构图式）和表格形式（列表式）。
6、树型结构图的WBS层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难表示出项目的全貌。
7、表格形式的直观性比较差，但能够反映出项目所有的工作要素。
8、值得注意的是，虽然有些参考文献也使用鱼骨图形式的WBS，但这种形式并不常用。
9、在分解的过程中，应该注意以下8个方面。
（1）WBS必须是面向可交付成果的。项目的目标是提供产品或服务，仅仅是一连串特别的活动。
（2）WBS必须符合项目的范围。WBS必须包括，也仅包括为了完成项目的可交付成果的活动
（3）WBS的底层应该支持计划和控制。WBS是项目管理计划项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。
（4）WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与
（5）WBS的指导。作为指导而不是原则，WBS应控制在4~6层。当然，大项目可以超过6层。
（6）WBS应包括项目管理工作，也要包括分包出去的工作。
（7）WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
（8）WBS并非是一成不变的。在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。
5.5.3 WBS的作用
1、当一个项目的WBS分解完成后，项目干系人对完成的WBS应该给予确认，并对此达成共识。WBS的目的和用途主要体现在以下8个方面。
（1）明确和准确说明项目范围，项目团队成员能够清楚地理解任务的性质和需要努力的方向。
（2）清楚地定义项目的边界。
（3）为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需要的技术和人力资源。
（4）针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。
（5）为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准。
（6）将项目工作和项目的财务账目联系起来。
（7）确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目。WBS可以使用图形化的方式来查看工作内容，任何人都能够清楚地辨别项目的阶段、工作单元，并根据实际情况进行调节和控制。
（8）有助于防止需求蔓延。
5.6 确认范围
确认范围是正式验收项目已完成的可交付成果的过程。确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。
5.6.1 确认范围概述
1、确认范围的主要工具与技术是检查和群体决策技术。检査也称为审查、评审、审计、走查、巡检、测试等。
2、确认范围应该贯穿项目的始终，一般步骤如下。
（1）确定需要进行范围确认的时间。
（2）识别范围确认需要哪些投入。
（3）确定范围正式被接受的标准和要素。
（4）确定范围确认会议的组织步骤。
（5）组织范围确认会议。
3、项目干系人进行范围确认时，一般需要检查以下6个方面的问题。
（1）可交付成果是否是确定的、可确认的。
（2）每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件。
（3）是否有明确的质量标准。
（4）审核和承诺是否有清晰的表达。
（5）项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误。
（6）项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。
5.6.2 干系人关注点
1、管理层所关注的项目范围，是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。
2、客户主要关心的是产品的范围，关心项目的可交付成果是否足够完成产品或服务。
3、项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
4、项目团队成员主要关心项目范围中自己参与的元素，通过定义范围中的时间，检査自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作又有冲突的地方。
5.6.3 几个术语的比较
1、确认范围与核实产品
核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完整；确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。
2、确认范围与质量控制
确认范围与质量控制的不同之处在于：
（1）确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。
（2）质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段末进行。
（3）质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。
3、确认范围与项目收尾
确认范围与项目收尾的不同之处在于：
（1）虽然确认范围与项目收尾工作都在阶段末进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。
（2）确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。
5.7 控制范围
1、控制范围是监督项目和产品的范围状态、管理范围基准变更的过程
2、范围变更的原因
（1）政府政策的问题。
（2）项目范围的计划编制不周密详细，有一定的错误或遗漏。
（3）市场上出现了或是设计人员提出了新技术、新手段或新方案。
（4）项目执行组织本身发生变化。
（5）客户对项目、项目产品或服务的要求发生变化。
3、范围变更控制的主要工作如下
（1）影响导致范围变更的因素，并尽量使这些因素向有利的方面发展。
（2）判断范围变更是否已经发生。
（3）范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。
补充
1、“需求蔓延”、“范围蔓延”需要理解，在做案例的时候可以用。就是不受控制了WBS分解的越细，那么对该工作的计划、管理和控制的能力就越强，然而大量的分解工作会导致生产效率降低、资源浪费、工作效率低下。
2、需求工程：与需求相关的活动都叫做需求工程，分为2类：一类是需求开发、一类是需求管理。
3、需求开发主要包含：需求获取（捕获用户的需求）、需求分析（将需求信息进行分析、抽象描述、建立概念模型）、需求定义（编制《需求规格说明书》）、需求验证（对需求文档进行评审，确认需求。）在需求开发中，完成需求验证过程后将确定需求基线。
4、需求管理包含：制定需求管理计划（如何进行需求管理的）、求得对需求的理解（确保项目干系人对需求正确理解）、求得对需求的承诺（实现需求所需的活动人员之间达成一致和建立承诺）、管理需求变更（通过变更流程对需求进行管理，防止需求蔓延）、维护对需求的双向跟踪性（需求文档和产品之间的双向跟踪）、识别项目工作与需求之间的不一致性（识别项目计划和工作产品与需求之间的不一致之处）。
真题
1、以下关于需求跟踪的叙述中，（ ）是不正确的。
A、逆向需求跟踪检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处
B、需求跟踪矩阵可以把每个需求与业务目标或项目项目目标联系起来
C、需求跟踪矩阵为管理产品范围变更提供框架
D、如果按照“需求开发-系统设计-编码-测试”这样的顺序开发产品，由于每一步的输出就是下一步的输入，所以不必担心设计、编程、测试会与需求不一致，可以省略需求跟踪
2、（ ）工作用来对项目进行定义，该工作用来明确“项目需要做什么”。
A、制定项目范围说明书 B、制定项目管理计划
C、制定项目章程 D、项目管理信息系统
3、在需求跟踪过程中，检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处的方法属于（ ）。
A、逆向跟踪 B、正向跟踪
C、双向跟踪 D、系统跟踪
4、测试人员在测试某一功能时，发现该功能在需求说明书里没有，他接下来正确的做法是（ ）。
A、在需求说明书中补充该功能 B、汇报项目经理，让其查明原因
C、找开发人员沟通，让其删除该功能 D、找用户沟通，该功能是否需要
5、以下关于需求跟踪的叙述中，不正确的是（ ）
A、需求跟踪是为了确认需求，并保证需求被实现
B、需求跟踪可以改善产品质量
C、需求跟踪可以降低维护成本
D、需求跟踪能力矩阵用于表示需求和别的系统元素之间的联系链
6、WBS最底层的工作单元被称为工作包，一下关于工作包的叙述中，正确的是（ ）
A、可依据工作包来确定进度安排、成本估算等工作
B、工作包可以非常具体，也可以很粗略，视项目情况而定
C、如果项目规模很大，也可以将其分解为子项目，这时子项目可以认为是一个工作包
D、工作包的规模应该较小，可以在40小时之内完成
7、在进行项目需求管理时，某需求的状态描述是“该需求已被分析，估计了其对项目余下部分的影响，已用一个明确的产品版本号或创建编号分配到相关的基线中，软件开发团队已同意实现该需求”，则这个需求状态值是（ ）
A、已建议 B、已验证 C、已实现 D、已批准
8、某企业软件开发人员的下列做法中，不正确的是（ ）
A、计划根据同行评审、阶段评审的结果建立需求、设计、产品三条基线
B、在需求分析规格说明书通过同行评审后建立需求基线
C、建立需求基线没有包括用户需求说明书
D、因用户需求有变更，故依据变更控制流程修改了需求基线
9、项目范围基线包括（ ）
A、批准的项目范围说明书、WBS及WBS字典
B、项目初步范围说明书、WBS及WBS字典
C、批准的项目范围说明书，WBS字典
D、项目详细范围说明书、WBS进度管理
1-5 DAABA 6-9 ADCA