​​​ 点击报名后领取>>>软考16本电子版教材 & 36本辅导教材 + 27套历年真题试卷 + 21套精编知识点6G资料包​​​

（5-3节包括需求的分类、收集需求的工具与技术、需求文件及需求跟踪，今天文章内容文字部分有点儿多，主要集中在收集需求的工具与技术，已吐血为大家整理了汇总表，都是满满的干货，相信随着娱乐圈的瓜越吃越多，大家最近的文字阅读能力和逻辑分析水平突飞猛进，加油学习吧！加油）

收集需求(Collect Requirement)是为实现项目目标而确定、记录并管理干系人的需要和需求的过程，其作用是为定义和管理项目范围(包括产品范围)奠定基础。

项目一旦开始，就应该足够详细地获取、分析和记录这些需求，以便日后进行测量。认真掌握和管理项目需求与产品需求，对促进项目成功有重要作用。

需求是指根据特定协议或其他强制性规范，项目必须满足的条件或能力，或者产品、服务或成果必须具备的条件或能力。

需求包括发起人、客户和其他干系人的已量化且书面记录下来的需要与期望。

5.3.1 需求的分类

收集需求旨在定义和管理客户期望。

需求是WBS的基础，成本、进度和质量计划也都要在这些需求的基础上进行。

需求开发始于对项目章程和干系人登记册中相关信息的分析。

许多组织将需求分为不同的种类，例如，业务解决方案和技术解决方案，前者是干系人的需要，后者是指如何实现这些需要。

需求分类包括业务需求、干系人需求、解决方案需求、过渡需求、项目需求和质量需求等。

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

（2）干系人需求：是指干系人或干系人群体的需要。

（3）解决方案需求：是为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求。功能需求是关于产品能开展的行动，例如，流程、数据以及与产品的互动等。非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量，例如，可靠性、安全性、性能、服务水平等。

（4）过渡需求：从当前状态过渡到将来状态所需的临时能力。例如数据转换和培训需求。

（5）项目需求：项目需要满足的行动、过程或其他条件。

（6）质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求。

以上需求分类并不是唯一的，也不是从单一角度来进行分类的，在不同场合，会有不同的说法。

5.3.2 收集需求的工具与技术

收集需求是否科学、准备充分，对收集的结果影响很大。

大部分干系人无法完整地描述需求，而且也不可能看到产品的全貌。因此，收集需求只有通过与干系人的有效合作才能成功。

【收集需求的工具与技术】主要有访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析等。

1、访谈（最基本收集需求的手段）

【访谈定义】访谈是通过与干系人直接交谈来获取信息的正式或非正式的方法。

【三种访谈形式】包括结构化、非结构化、二者相结合

（1）结构化是指事先准备好一系列问题，有针对地进行；

（2）非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。

（3）最有效的访谈是结合这两种方法进行，可以保持良好的灵活性。

【访谈对象】有经验的项目参与者、干系人和主题专家，有助于识别和定义项目可交付成果的特征和功能。

【访谈优点】访谈具有良好的灵活性，有较宽广的应用范围。

【访谈困难及缺点】

（1）干系人经常较忙，难以安排时间。特别是需要多个被访谈者一起进行访谈时，这种困难显得更加突出。

（2）面谈时信息量大，记录较为困难。一般情况下，在访谈时只能使用纸笔进行记录， 不能录音或录像，因为涉及到被访谈者的隐私问题。如果必须要录音或录像，则必须事先告知被访谈者。

（3）沟通需要很多技巧，同时需要项目经理具有足够的领域知识、丰富的经验和较强的沟通能力等。

2、焦点小组

焦点小组将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度；由一位受过训练的主持人引导大家进行互动式讨论，以求得到更有价值的意见。

焦点小组是一种群体访谈而非一对一访谈（比一对一的访谈更加热烈），可以有6-10个被访谈者参加。

3、引导式研讨会

通过邀请主要的跨职能干系人一起参加会议，引导式研讨会(Facilitated Workshop)对产品需求进行集中讨论与定义。

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

由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。能够比单项会议更快地发现和解决问题。

【案例1】软件开发中常用的联合应用开发(Join Application Development，JAD)就是一种典型的引导式研讨会。这种研讨会注重将干系人和开发团队集中在一起，来改进软件开发过程。

【案例2】使用质量功能展开引导式研讨会，来帮助确定新产品的关键特征。质量功能展开从收集客户需求(客户声音)开始，然后客观地对这些需求进行分类和排序，并为实现这些需求而设置目标。质量功能展开的具体步骤如下。

(1)将用户的多种需求(例如，可靠性、可用性、安全性等)及其相对重要性列为矩阵表的第一列。

(2)将产品可能的多种特性(例如，功能列表)列为矩阵表的第一行。

(3)由相关专家集体讨论每种特性与每种需求之间的关联性，即每种特性能满足每种需求的程度，并记录在矩阵表相应的空格中。

(4)按列加权(考虑需求的重要性)汇总，即可看出哪种产品特性最能满足用户需求。

4、群体创新技术

群体创新技术(Group Creativity Technique)是指可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。

1)头脑风暴法

头脑风暴(Brain Storming，BS )法又称为智力激励法、自由思考法或集思广益法，是用来产生和收集对项目需求与产品需求的多种创意的一种技术。

头脑风暴法分为直接头脑风暴法和质疑头脑风暴法。头脑风暴法的参加人数一般为5-10人，最好由不同专业或不同岗位者组成，会议时间控制在1小时左右。

①直接头脑风暴法(通常简称为头脑风暴法)是在专家群体决策时尽可能激发创造性，产生尽可能多的设想的方法，

②质疑头脑风暴法(也称为反头脑风暴法)则是对前者提出的设想、方案逐一质疑，分析其现实可行性的方法。

2)名义小组技术

名义小组技术(Nominal Group technique)通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。

名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法。

其一般过程如下：

①将全体参与者分成多个“名义”上的小组，由每个小组开展讨论。

②小组讨论结束后，主持人依次向每位参与者询问，请每人提出一个创意。这种询问可以进行很多轮，直至得到足够数量的创意。

③请全体参与者对所有创意进行评审和排序。

也可以由名义小组先提出一些较大的创意类别，再将这些创意类别提交给全体参与者作为头脑风暴的基础。与一般的头脑风暴法相比，名义小组技术可以使那些不善言辞的参与者也能充分发表自己的意见。

3)德尔菲技术

德尔菲技术(Delphi Technique )是一种组.织专家就某一主题达成一致意见的一种信息收集技术。由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈。专家的答复只能交给主持人，以保持匿名状态。

【德尔菲技术方法的四大步骤】

(1)根据问题的特点，选择和邀请做过相关研究或有相关经验的专家。

(2)将与问题有关的信息分别提供给专家，请他们各自独立发表自己的意见，并写成书面材料。

(3)主持人收集并综合专家们的意见后，将综合意见反馈给各位专家，请他们再次发表意见。如果分歧很大，可以开会集中讨论;否则，主持人分头与专家联络。

(4)如此反复多次，最后形成代表专家组意见的方案。

【德尔菲技术的四大典型特征】

（1）吸收专家参与预测，充分利用专家的经验和学识。

（2）采用匿名或背靠背的方式，能使每一位专家独立自由地做出自己的判断。

（3）预测过程几轮反馈，使专家的意见逐渐趋同。

（4）有助于减轻数据的偏倚，防止任何个人对结果产生不恰当的影响。

德尔菲技术的这些特点使它成为一种最为有效的判断预测法。

德尔菲技术与常见的召集专家开会、通过集体讨论、得出一致预测意见的专家会议法既有联系又有区别。

【德尔菲技术的优点】

（1）既能发挥专家会议法的优点，即:

①能充分发挥各位专家的作用，集思广益，准确性高。

②能将各位专家意见的分歧点表达出来，取各家之长，避各家之短。

（2）同时，德尔菲技术又能避免专家会议法的缺点，即:

①权威人士的意见影响他人的意见。

②有些专家碍于情面，不愿意发表与其他人不同的意见，。

③出于自尊心而不愿意修改自己原来不全面的意见。

【德尔菲技术的缺点】 德尔菲技术的主要缺点是过程比较复杂，花费时间较长。

4）概念/思维导图

思维导图(Mind Mapping}又称为心智图，是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。

思维导图运用图文并重的技巧，将各级主题的关系用相互隶属与相关的层级图表现出来，将主题关键词与图像、颜色等建立记忆链接，思维导图充分运用左右脑的机能，利用记忆、阅读、思维的规律，协助人们在科学与艺术、逻辑与想象之间平衡发展。

5)亲和图

亲和图(Affinity Diagram)又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并将其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。

亲和图的核心是头脑风暴法，是根据结果去找原因。可以将大量创意分类，以便审查和分析。主要依据各种创意之间的相似性，对头脑风暴中得到的各种创意进行分类。

在项目管理中，亲和图针对某个问题，产生出可联成有组织的想法模式的各种创意，主要用来确定范围分解的结构，有助于WBS的制订。

6)多标准决策分析

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

5、群体决策技术

群体决策技术（Group Decision-Making）就是为了达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。

达成群体决策的方法很多，例如：

（1）一致同意(Unanimity )。所有人都同意某个行动方案。

（2）大多数原则(Majority )。获得群体中50%以上的人的支持，就能做出决策。参与决策的人数定为奇数，防止因平局而无法达成决策。

（3）相对多数原则(Plurality)。根据群体中相对多数者的意见做出决定，即便未能获得一部分人的支持。通常在候选项超过两个时使用该原则，例如，某个软件构件的功能有3种实现方案(标记为A, B, C)，在群体决策时，同意A方案的 人有40％，同意B方案的人有35%，同意C方案的人有25%，则最终确定采用A方案。

(4)独裁(Dictatorship)。由某一个人(例如，项目经理)为群体做出决策。

在收集需求的过程中，这些群体决策技术都可以与群体创新技术联合使用。

6、问卷调查

问卷调查（Questionnaire and Survey）是指通过设计书面问题，向为数众多的受访者快速收集信息。

【问卷调查的优点】

（1）如果受众众多、需要快速完成调查，受访者地理位置分散，并想要使用统计分析法，就适宜采用问卷和/或调查方法。

（2）与访谈法相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据：

（3）问卷调查允许回答者匿名填写，大多数干系人可能会提供真实信息；

（4）问卷调查的结果比较好整理和统计。

【问卷调查的缺点】

（1）最大的不足就是缺乏灵活性

（2）双方未见面，项目经理无法从干系人的表情等其他动作来获取一些更隐性的信息，干系人也没有机会立即澄清对问题有含糊或错误的回答。

（3）干系人有可能在心理上会不重视一张小小的表格，不认真对待，从而使得反馈的信息不全面。

（4）调查表不利于对问题进行展开的回答，无法了解一些细节问题。

（5）回答者的数量往往比预期的要少，无法保证干系人会回答问题或进一步说明所有问题。

因此，较好的做法是将访谈和问卷调查结合使用。具体来说，就是先设计问题，制作成问卷调查表，下发填写完后，进行详细的分一组、整理和分析，以获得基础信息。然后，再针对分析的结果进行小范围的干系人访谈，作为补充。

7、观察

观察(observation)是指直接观察个人在各自的环境中如何开展工作和实施流程。

当产品使用者难以或不愿说明他们的需求时，就特别需要通过观察来了解细节。

观察也称为工作跟踪，通常由观察者从外部来观察使用者的工作。观察也可以由参与观察者进行，参与观察者需要实际执行一个流程或程序，体验该流程或程序是如何实施的，以便挖掘出隐藏的要求。

8、原型法

原型法（Prototype）是一种根据干系人初步需求，利用产品开发工具，快速地建立一个产品模型展示给干系人，在此基础上与干系人交流，最终实现干系人需求的产品快速开发的方法。

原型是有形的实物，它使干系人有机会体验最终产品的模型，而不是只讨论抽象的需求陈述。原型法符合渐进明细的理念，因为原型需要重复经过开发、试用、反馈、修改等过程·在经过足够的重复之后，就可以从原型中获得足够完整的需求井进而进入设计或制造阶段。

【实际案例】在软件产发中，原型是系统的一个早期可运行的版本，它反映最终系统的部分重要特性。如果在获得一组基本需求说明后，通过快速分析构造出一个小型的系统，满足干系人的基本要求，使得干系人可在试用原型系统的过程中得到亲身感受和受到启发，做出反应和评价，然后开发者根据干系人的意见对原型加以改进。随着不断试验、纠错、使用、评价和修改，获得新的原型版本，如此周而复始，逐步减少分析和通信中的误解，弥补不足之处，进一步确定各种需求细节，适应需求的变更从而提高了最终产品的质量。

9、标杆对照

标杆对照(Benchmarking)将实际或计划的做法与其他类似组织的做法(例如，流程、操作过程等)进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。

标杆对照所采用的“类似组织”可以是内部组织，也可以是外部组织。

10、系统交互图

系统交互图(context Diagram)是范围模型的一个例子，它是对产品范围的可视化描述，显示系统(过程、设备、信息系统等)与参与者(用户、独立于本系统之外的其他系统)之间的交互方式。

系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。例如，软件需求分析中的DFD、用例图都可以看作是系统交互图。

11、文件分析

文件分析(document Analysis)就是通过分析现有文档，识别与需求相关的信息来挖掘需求。

可供分析的文档很多，包括商业计划、营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等。

收集需求过程的主要输出有需求文件(Requirements documentation)和需求跟踪矩阵。

5.3.3 需求文件

【定义】需求文件描述各种单一的需求将如何满足与项目相关的业务需求。

【格式】需求文件的格式多种多样，在不同的组织中，可能有不同的称呼。

【内容详略程度】需求文件既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

需求文件的内容包括（但不限于）以下几个方面：

（1）业务需求：包括可跟踪的业务目标和项目目标、执行组织的业务规则、组织的指导原则

（2）干系人需求：包括对组织其他领域的影响、对执行组织内部或外部团体的影响、干系人对沟通和报告的需求。

（3）解决方案需求，包括功能和非功能需求、技术和标准合规性(Complicance)需求、 支持和培训的需求、质量需求和报告需求。可用纯文本方式或用模型展示解决方案需求，也可两者同时使用。

（4）项目需求，包括服务水平、绩效、安全和合规性等，以及验收标准。

（5）过渡需求。

（6）与需求有关的假设条件、依赖关系和制约因素。

【实际案例】软件需求规格说明书就是一种典型的需求文件。因为项目具有渐进明细的特点，一开始，可能只有概括性的需求，然后随着信息的增加而逐步细化。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的，_且主要干系人愿意认可的需求，才能作为基准。

5.3.4 需求跟踪

在CMMI中，需求管理是已管理级的一个关键过程域，其目标是为产品需求建立一个基线，供软件开发及其管理使用，使计划、产品和活动与需求保持一致。

从需求工程的角度来看，需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。

可跟踪性包含两个层面的含义：

（1）项目执行过程的两个或多个产品之间能够建立关系的程度，尤其是那些具有前后关系或主从关系的产品。例如，某个给定构件的需求和设计的匹配程度；

（2）项目产品中每个元素能够建立其存在理由的程度，例如，产品设计中的每个元素定位它所满足需求的程度。

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

1、需求跟踪的内容

每个配置项的需求到其涉及的产品(或构件)需求都要具有双向可跟踪性。

所谓双向跟踪，包括正向跟踪和反向跟踪：

（1）正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品(成果)中找到对应点；

（2）反向跟踪也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。具体来说，需求跟踪涉及五种类型，如图5-1所示。

2、需求跟踪矩阵

需求跟踪(能力)矩阵是表示需求和其他产品元素之间的联系链的最普遍方式。

需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。

需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束时都能交付，还可以为管理产品范围变更提供框架。

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

（1）业务需求、机会、目的和目标；

（2）项目目标；

（3）项目范围 (WBS可交付成果)；

（4）产品设计；

（5）产品开发；

（6）测试策略和测试场景；

（7）高层级需求到详细需求。

不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵，它保存了需求与后继工作

成果的对应关系。需求跟踪矩阵中可以定义各种产品元素类型间的一对一、一对多和多对多关系。

例如，一个构件对应一个设计元素，多个测试案例验证一个功能点，每个用例导致多个功能点等。

应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态(例如，进行中、己取消、已推迟、新增加、已批准、已分配、已完成等)和状态日期。

另外，为了确保干系人满意，可能需要增加一些补充属性，例如，稳定性、复杂性和验收标准等。

文章源于网络，如有侵权，请私信文章标题联系删除，谢谢。

为了能让更多人享受软考的政策福利和现实功利，51CTO旗下软考教研团队联合薛大龙老师，认真严肃向大家推出软考2日直播特训营。

软考资料包括：软考16本电子版教材 & 36本辅导教材 + 27套历年真题试卷 + 21套精编知识点6G资料包​

软考训练营名额+资料领取方式>>>

扫下方码入群后按照老师的要求操作即可领取。

51CTO软考两天直播训练营

这门课恰好能够为你答疑解惑，助你快速入门并掌握软考知识要点，获得技能提升。为自己的职业发展规划制定一个更明确的规划，迈出升职加薪的第一步。

训练营周期为 两天直播课 晚8：00-9：00

心急的小伙伴可直接扫码解锁。

☟☟☟

2天软考直播特训营

3大必备技能

↓↓↓

限时 0 元 即可解锁

点击下方链接报名

仅限前100个名额

报名链接: ​ ​​https://edu.51cto.com/surl=oR9sp3​​​

课程涵盖：高分知识点梳理，案例分析解题方法、论文通用模板等。我们力争通过2天的直播课程，助力您快速入门并一次性通关软考！

如果你对这门课程还不太了解的话，就跟我一起往下看吧。

我们的主讲老师薛大龙老师，深耕软考教育培训20余年，主编出版软考辅导教材60余本，非常熟悉软考题目的要求、难度、以及判卷标准。

完成本体验营2天所有课程及作业考核，学员将掌握信息系统项目管理师、系统集成项目管理工程师的高频考点及答题技巧：

①掌握信息系统项目管理师知识体系；

②掌握考试高分占比知识领域；

③掌握考试考情前沿分析；

④掌握论文与案例超干货答题方法；

⑤掌握名师对真题的独到解析。

报名前，你还需要知道的3件事

1）课程形式

直播课程+社群学习活动

2）课程时间

报名后老师安排上课 晚8:00-9:00

3）报名后要做什么？

付费后根据提示添加学姐为好友，开营前学姐会统一拉人入群。

2天软考考证特训营

0 元 解锁课程

还可 领取「6G课程资料」

点击下方链接报名 仅限前100个名额