知识点一 收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。本过程的主要作用是，为定义和管理项目范围（包括产品范围）奠定基础。（《PMBOK®指南》第110页）

解读 需求是项目成功的源头和基准。收集需求过程所识别出来的所有需求未必都要包含在项目中，所以后续还需要通过“定义范围”过程来界定。

知识点二 收集需求过程的输入：范围管理计划、需求管理计划、干系人管理计划、项目章程、干系人登记册。工具与技术：访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析。输出：需求文件、需求跟踪矩阵。（《PMBOK®指南》第111页，该过程的输入、工具与技术和输出见《PMBOK®指南》111页图5-4，该过程的数据流向图见《PMBOK®指南》111页图5-5。）

解读 收集需求过程一共包括11个工具和技术，是47个过程中工具和技术最多的一个过程。既然是收集需求，当然就要输出需求文件。

知识点三 需求包括发起人、客户和其他干系人的已量化且书面记录的需要与期望。（《PMBOK®指南》第112页）

解读 需要：显性的需求；期望：隐性的需求。根据需求的冰山模型，显性的需求大约占10%，隐性的需求大约占90%；相当多的项目做完后向客户提交项目成果时，客户说“这不是我所需要的”，核心原因就是我们没有把干系人的“期望”充分挖掘出来转变成显性的需求。

知识点四 许多组织把需求分为不同的种类，如业务解决方案和技术解决方案。前者是干系人的需要，后者是指如何实现这些需要。需求可以分成如下几类。业务需求：整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。干系人需求：干系人或干系人群体的需要。解决方案需求：为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求（功能需求是关于产品能开展的行为，如流程、数据，以及与产品的互动。非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量，如可靠性、安防性、性能、安全性、服务水平、可支持性、保留/清除等）。过渡需求。从“当前状态”到“将来状态”所需的临时能力，如数据转换和培训需求。项目需求：项目需要满足的行动、过程或其他条件。质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。（《PMBOK®指南》第112页）

解读 业务解决方案需求是指业务需求和干系人需求；技术解决方案需求是指如何实现业务解决方案需求。功能需求是指项目产品所具有的功用，非功能需求是指项目产品所应该呈现的特性。

知识点五 访谈是通过与干系人直接交谈来获取信息的正式或非正式的方式。（《PMBOK®指南》第114页）

解读 访谈通常是“一对一”沟通，既可当面沟通，也可以通过电话等工具进行沟通。

知识点六 焦点小组是召集预定的干系人或主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。（《PMBOK®指南》第114页）

解读 焦点小组一般是多人之间的沟通，在被调研者之间开展互动式讨论，以求得到更有价值的、焦点小组成员普遍认可的集体意见。参加者通常是同一个领域的主题专家，都熟悉作为会议主题的、某个特定的领域。

知识点七 引导式研讨会把主要干系人召集在一起，通过集中讨论来定义产品需求。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。（《PMBOK®指南》第114页）

解读 引导式研讨会比较适合于需要跨职能部门人员一起参与进行需求讨论的情形。

知识点八 在软件开发行业，有一种称为“联合应用设计/开发（JAD）”的引导式研讨会。这种研讨会注重把业务主题专家和开发团队集中在一起，来改善软件开发过程。（《PMBOK®指南》第114页）

解读 “联合应用设计/开发（JAD）”这种引导式研讨会的作用就是用来改善软件开发过程。

知识点九 在制造行业，则使用“质量功能展开（QFD）”这种引导式讨论会，来帮助确定新产品的关键特征。QFD从收集客户需要（又称“客户声音”）开始，然后客观地对这些需要进行分类和排序，并为实现这些需求而设定目标。（《PMBOK®指南》第114页）

解读 “质量功能展开（QFD）”这种引导式讨论会用来帮助确定新产品的关键特征。它是一种把顾客或市场的要求转化为设计要求、零部件特性、工艺要求、生产要求的多层次演绎分析方法。它也是一种结构化方法，用这种方法把顾客要求转化为产品开发和生产的每一阶段的适当要求。

知识点十 用户故事是对所需功能的简短文字描述，经常产生于需求研讨会。用户故事描述哪个干系人将从功能中受益（角色），他需要实现什么（目标），以及他将获得的收益（动机）。用户故事在敏捷方法中广泛使用。（《PMBOK®指南》第114页）(www.daowen.com)

解读 用户故事是从用户的角度来描述用户渴望得到的功能。一个用户故事包括3个要素：角色（谁要使用这个功能）、活动（需要完成什么样的功能）、商业价值（为什么需要这个功能，这个功能带来什么样的价值）。例如：“作为公司总经理（角色），他想要通过财务系统的汇总分析功能（功能）了解公司的财务状态，以便进行科学的决策（商业价值）。”就是一个用户故事。用户故事应该用简洁、通俗的语言来描述。

知识点十一 头脑风暴法是指一种用来产生和收集对项目需求与产品需求的多种创新的技术。名义小组技术是指用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。概念/思维导图是指把从头脑风暴中获得的创意合成一张图的技术，以反映创意之间的共性与差异，激发新创意。亲和图是指用来对大量创意进行分组的技术，以便进一步审查和分析。多标准决策分析是指借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。（《PMBOK®指南》第115页）

解读 头脑风暴法、名义小组技术、概念/思维导图、亲和图、多标准决策分析是常用的群体创新技术。头脑风暴法用于收集创意，它有3个特点：①事先不需要规定会议议程；②与会者可以畅所欲言；③任何人既不能打断发言者的发言，也不能对发言者的言论给出任何评价。多标准决策分析是用多个指标或从多个维度对方案进行综合评估，根据评估结果确定优先顺序。

知识点十二 群体决策技术就是为达成某种期望结果，而对多个未来行动方案进行评估的过程。达成群体决策的方法有一致同意（每个人都同意某个行动方案。达成一致同意的一种方法就是德尔菲技术，由一组选定的专家回答问卷，并对每轮需求收集的结果给出反馈。只有主持人可以看到专家的答复，以保持匿名状态）、大多数原则（获得群体中超过50%人员的支持，就能做出决策）、相对多数原则（根据群体中相对多数者的意见做出决策，即便未能获得大多数人的支持）和独裁（由某一个人为群体做出决策）。群体决策技术与群体创新技术联合使用。（《PMBOK®指南》第115～116页）

解读 德尔菲技术属于群体决策技术，不属于群体创新技术。采用大多数原则进行群体决策时，应该把参与决策的小组人数定为奇数；相对多数原则通常用在候选项超过两个时的情形。

知识点十三 问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。（《PMBOK®指南》第116页）

解读 问卷调查一般不能作为收集需求的主要手段，因为它只适合进行简单、少量的需求调查。复杂、大量的需求调查，由于需要耗费被调查者大量的时间和精力，如果采用问卷调查的方法，被调查者往往不会给出积极的配合和反馈。

知识点十四 观察是指直接察看个人在各自的环境中如何执行工作（或任务）和实施流程。当产品使用者难以或不愿清晰说明他们的需求时，就特别需要通过观察来了解他们的工作细节。（《PMBOK®指南》第116页）

解读 观察适用于“只可意会，不可言传”或“不愿言传”的情形。

知识点十五 原型法是指在实际制造预期产品之前，先造出该产品的实际模型，并据此征求对需求的早期反馈。因为原型是有形的实物，它使得干系人可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反馈循环过程。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。（《PMBOK®指南》第116页）

解读 “百闻不如一见”，原型法就是让“产品”尽早被用户所见。因此，原型法是一种很好的收集用户需求的方法。

知识点十六 标杆对照将实际或计划的做法（如流程和操作过程）与其他可比组织的做法进行比较以便识别最佳实践，形成改进意见，并为绩效考核提供依据。（《PMBOK®指南》第116页）

解读 标杆对照就是通过对比来快速、准确地识别和定位需求。

知识点十七 系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘，显示业务系统（过程、设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。（《PMBOK®指南》第117页）

解读 系统交互图展示系统与人之间或系统与系统之间的交互方式，可以为需求被调研者提供一种对产品的直观感受。

知识点十八 需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。（《PMBOK®指南》第118页）

解读 需求跟踪矩阵有两大主要作用：①跟踪产品需求被实现的过程（如针对软件项目，跟踪每一个需求从需求→设计→开发→测试→实施→验收的过程）；②记录每一需求所对应的后续可交付成果及其位置，从而在问题出现时方便快速追溯。