学系统集成项目管理工程师（中项）系列17a_范围管理（上）.png

1. 包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程

2. 项目工作明确划定边界

2.1. 什么是包括在项目之内的

2.2. 什么是不包括在项目之内的

3. 项目其他各方面管理的基础

4. 编制范围管理计划过程

4.1. 对如何定义、确认和控制项目范围的过程进行描述

4.2. 输入

4.2.1. 项目管理计划

4.2.2. 项目章程

4.2.3. 组织过程资产

4.2.4. 事业环境因素

4.3. 工具与技术

4.3.1. 会议

4.3.2. 专家判断

4.4. 输出

4.4.1. 范围管理计划

4.4.1.1. 制定项目管理计划过程和其他范围管理过程的主要依据

4.4.2. 需求管理计划

4.4.2.1. 需求管理计划是编制范围管理计划的输出

4.4.2.1.1. 【21下选38】

4.4.2.2. 用于规划,跟踪和报告各种需求活动

4.4.2.2.1. 【20下选39】

4.4.2.3. 如何规划、跟踪和报告各种需求活动

4.4.2.4. 配置管理活动

4.4.2.5. 需求优先级排序过程

4.4.2.6. 产品测量指标及使用这些指标的理由

4.4.2.7. 用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构

4.4.2.8. 收集需求过程

4.4.2.9. 【22下选38】

5. 收集需求

5.1. 为实现项目目标而确定、记录并管理干系人的需要和需求的过程

5.2. 为定义和管理项目范围（包括产品范围）奠定基础

5.3. 输入

5.3.1. 范围管理计划

5.3.2. 需求管理计划

5.3.3. 干系人管理计划

5.3.4. 项目章程

5.3.5. 干系人登记册

5.4. 工具与技术

5.4.1. 访谈

5.4.1.1. 与干系人直接交谈来获取信息的正式或非正式的方法

5.4.1.2. 可用于获取机密信息

5.4.2. 焦点小组

5.4.2.1. 比“一对一”的访谈更热烈

5.4.3. 引导式研讨会

5.4.3.1. 研讨会是快速定义跨职能需求和协调干系人差异的重要技术

5.4.3.2. 能够比单项会议更早发现问题，更快解决问题

5.4.3.3. “联合应用设计/开发（JAD）”的引导式研讨会

5.4.3.3.1. 软件开发行业

5.4.3.4. “质量功能展开（QFD）”这种引导式讨论会

5.4.3.4.1. 制造行业

5.4.3.5. 用户故事是对所需功能的简短文字描述，经常产生于需求研讨会

5.4.3.5.1. 在敏捷方法中广泛使用

5.4.4. 群体创新技术

5.4.4.1. 可以组织一些群体活动来识别项目和产品需求

5.4.4.2. 头脑风暴法

5.4.4.3. 名义小组技术

5.4.4.4. 概念/思维导图

5.4.4.5. 亲和图

5.4.4.6. 多标准决策分析

5.4.5. 群体决策技术

5.4.5.1. 为达成某种期望结果，而对多个未来行动方案进行评估的过程

5.4.5.2. 一致同意

5.4.5.3. 大多数原则

5.4.5.3.1. 群体中超过50%人员的支持

5.4.5.4. 相对多数原则

5.4.5.5. 独裁

5.4.6. 问卷调查

5.4.7. 观察

5.4.7.1. 直接察看个人在各自的环境中如何执行工作（或任务）和实施流程

5.4.7.2. 工作跟踪

5.4.8. 原型法

5.4.9. 标杆对照

5.4.9.1. 将实际或计划的做法（如流程和操作过程）与其他可比组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据

5.4.9.1.1. 【21上选39】

5.4.10. 系统交互图

5.4.11. 文件分析

5.4.11.1. 通过分析现有文档，识别与需求相关的信息，来挖掘需求

5.5. 输出

5.5.1. 需求文件

5.5.1.1. 描述各种单一需求将如何满足与项目相关的业务需求

5.5.1.2. 只有明确的、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准

5.5.1.3. 业务需求

5.5.1.4. 干系人需求

5.5.1.5. 解决方案需求

5.5.1.6. 项目需求

5.5.1.7. 过渡需求

5.5.1.8. 与需求相关的假设条件、依赖关系和制约因素

5.5.2. 需求跟踪矩阵

5.5.2.1. 把产品需求从其来源连接到能满足需求的可交付成果的一种表格

5.5.2.2. 在整个项目生命周期中跟踪需求的一种方法

6. 定义范围

6.1. 详细描述产品范围和项目范围，编制项目范围说明书

6.2. 制定项目和产品详细描述的过程

6.3. 从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或输出的详细描述

6.4. 详细定义项目的范围边界

6.5. 输入

6.5.1. 范围管理计划

6.5.2. 项目章程

6.5.3. 需求文件

6.5.4. 组织过程资产

6.5.5. 【22上选38】

6.6. 工具与技术

6.6.1. 产品分析

6.6.1.1. 弄清产品范围，并把对产品的要求转化成项目的要求

6.6.2. 专家判断

6.6.3. 备选方案生成

6.6.3.1. 一种用来制定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法

6.6.4. 引导式研讨会

6.6.4.1. 有助于就项目目标和项目限制达成跨职能的共识

6.7. 输出

6.7.1. 项目范围说明书

6.7.1.1. 【22下选39】

6.7.1.2. 对项目范围、主要可交付成果、假设条件和制约因素的描述

6.7.1.3. 记录了整个范围，包括项目和产品范围

6.7.1.4. 可明确指出哪些工作不属于本项目范围

6.7.1.5. 项目的范围边界一定是闭合的

6.7.1.6. 项目目标

6.7.1.7. 产品范围描述

6.7.1.8. 项目需求

6.7.1.9. 项目边界

6.7.1.9.1. 项目边界严格地定义了项目内包括什么和不包括什么，以防有的项目干系人假定某些产品或服务是项目中的一部分

6.7.1.9.1.1. 【21下选39】

6.7.1.10. 项目的可交付成果

6.7.1.11. 项目的制约因素

6.7.1.11.1. 【19下选40】

6.7.1.12. 项目的除外责任

6.7.1.13. 假设条件

6.7.1.13.1. 不需验证即可视为正确、真实或确定的因素就是假设

6.7.1.14. 【22上选39】

6.7.1.15. 干系人清单不会在范围说明书

6.7.1.15.1. 【20下选40】

6.7.1.15.1.1. 【19上选43】

6.7.2. 项目文件更新

6.7.2.1. 干系人登记册、需求文件、需求跟踪矩阵