[需求管理-2]：什么是需求以及需求的收集与识别

作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客

本文网址：[需求管理-2]：什么是需求以及需求的收集与识别_文火冰糖的硅基工坊的博客-CSDN博客

第1章什么是需求识别

第2章需求的来源

2.1 外部需求（收集）

2.2 内部需求（开发）

第3章需求的层次

第4章需求的形式

4.1 提问题（针对业务层次需求、原始性需求）：第一性原理

4.2 提目的（针对任务层次需求）

4.3 提方案（针对系统层次需求）

4.4 功能性需求

4.5 非功能性需求

第5章收集需求的方法

5.1 定性 VS 定量

5.2 收集需求常用方法

第6章用户访谈

6.1 用户访谈的形式

6.1 明确用户访谈的形式

6.2 明确访谈目标

6.3 访谈的问题设计

6.4 用户访谈的注意事项

第7章其他方式

7.1 问卷调查

7.2 竞品分析

第8章原始需求列表池（backlog）

8.1 需求表格类型

8.2 表格内容

8.3 需求控制的原则

第1章什么是需求识别

需求定义：未满足的某种期望，预期与现状之间的差异部分就是需求。

需求识别：就是理解和表达潜在的需求。

客户需求存在的地方，就是为组织进行价值创造的地方。

（1）已知的已知：客户自己知道已有的需求。-- 客户主动提出来的需求

（2）未知的已知：客户不知道自己有某种需求 -- 需要需求工程师帮助客户发现。

（3）已知的未知：客户知道有可能有需要，但不明确 -- 需要需求工程师帮助客户发现。

（4）未知的未知：客户不知道是否有什么需求，认知盲区 -- 需要需求工程师帮助客户挖掘。

因此，需求工程师，不仅仅收集、理解、文档化客户的需求。还需要依靠自己的专业性帮助客户发现潜在的需求。

第2章需求的来源

2.1 外部需求（收集）

客户需求
行业分析
竞争对手
展览
出版物

2.2 内部需求（开发）

客户服务部门
产品经理部门
公司预研部门
业务部门
老板需求（这需要特别重要的需求）

第3章需求的层次

BR：Business Requirment，站在业务的角度。

UR：User Requirment，站在用户，系统的使用者角度。

SR：System Requirment，站在目标系统的实现的角度，这里的系统，通常是目标软件或硬件系统。SR的需求，是最接近软硬件系统的具体实现的。

备注：

越是高层的需求，越是远离软件产品的软硬件系统的具体实现。

需求工程师（包括产品经理、系统工程师）一个重要的职责：就把高层的业务需求，逐步转换成底层的组织内软硬件系统的具体实现的需求。

第4章需求的形式

不同层次的需要，呈现不同的形式。

4.1 提问题（针对业务层次需求、原始性需求）：第一性原理

这种类型的需求，通常是由客户提出来的。客户并不知道用什么方案来解决，也不知道提出什么样的目标和任务。通常，他们通常会提出自己遇到的困境和问题、甚至是难题。

解决客户的问题，是终结目标。提目的和体方案，都已经是手段了，也是一个公司存在的根基。

针对相同的客户问题，不同组织、不同的需求分析人员可能会给出不同的解决方案和解决手段。

原始需求是后续需求的原始档案。

4.2 提目的（针对任务层次需求）

这种类型的需求，有明确的目标或明确的任务。但并没有解决方案和实现方法。

4.3 提方案（针对系统层次需求）

这种层面的需要，不仅仅明确了要解决的问题和实现的目标，同时也给出了系统层面的解决方案，即对系统层面的解决方案进行了限制。这种需求，通常有客户的专家或组织内的产品经理、系统工工程师根据客户的实际问题，进行抽象和总结给出来的，是针对现有的目标软件系统给出来的需求。

4.4 功能性需求

功能性需求和非功能性需求，已经是针对系统需求提出来的。

（1）功能需求（functional requirement）

规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。

功能需求描述是开发人员需要实现什么。

注意：用户需求不总是能被转变成功能需求。

（2）产品特性 (feature)

所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。

对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。

客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用户用例，即被多个用例复用。而每个用例又要求实现多项功能需求，以便用户能够执行某项任务。

4.5 非功能性需求

非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括安全性、可靠性、互操作性、健壮性等。

在需求分析时，功能性需求是人们普遍关注的，但也不能忽视非功能性需求的分析，因为它所涉及的方面比较广泛。正因为如此也就往往被人们所忽视。

非功能性需求也可称之为软件开发的“约束”，这主要是因为从最简单的到最复杂的软件系统，都有反映软件系统质量和特性的额外要求，它从各个角度对所考虑的可能采取的解决方案起约束和限制作用。软件的非功能性需求主要是软件系统的性能、可靠性、运行限制等多个方面。

对于不同的软件系统，其非功能性需求不可能完全相同。具体的内容要根据需要和可能由软件和工作环境等具体情况来确定。在进行非功能性需求分析时，重要的是将精力放在那些至关重要的因素上。

非功能性需求是随着软件系统的规模成长和复杂性增加这两个因素才逐渐成为软件工程师们的新着眼点和关注点的，早期的时候，甲方处于自身对软件技术的了解和自身对系统文件维护的方便性考虑等，对系统有了诸如：开发平台、技术流派、关键实现等等方面的要求，这被称之为“设计约束”。从甲乙双方合同的角度，设计约束也是一种需求——一种“非功能”性的需求，后来，软件的质量问题越来越突出，描述软件质量目标的要求也成为非功能性需求的一部分。于是，目前业界关于软件的非功能需求，一般就包括：质量属性要求和约束性要求。

第5章收集需求的方法

5.1 定性 VS 定量

5.2 收集需求常用方法

（1）客户访谈：直接与客户交谈获取需要，可以发散、与可以聚焦。

（2）问卷调查：给用户填写结构化的问卷。

（3）竞品分析：分析对手的产品或服务

（4）客户反馈：来自客户的反馈意见（客户已经在使用组织的产品）

（5）头脑风暴：不同角色的人，发散性讨论。

（6）观察法：观察客户的现场，利用自己的专业技能，发现客户潜在的需求。

（7）文献分析：分析文献、论文、行业分析等等。

（8）数据分析：分析数据、进行大数据分析。

（9）行业积累：在行业内深耕，根据商业的敏感性预测未来的需求，这是高阶的获取需求的方式。

第6章用户访谈

6.1 用户访谈的形式

6.1 明确用户访谈的形式

相关研究机构将用户访谈分为3类，分别是：结构式访谈、半结构式访谈、开放式访谈。

1）结构式访谈

通常结构式访谈的问题和答案都会局限在一定范围内，结构式访谈聚焦于特定的问题，可以包含多选题和一定范围限制的问题。这种访谈方式成本低可以快速执行，但是无法获取用户更深层次的见解。

2）开放式访谈

开放式的访谈通常是对于某个问题的深入看法，如：针对这个问题您是怎么看的呢？针对这类问题用户可以随意发散，往往能更好获取用户内心真实想法，帮助设计师更好理解隐藏诉求和背后潜在动机。开放式访谈需要发起者把控好主题，在用户偏离主线时，将其及时拉回。

3）半结构式访谈

半结构式访谈可以理解为开放式和结构式访谈的一种折中访谈方式，是对特定问题快速询问并且确定范围的访问形式。通常访谈提纲制定的问题会从简单到复杂，从行为的描述到行为背后原因的探讨。简单的问题不需要思考只是常态的描述，复杂的问题通常需要用户阐述行为背后的深层原因。

6.2 明确访谈目标

① 了解具体用户使用场景

了解用户在什么场景下会使用该功能，帮助更好理解用户诉求。

② 使用中存在痛点

观察用户具体使用行为，观察沟通询问获取用户在不同使用场景中遇到的问题点，帮助更好弥合产品与用户之间鸿沟。

③ 获取用户预期

沟通中获取用户期望，帮助更好提升用户使用体验。

6.3 访谈的问题设计

（1）现状：用户现在是如何做的？

（2）痛点：未被满足的强烈的需求点，即现在遇到了哪些显著的困难。

（3）用户解决方案：用户针对他们的痛点，自己想出来的替代方案。

6.4 用户访谈的注意事项

（1）明知故问

（2）故意引导用户

（3）问题太发散、太开放

（4）太细节，难记忆

第7章其他方式

7.1 问卷调查

问卷调查是指通过制定详细周密的问卷，要求被调查者据此进行回答以收集资料的方法。所谓问卷是一组与研究目标有关的问题，或者说是一份为进行调查而编制的问题表格，又称调查表。它是人们在社会调查研究活动中用来收集资料的一种常用工具。调研人员借助这一工具对社会活动过程进行准确、具体的测定，并应用社会学统计方法进行量的描述和分析，获取所需要的调查资料。