需求跟踪(需求跟踪工具)

啥都别说，也没人看，只好坚持了~ ~ ~

5.2 规划范围管理

规划范围管理是准备范围管理计划的过程，以书面形式描述如何定义、确认和控制项目范围，并就如何在整个项目中管理范围提供指导和指示。范围管理计划需要项目管理团队的全面参与。

5.2.1 范围管理计划

范围管理计划可以是一个项目，也可以是项目管理计划中的一个单独项目。根据项目不同，可以细化或概括，正式或非正式。

范围管理计划是制定项目管理计划和其他范围管理过程的主要输入，有必要规定用于以下工作的管理过程。

如何制订项目范围说明书。如何根绝范围说明书创建WBS。如何维护和批准WBS。如何确认和正式验收已完成的项目可交付成果。如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。5.2.2 需求管理计划

需求管理贯穿整个过程，其最基本的任务是定义需求，使项目团队和用户达成共识，即建立需求基线。此外，还需要建立需求跟踪能力的链接链，确保所有用户需求都得到正确应用，在需求发生变化时，能够完全控制其影响范围，始终保持产品与需求的一致性。

需求管理计划描述了在整个项目生命周期中如何分析、记录和管理需求。

主要包括以下内容。

（1）如何规划、跟踪和汇报各种需求活动。（2）需求管理需要使用的资源。（3）培训计划。（4）项目干系人参与需求管理的策略。（5）判断项目范围与需求不一致的准则和纠正规程。（6）需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求。（7）配置管理活动。5.3 收集需求5.3.1 需求的分类（1）业务需求：整个组织的高层级需求，例如：解决业务问题或者抓住业务机会，以及实施项目的原因。（2）干系人需求：是指干系人活干系人群体的需要。（3）解决方案需求（4）过渡需求：从当前状态过渡到将来状态所需的临时能力（5）项目需求：项目需要满足的行动、过程或其他条件。（6）质量要求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件和标准。QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求。5.3.2 收集需求的工具与技术

工具

形容

采访

通过与利益相关者直接对话获得信息的正式或非正式方式。

焦点小组会议

焦点小组会议旨在将预选的利益相关方和主题专家召集在一起，了解他们对提议的产品、服务或结果的期望和态度。

引导式研讨会

通过邀请主要的跨职能利益相关者参加会议，引导式研讨会将重点讨论和定义产品需求。Seminar是快速定义跨职能需求和协调反洗者差异的重要技术。

群体创新技术

1)头脑风暴法2)名义群体技术(头脑风暴的深度应用)3)德尔菲技术4)概念/思维导图5)亲和图6)多准则决策分析。

群体决策技术

1)一致同意2)多数原则3)相对多数原则4)独裁

问卷调查

设计一系列书面问题，从众多受访者中快速收集信息。它适用于多样化的受众，需要快速完成调查的被调查者地理位置分散，适合于统计分析。

观察

也称为“工作跟踪”

样机研究

原型法是指在实际制造产品之前制作产品的使用模型，然后征求需求反馈。原型是有形的对象，它让涉众有机会体验最终产品的模型，而不仅仅是讨论抽象的需求陈述。

基准比较

与其他可比组织的做法进行比较，以确定最佳做法，形成改进建议，并为绩效评估提供依据。

系统交互图

产品范围的可视化描述，显示业务系统及其与人和其他系统的交互。

文件分析

通过分析现有的文档，使用与需求相关的信息来挖掘需求。

5.3.3需求文件收集过程的主要输出包括需求文件和需求跟踪矩阵。需求文档描述了各种单一需求如何满足与项目相关的业务需求。需求文档可以是一个简单的文档，根据涉众和优先级列出所有需求，也可以是一个详细的文档，包括执行摘要、详细描述和附件。其内容包括:

业务需求干系人需求解决方案需求项目需求过渡需求与需求有关的假设条件、依赖关系和制约因素。5.3.4 需求跟踪1. 需求跟踪的内容

每个配置项的需求应该可以从其相关产品(组件)的需求中双向追溯。双向跟踪包括向前跟踪和向后跟踪。正向跟踪是指检查需求文件中的每个需求是否能在后续工作产品(成果)中找到对应点；反向跟踪也称逆向跟踪，是指检查设计文档、产品组件、测试文档等工作成果是否能在需求文档中找到。具体来说，需求跟踪包括五种类型。如图，箭头表示需求跟踪能力的联系链，可以跟踪需求使用的全周期，即从需求建议到交付的全过程。

第五种联系链是需求文档之间的追踪，便于更好地处理各种需求之间的逻辑关联，检查需求分解中可能出现的错误或遗漏。

①追溯需求(客户需求-需求)

②从需求追溯(需求-下游工作产品)

③回到需求(下游工作产品-需求)

④需求回溯(需求-客户需求)

2. 需求跟踪矩阵

表达需求和其他产品元素之间的链接链的最常见方式是使用需求跟踪(能力)矩阵，这是一个将产品需求从其来源连接到满足需求的可交付成果的表格。

记录在需求跟踪矩阵中的典型属性包括唯一标识、需求的文档描述、包含需求的原因、所有者、来源、优先级、版本、当前状态(例如，进行中、已取消、已延期、新添加、已批准、已分配、已完成等。)和状态日期。

5.4 定义范围

范围定义(Scope definition)是对项目和产品进行详细描述的过程，是定义收集到的哪些需求将被纳入项目范围，哪些需求将被排除在项目范围之外的过程，从而定义产品、服务或成果的边界。

5.4.1 定义范围的工具与技术

主要工具和技术有专家判断、产品分析、备选方案生成和引导研究。

5.4.2 项目范围说明书1. 范围说明书的内容（1）产品范围描述。（2）验收标准。（3）可交付成果（4）项目的除外责任。（5）制约因素。（6）假设条件。

当项目经理向风险承担者解释项目范围时，应该基于项目范围规范。

2. 范围说明书的作用（1）确定范围。（2）沟通基础。（3）规划和控制依据。（4）变更基础。（5）规划基础。5.5 创建工作分解结构（WBS）

创建WBS是将项目可交付成果和项目分解成更小、更易管理的组成部分的过程。

5.5.1 WBS的层次1. 里程碑

里程碑标志着可交付成果或阶段的正式完成。

2. 工作包

因为工作包应该容易地分配给不同的人或组织单元，所以需要定义每个工作单元的直接接口。工作包要非常具体，让承担者明确自己的任务，努力的目标，施工的责任。

8/80法则:工作包的大小至少需要8个小时才能完成，总完成时间不能大于80个小时或两周。

3. 控制账户

账户控制是一个管理控制点。它可以是一个工作包，也可以是一个比工作包级别更高的元素。在后一种情况下，一个控制帐户包括几个工作包，但一个工作包只属于一个控制帐户。

4. 规划包

计划包是指控制账户下活动的WBS组成部分，工作内容相同，但缺少详细的进度。计划是控制账户下工作包的WBS要素。规划包用于临时规划。随着情况越来越明朗，规划包最终将被分解为工作包和相应的具体活动。

5. WBS词典

WBS字典是描述WBS组成部分的文件。WBS字典可能包括帐户代码标识、工作描述、假设和约束、负责人或组织单位、进度里程碑、相关进度活动、所需资源、成本估算、质量要求、验收标准、技术参考协议信息等。

5.5.2 分解

分解是一种将项目可交付成果和项目工作分解成更小、更易管理的组件的技术。为了将整个项目工作分解成工作包，通常需要以下活动:

识别和分析可交付成果及相关工作。确定WBS的结构和编排方法。自上而下逐层细化分解。为WBS组件制定和分配标识编码。核实可交付成果分解的程度是恰当的。1. 分解的原则

在创建WBS时，我们可以参考一些现成的分工原则，包括:

(1)功能或技术原则。在创建WBS时，你需要考虑将不同人的工作分开。

(2)组织结构。

(3)系统或子系统。将整个系统分为几个主要子系统，然后对每个子系统进行分解。

在项目实践中，可以通过以下方式进行分解:

(1)项目生命周期的每个阶段都是第二级分解，产品和项目可交付成果放在第三级。

(2)主要的可交付成果作为分解的第二层。

(3)整合可能由项目团队以外的组织实施的各种组件(例如外包工作)，然后作为外包工作的一部分，卖方需要准备一份响应性的合同WBS。

2. 工作过程

WBS不是项目团队成员的责任，而是应该由所有项目团队成员、用户和项目利益相关者完成和确认。常用的WBS识别形式主要有层次树形结构(组织结构图)和表格形式(列表形式)。

树型结构的WBS层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难标识出项目的全貌。表格形式的直观性比较差，但能够反映出项目所有的工作要素。3. 注意事项

在WBS分解过程中，要注意以下八个方面。

（1）WBS必须是面向可交付成果的。（2）WBS必须符合项目的范围。（3）WBS的底层应该支持计划和控制。（4）WBS中的元素必须有人负责，而且只有一个人负责，尽管实际上可能需要多个人参与。（5）WBS的指导，WBS应控制在4～6层。（6）WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。（7）WBS的编制需要所有（主要）项目干系人参与，需要项目团队成员的参与。（8）WBS并非是一成不变的。在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。5.5.3 WBS的作用

WBS的目的和用途主要体现在以下八个方面。

（1）明确和准确说明项目范围，项目团队成员能够清楚地理解人物的性质和需要努力的方向。（2）清楚的定义项目的边界，它提供了项目管理人员、项目产品或服务的用户、项目发起人、项目团队成员等其他项目干系人一直认可的项目需要做的工作和不需要做的工作。（3）为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需要的技术和人力资源。（4）针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。（5）为计划、预算、进度安排和费用控制奠定共通基础，确定项目进度和控制的基准。（6）将项目工作和项目的财务账目联系起来。（7）确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施（8）有助于防止需求蔓延。5.6 确认范围

范围确认是正式接受项目已完成的可交付成果的过程。确认范围包括与客户或赞助商一起审查可交付成果，以确保可交付成果已成功完成并被客户或赞助商正式接受。

5.6.1 确认范围概述

范围确认的主要工具和技术是检查和群体决策技术。检查，也称为复查、评审、审核、走查、检验、测试等。，是指为判断工作和交付成果是否满足要求和产品验收标准而进行的测量、评审和确认活动。

1. 确认范围的步骤

(1)确定范围确认的时间。

(2)确定范围并确认需要哪些输入。

(3)确定正式接受范围的标准和要素。

(4)确定范围确认会议的组织步骤。

(5)组织范围确认会议。

2. 需要检查的问题

项目干系人在确认范围时，一般需要检查以下六个方面。

(1)可交付成果是否明确和可识别。

(2)每个可交付物是否有明确的里程碑，里程碑是否有明确的可识别的事件，如客户的书面批准。

(3)是否有明确的质量标准？

(4)是否明确表达审计和承诺。

(5)项目范围是否涵盖需完成的产品或服务的所有活动，是否有遗漏或错误。

(6)项目范围内的风险是否过高，管理层能否降低可预见风险对项目的影响。

5.6.2 干系人关注点

管理层关注的项目范围是指范围对项目的进度、资金和资源的影响，这些因素是否超出了组织的范围，在投入和产出方面是否合理。

客户主要关心产品的范围，项目的可交付成果是否足以完成产品或服务。

项目经理主要关心的是可交付成果是否足够且必须完成，时间、资金、资源是否足够，主要潜在风险和需要解决的方法。

团队成员主要关注自己在项目范围内参与和负责的要素，通过定义范围内的时间来检查自己的工作时间是否足够，是否在项目范围内有多个工作，这些工作是否有冲突。

5.6.3 几个术语的比较1. 确认范围与核实产品

产品验证针对产品是否完成，在项目(或阶段)结束时由发起人或客户进行验证，强调产品是否完成；

确认范围是指客户或发起人在阶段结束时确认和接受项目可交付成果的过程。

2. 确认范围与质量控制

两者的区别在于:

确认范围主要强调可交付成果获得客户或发起人接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而控制质量并不一定在阶段末进行。质量控制属于内部检查，由执行组织的响应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。3. 确认范围与项目收尾

两者的区别在于:

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

范围控制是监控项目和产品的范围状态，管理范围基准变化的过程，其主要作用是在整个项目期间维护范围基准。当变更实际发生时，也应该采用范围控制过程来管理这些变更。

1. 范围变更的原因政府政策的问题。项目范围的计划编制不周密详细，有一定的错误或遗漏。市场上出现了或是设计人员提出了新技术、新手段或新方案。项目执行组织本身发生变化。客户对项目、项目产品或服务的要求发生变化。

产品或项目范围不受控制的扩大(没有对时间、成本和资源进行相应的调整)称为范围扩展。在信息系统集成项目中，变更是不可避免的，控制范围的过程依赖于范围变更控制系统。范围变更控制是控制相关项目范围变更和批准项目范围变更的一系列过程，包括书面文件、跟踪系统和授权变更所需的批准级别。

2. 范围变更控制的工作

范围变更控制的主要工作如下:

(1)影响导致范围变化的因素，并设法使这些因素朝着有利的方向发展。

(2)确定范围是否发生了变化。

(3)管理范围变更发生时的实际变更，确保所有请求的变更按照项目的整体变更控制流程进行处理。

第五章，吐血完毕！！！！