三、收集需求

在这里插入图片描述

需求是用户满意的前提—发散式收集

在这里插入图片描述

原则：尽量多的收集需求

裁剪收网-优先级排序和需求会

在这里插入图片描述

收集需求-工具及技术

1. 访谈

在这里插入图片描述

结构化访谈：事先准备好一些列问题，有针对性的进行
非结构化访谈：列出一个粗略的想法
实际中常常两者结合

2. 焦点小组

焦点小组会议（预定的干系人和主题专家集中在一起讨论）

在这里插入图片描述

3.引导式研讨会

跨职能、集中式讨论。比单项会议能更快的发现和解决问题。
JAD 联合应用设计/开发 Joint Application Development < 干系人+开发团队>
QFD 质量功能展开 Quality Function Deployment <客户声音（用户故事）>
QFD步骤：
（1）将用户需求作为第一列
（2）将特性做为第一行
（3）集中讨论特性与需求的关联性
（4）确定哪些特性最能满足需求

4. 群体创新技术（6个）※

（1）头脑风暴
关键词：面对面、畅所欲言、相互启发；人数5-10人，时长1小时左右
原则：1)庭外判决原则：评判必须放到最后阶段，2)欢迎各抒己见，自由鸣放；3)追求数量；4)探索取长补短和改进办法
缺点：可能会于屈服权威

（2）名义小组技术
通过投票来排列最有用的创意；以便进行进一步的头脑风暴或优先排序，也可以先提出一些较大的创意类别，做为头脑风暴的基础

头脑风暴+优先排序

（3）德尔菲技术
关键词：背对背、匿名，以问卷方式多次征询专家意见
过程步骤：(1)选择有相关经验的专家。(2)将信息分别提供给专家，请他们各自独立发表自己的意见，并写成书面材料。(3)主持人收集并综合专家们的意见后，将综合意见反馈给各位专家，请他们再次发表意见。如果分歧很大，可以开会集中讨论；否则主持人分头与专家联络。(4)如此反复多次，最后形成代表专家组意见的方案。

优点：
--能充分发挥各位专家的作用，集思广益，准确性高。
--减少数据及各方面的偏见。
--能把专家意见的分歧点表达出来，避免权威人士的意见影响他人的意见；
缺点是过程复杂、耗时

背对背，专家与专家之间也不能联系

（4）概念/思维导图

image

中心主题
思维放射

（5）亲和图

亲和图

收集想法 --> 亲和性（相近性） --> 归纳分类
亲和图(Affinity Diagram) 又称为KJ法， 是针对某一问题， 充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。
亲和图的核心是头脑风暴法，是根据结果去找原因。
主要用来确定范围分解的结构， 有助于WBS的制订。

头脑风暴+归类分组

（6）多标准决策分析
借助决策矩阵，采用多标准评估和排序方案

在这里插入图片描述

5. 其它

• 群体决策技术：一致同意；大多数原则(50%以上)；相对多数原则(有超过两个方案时)；独裁现象

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

• 观察：直接察看个人在各自的环境中如何执行工作(或任务)和实施流程(产品使用者难以或不愿说明需求时。可以挖掘隐藏需求)

• 原型法：在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈标杆对照：与其他类似组织的做法比较，识别最佳实践，形成改进意见(差异性分析)

• 系统交互图：是对产品范围的可视化描述。显示系统与参与者的交互方式；系统间交互等，显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者(如DFD、用例图)

• 文件分析：文档考古。分析现有文档，识别与需求相关的信息，来挖掘需求

输出-需求文件

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

1. 需求清单
2. 需求规格说明书

输出-需求跟踪矩阵

表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果的一种表格。有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付，还可以为管理产品范围变更提供框架。

在这里插入图片描述

需求管理-需求跟踪

需求跟踪

1.正向跟踪：正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品(成果)中中找到对应点(以免需求被做漏、做偏)

2.反向跟踪：也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处(是查需求源头，了解为什么要做这个需求，来源背景和原因是什么)

在这里插入图片描述

①从用户原始需求可向前追溯到需求文件，可区分受变更影响的需求，确保需求文件包括所有用户需求

②从需求文件回溯到相应的用户原始需求，确认每个需求的出处

③从需求文件追溯到产品元素，可知每个需求对应的产品元素，从而确保产品元素满足需求

④产品元素回溯到需求文件，使项目团队成员知道产品元素存在的原因(如果设计元素或测试案例无法回溯到需求文件，则可能是镀金；如果孤立的产品元素是一个正当功能，则可能是需求遗漏)

⑤ 需求文件之间的跟踪，便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。