【中项】系统集成项目管理工程师-第11章 项目范围管理-11.2收集需求

前言：系统集成项目管理工程师专业，现分享一些教材知识点。觉得文章还不错的喜欢点赞收藏的同时帮忙点点关注。 

       软考同样是国家人社部和工信部组织的国家级考试，全称为“全国计算机与软件专业技术资格（水平）考试”，目前涵盖了计算机软件、计算机网络、计算机应用技术、信息系统、信息服务5大领域，总共27个科目，也是分为初、中、高三个级别。

       通信专业主要需要关注“计算机网络”这个专业类别，可以考的科目有初级资格的“网络管理员”、中级的“网络工程师”。

       还有5个高级资格专业，分别是“信息系统项目管理师“”系统分析师“”系统架构设计师“”网络规划设计师“”系统规划与管理师“。

       软考高级证书在通信行业比较吃香，主要原因有两个： 通信行业与计算机软件是相近专业，评职称满足相近专业的要求； 通信高级不能以考代评，但软考高级可以，很多考生通过考软考高级来评高级职称。
————————————————

                       

11.2收集需求

        收集需求是为实现目标而确定、记录并管理干系人的需要和需求的过程。本过程的主要作用是 为定义产品范围和项目范围奠定基础。本过程仅开展一次或仅在项目的预定义点开展。图11-4描述了 本过程的输入、工具与技术和输出。

        让干系人积极参与需求的探索和分解工作（分解成项目和产品需求），并仔细确定、记录和管 理对产品、服务或成果的需求，能直接促进项目成功。需求是指根据特定协议或其他强制性规范， 产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他干系人的已量化且书面记录 的需要和期望。应该足够详细地挖掘、分析和记录这些需求，并将其包含在范围基准中，在项目执 行开始后对其进行测量。需求将作为后续工作分解结构（WBS）的基础，也将作为成本、进度、质 量和采购规划的基础。

        收集需求过程的主要输入为项目管理计划和项目文件，主要工具与技术为数据收集、数据分 析、决策、数据表现、人际关系与团队技能、系统交互图和原型法，主要输出为需求文件和需求跟 踪矩阵。

11.2.1主要输入（ 中23下2次）

1.项目管理计划

收集需求过程使用的项目管理计划组件主要包括：范围管理计划、需求管理计划和干系人参与 计划等。

（1）范围管理计划。范围管理计划包含如何定义和制定项目范围的信息。

（2）需求管理计划。需求管理计划包含如何收集、分析和记录项目需求的信息。

（3）干系人参与计划。从干系人参与计划中了解干系人的沟通需求和参与程度， 以便评估并适 应干系人对需求活动的参与程度。

2.项目文件

可用作收集需求过程输入的项目文件主要包括假设日志、经验教训登记册和干系人登记册等

（1）假设日志。假设日志识别了有关产品、项目、环境、干系人以及会影响需求的其他因素的 假设条件。

（2）经验教训登记册。经验教训登记册提供了有效的需求收集技术，尤其针对使用敏捷或适应 型产品开发方法的项目。

（3）干系人登记册。干系人登记册用于了解哪些干系人能够提供需求方面的信息，及记录干系人对项目的需求和期望。

11.2.2主要工具与技术

1.数据收集

可用于收集需求过程的数据收集技术主要包括头脑风暴、访谈、焦点小组、 问卷调查和标杆对 照等。

（1）头脑风暴。头脑风暴是一种用来产生和收集对项目需求与产品需求的多种创意的技术。

（2）访谈。访谈是通过与干系人直接交谈来获取信息的正式或非正式的方法。访谈的典型做法 是向被访者提出预设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间 的“一对一 ”谈话，但也可包括多个访谈者和/或多个被访者。访谈有经验的项目参与者、发起人和 其他高管及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机 密信息。

（3）焦点小组。焦点小组是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或 成果的期望和态度。 由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对 一 ”的访谈更热烈。

（4） 问卷调查。 问卷调查是指设计一系列书面问题， 向众多受访者快速收集信息。 问卷调查方 法非常适用于受众多样化、需要快速完成调查、受访者地理位置分散，并且适合开展统计分析的情 况。

（5）标杆对照。标杆对照将实际或计划的产品、过程和实践与其他可比组织的实践进行比较， 以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内 部的，也可以是外部的。（ 高22上、中21上）

2.数据分析

        可用于收集需求过程的数据分析技术是文件分析。文件分析指审核和评估任何相关的文件信 息。在此过程中，文件分析通过分析现有文件，识别与需求相关的信息来获取需求，可供分析并有 助于获取需求的文件包括协议，商业计划，业务流程或接口文档，业务规则库，现行流程，市场文 献， 问题日志，政策、程序或法规文件（如法律、准则、法令等） 、建议邀请书、用例等（中22下 广）。

3.决策

适用于收集需求过程的决策技术主要包括投票、独裁型决策制定和多标准决策分析等。

（1）投票。投票是一种为达成某种期望结果，而对未来多个行动方案进行评估的决策技术和过 程。本技术用于生成、归类和排序产品需求。

（2）独裁型决策制定。采用这种方法将由一个人负责为整个集体制定决策。

（3）多标准决策分析。该技术借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和 价值收益等多种标准，以对众多创意进行评估和排序。

4.数据表现

可用于收集需求过程的数据表现技术主要包括亲和图和思维导图等。

（1）亲和图。用来对大量创意进行分组的技术，以便进一步审查和分析。

（2）思维导图。把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异， 激发新创意

5.人际关系与团队技能

可用于收集需求过程的人际关系与团队技能主要包括名义小组技术、观察和交谈、引导等

（1）名义小组技术。名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创 意， 以便进一步开展头脑风暴或优先排序（ 高21下、高19下） 。名义小组技术是一种结构化的头脑 风暴形式， 由以下4个步骤组成：

●向集体提出一个问题或难题，每个人在沉思后写出自己的想法。

●主持人在活动挂图上记录所有人的想法。

●集体讨论各个想法，直到全体成员达成一个明确的共识。

●个人私下投票决出各种想法的优先排序，通常采用5分制，1分最低，5分最高。为减少想法数 量、集中关注想法，可进行数轮投票。每轮投票后，都将清点选票，得分最高者被选出。

（2）观察和交谈。观察和交谈是指直接查看个人在各自的环境中如何执行工作（或任务）和实 施流程。当产品使用者难以或不愿清晰说明他们的需求时，特别需要通过观察来了解他们的工作细 节。观察也称为“工作跟随 ”，通常由“旁站观察者 ”观察业务专家如何执行工作，但也可以由 “参与观察者 ”来观察，即通过实际执行一个流程或程序，来体验该流程或程序是如何实施的， 以便 挖掘隐藏的需求。

（3） 引导。引导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求。研讨会可用 于快速定义跨职能需求并协调干系人的需求差异。因为具有群体互动的特点，有效引导的研讨会有 助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见。此外，与分别 召开会议相比，研讨会能够更早发现并解决问题。

6.系统交互图

系统交互图是对产品范围的可视化描绘，可以直观显示业务系统（过程、设备、计算机系统 等）及其与人和其他系统（行动者）之间的交互方式。

7.原型法

原型法是指在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。 原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的实物，它 使得干系人可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的 理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈 循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段（ 高21上、中22上、20 下）。

故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行 业的各种项目中，如电影、广告、教学设计， 以及敏捷和其他软件开发项目。在软件开发中，故事 板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

11.2.3主要输出

1.需求文件

        需求文件描述各种单一需求将如何满足项目相关的业务需求。一开始可能只有高层级的需求， 然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的） 、可跟踪的、完整 的、相互协调的，且主要干系人愿意认可的需求，才能作为基准（ 高22上）。需求文件的格式多种 多样，既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提 要、细节描述和附件等的详细文件。许多组织把需求分为不同的种类，如业务解决方案和技术解决 方案。前者是干系人的需要，后者是指如何实现这些干系人需要的方案。把需求分成不同的类别， 有利于对需求进行进一步完善和细化。需求的类别一般包括业务需求、干系人需求、解决方案需 求、过渡和就绪需求、项目需求和质量需求等。

（1）业务需求。整个组织的高层级需要，例如，解决业务问题或抓住业务机会， 以及实施项目 的原因（ 高19上）。

（2）干系人需求。干系人的需要。

（3）解决方案需求。为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能 和特征。解决方案需求又可以进一步分为功能需求和非功能需求。功能需求描述产品应具备的功 能，例如，产品应该执行的行动、流程、数据和交互；非功能需求是对功能需求的补充，是产品正 常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持 性、保留或清除等。

（4）过渡和就绪需求。如数据转换和培训需求。这些需求描述了从“ 当前状态 ”过渡到“将来 状态 ”所需的临时能力。

（5）项目需求。项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因 素等。

（6） 质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标 准，例如，测试、认证、确认等。（ 高23上）

2.需求跟踪矩阵

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟 踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有业务价值。需求 跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项 需求在项目结束的时候都能实现并交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。 跟踪需求的内容包括：（ 中23下）

●业务需要、机会、 目的和目标；

●项目目标；

●项目范围和WBS可交付成果；

●产品设计；

●产品开发；

●测试策略和测试场景；

●高层级需求到详细需求等。

        应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需 求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来 源、优先级别、版本、当前状态和状态日期。为确保干系人满意，可能需要增加一些补充属性，如 稳定性、复杂性和验收标准。需求跟踪矩阵示例如图11-5所示。

需求跟踪矩阵
项目名称：
成本中心：
项目描述：
标识	关联标识	需求描述	业务需要 机会、 目 的和目标	项目目 标	WBS 可交付成果	产品设 计	产品开 发	测试案 例
001	1.0
	1. 1

	1.2
	1.2.1
002	2.0
	2. 1
	2. 1.1
003	3.0
	3. 1
	3.2
004	4.0
005	5.0

图11-5：需求跟踪矩阵示例

1 #include "stdio.h"
2 void main()
3 {
4     int time;
5     for (time=1;time<=10;time++)
6     printf("%d、喜欢的帮忙点赞收藏加关注哦！\n",time);
7 }