范围管理计划描述将如何定义、制订、监督、控制和确认项目范围。

• 定义怎样变化怎样变化、变化频率如何、变化了多少等项目范围预期的稳定性进行评估。
• 对变化范围怎样确定，变化应归为哪一类等问题的清楚描述；---范围潜变；蔓延；镀金；

需求是软件项目成功的核心所在，它为其他许多技术和管理活动奠定了基础。需求管理贯穿于整个过程。

• 基本任务就是明确需求，达成共识，建立需求基线。
• 建立需求跟踪能力联系链,确保所有用户需求都被正确地实现、核实和确认。
• 变更时，控制其影响范围，始终保持产品与需求的一致性。

1.文件分析，标杆对照---分析初步需求

2. 访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、

3. 问卷调查、观察

4. 原型法、系统交互图--进一步开发和确认需求

引导式研讨会    集中主要干系人，集中讨论定义产品需求，强调跨职能和协调客户、设计技术和开发等干系人组织一系列结构性的专题研讨会，集中确定需求，效率高，客户参与度高。

群体创新技术    组织一些群体活动来识别项目和产品需求
群体决策技术    为达成某种期望结果，对多个未来行动方案进行评估

原型法    制造模型，征求反馈，支持渐进明细
标杆对照    用实际和计划与其他组织的进行比较

系统交互图法：软件需求分析中的DFD数据流图、用例图都可以看作是系统交互图。

群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。

①头脑风暴：各抒己见，庭外判决，追求数量，取长补短；

②名义小组技术：通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法。

将参加头脑风暴的人员按名义分组，分组讨论，促进创意。

③德尔菲技术：可以防止个人的观点被不正确的放大。

④概念/思维导图：是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。

⑤亲和图又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。亲和图的核心是头脑风暴法，是根据结果去找原因。

⑥多标准决策分析是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。

可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件，以及帮助文件等。

五类需求可跟踪：

1. 用户需求--需求文件双向跟踪；

2. 需求文件---设计、产品，测试文档双向跟踪

3. 需求文件格需求之间的逻辑关系可跟踪。

需要跟踪的内容包括以下几个方面。

• 业务需求、机会、目的和目标。
• 项目目标。
• 项目范围(WBS可交付成果)。.
• 产品设计。
• 产品开发。
• 测试策略和测试场景。
• 高层级需求到详细需求。

专家判断、产品分析、备选方案生成和引导式研讨会。

产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。

关键的还是产品分析后的范围界定，例如是否包含基础开发平台，只提供前台还是前后台都提供。

价值工程( Value Engineering)与价值分析( Value Analysis)两种活动都是对商品的
价值、功能与成本进-步做思考与探索，以小组活动方式集思广益，朝各方向寻求最佳方案，再运用体系分工的方式达成价值提升或降低成本的目标。两者都是指对项目的范围和成本进行分析，以便在保持项目范围不变的前提下，降低项目成本，追求功能与成本之间的更高的性价比。

• 价值工程是在产品开发设计阶段进行的价值与成本革新活动，因为仍在工程设计阶段，故称为价值工程。
• 而一旦开始量产后，往往为了成本或利润压力，如果不进行详尽的价值分析，就难以发掘可以降低成本或提高价值的改善点。此阶段以后持续的分析是降低成本的主要方法，就称为价值分析。

因此，要注意价值工程与价值分析的细微差别，

①产品范围描述
②验收标准
③可交付成果
④项目的除外责任
⑤制约因素
⑥假设条件

2. 工作包，WBS最底层交付成功或者项目工作。

 1）工作要具体，有明确的目标和责任，方便指派。

 2）工作包的颗粒度要合适，不能太大，也不能太小，太大会导致估算控制偏差过大；太小浪费管理效率资源； 8/80原则，即工作包不小于8人时，不大于80人时。1-10人天。

3. 控制账号，项目范围，进度，成本等绩效控制的基础单元。项目管理团队在控制账户上考核项目的执行情况，将项目执行情况与计划情况进行比较，发现问题与纠正偏差。

控制账尸是WBS某个层次上的要系，既可以是工作包，也可时县比工作包更高层次上的一个要素。一个工作包仅属于一个控制账户。

4. 规划包( Planning Package)是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分。也就是说，规划包是在控制账户之下、工 作包之上的WBS要素。

项目管理团队虽然已经知道它是一-个什么样的成果，但是尚不清楚究竟要做哪些具体的活动才能将该成果开发出来。

由于当前无法分解到编制项目管理计划所需要的详细程度，规划包是暂时用来做计划的。随着情况的逐渐清晰，规划包最终将被分解成T作包以及相应的具体活动。

WBS词典：

WBS词典也称为WBS词汇表，它是描述WBS各组成部分的文件。对于WBS的每一组成部分，WBS词典可能包括账户编码标识、工作描述、假设条件和制约因素负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。

7、分解是一种将项目可交付成果和项目工作分解成较小的、更易于管理的组件的技术。
8、要将整个项目工作分解为工作包，需要开展以下活动：
①识别和分析可交付成果及相关工作
②确定WBS的结构和编排方法
③自上而下逐层细化分解。
④为WBS组件制定和分配标识编码。
⑤核实可交付成果分解的程度是恰当的

9、创建WBS时对工作的划分原则包括：
①功能或者技术原则。在创建WBS时，需要考虑工作分派。
②组织结构
③系统或者子系统。

10、WBS分解的方法：
①项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层。（如按项目周期的需求、设计、开发、测试、实施等阶段做为第二层；把每个阶段产出的可交付成果作为第三层，如：需求分析结果、调研结果等）
②主要可交付成果作为分解的第二层
③整合可能由项目团队以外的组织来实施的各种组件（例如，外包工作），然后作为外包工作的一部分，卖方需编制相应的合同WBS。
例子看这里：https://m.sohu.com/a/150900112_208218

14、WBS分解注意8个方面：
①WBS必须是面向可交付成果的。
②WBS必须符合项目的范围。
③WBS的底层应该支持计划和控制。
④WBS中的元素必须有且只由一个人负责，尽管实际上可能需要多个人参与。
⑤WBS的指导（不是原则），WBS应控制在4∽6层。
⑥WBS应包括项目管理工作，也要包括分包出去的工作。
⑦WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
⑧WBS并非是一成不变的。需要不断维护和更新。
补充：
（1）在层次上保持项目的完整性，避免遗漏必要的组成部分。
（2）一个工作单元只能从属于某个上层单元，避免交叉从属。
（3）相同层次的工作单元应用相同性质。
（4）工作单元应能分开不同的责任者和不同的工作内容。
（5）便于项目管理计划和项目控制的需要。
（6）最底层工作应该具有可比性，是可管理的，可定量检查的。
（7）应包括项目管理工作，包括分包出去的工作。

当一个项目的WBS分解完成后，项目干系人应该给予确认，并对此达成共识，然后才能据此进行时间估算和成本估算。

WBS的目的和用途主要体现在以下8个方面
(1)明确项目范围，团队成员能够清楚地理解任务的性质和需要努力的方向。
(2)清楚地定义项目的边界，有了一致认可的项目要做的和不要做的标准。
(3)为各独立单元分派人员，定义职责。
(4)针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。
(5)为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准。
(6)将项目工作和项目的财务账目联系起来。
(7)确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目。
(8)有助于防止需求蔓延。

当项目用户或者其他项目干系人试图为项目增加功能时，在WBS增加相应的工作的同时，也就能够很容易地让他们理解，相关成本和进度也必须做相应的改变。

确认范围的主要工具与技术是检查和群体决策技术。检查也称为审查、评审、审计、走查、巡检、测试等，是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。

例如，验收测试就是一种典型的确认范围的技术。

(1)可交付成果是否是确定的、可确认的。

(2)每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，
例如，客户的书面认可等。

(3)是否有明确的质量标准，也就是说，可交付成果的交付不但要有明确的标准标志，而且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确的联系。

---------怎么证明质量监测结果

(4)审核和承诺是否有清晰的表达。项目发起人必须正式同意项目的边界，项目完成的产品或者服务，以及项目相关的可交付成果。项目团队必须清楚地了解可交付成果是什么。所有的这些表达必须清晰，并取得一致的 同意。

(5)项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误。
(6)项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。

1.确认范围与核实产品
核实产品是针对产品是否完成，在项目(或阶段)结束时由发起人或客户来验证，强调产品是否完整;

确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。

2. 确认范围与质量控制

• 确认范围主要强调可交付成果获得客户或发起人的接受;质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求(质量标准)。
• 质量控制一般在确认范围前进行，也可同时进行;确认范围一般在阶段末尾进行，而质量控制并不一定在阶段未进行。
• 由执行组织的相应质量部门]实施;确认范围则是由外部干系人(客户或发起人)对项目可交付成果进行检查验收。
• 从检查的详细程度来说，核实产品、确认范围和质量控制是递进的、越来越细的检查过程。

3.确认范围与项目收尾
。虽然确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目(或阶段)所要做的流程性工作。
。确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。