前言
在软件开发的过程中，我们经常遇到以下两种情况：
1、客户说的不一定是客户想要的；
2、需求传递失真是客观存在的。
一、什么是需求
IEEE 《软件工程标准词汇表（1997）》从用户角度和开发者角度定义需求：
（1）用户解决问题和达到目标所需的条件或能力；
（2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力；
（3）一种反应上面（1）或（2）所描述的条件或权能的文档说明。
在IEEE830【1998年版】中，将软件需求总结为以下需求：
1）功能性需求
功能性需求是软件需求的主题，即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。是系统应提供的服务、系统针对特定输入如何响应，以及系统在特定情形下行为的陈述。如，51CTO博客的功能性需求是：对用户开放博客的编写、查看、编辑、删除，个人信息的换头像、更改密码等。
2）非功能性需求
作为对功能性需求的补充，软件需求分析的内容中还应该保护一些非功能需求（DFX需求）。主要包括软件使用时对性能方面的要求、运行环境要求。软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。如：
性能：页面的响应时长不超过3秒。
备份：用户不正常退出时，需将用户编辑的内容存为草稿。
兼容性：用户使用IE浏览器、谷歌浏览器、火狐浏览器登录51CTO的博客模块，都可以正常使用。
3）设计约束
一般也称为设计限制条件，通常是对一些设计或实现方案的约束说明。如，数据库、部署环境等。
1.1 需求的分类（KANO模型）
众所周知，马洛斯认为，人的诉求主要由生理需求、安全需要、社交需求、尊重需求、自我价值实现的需求5类构成，这就是著名的马洛斯模型。
那么，对于产品来说，东京理工大学教授：授野纪昭（Noriaki Kano）通过对用户需求分类和优先排序的有用工具，以此分析用户需求对用户满意度的影响为基础，总结出了一种可以体现产品性能和用户满意之间的非线性关系，这便是KANO模型。
KANO模型定义了5类需求：必备型需求、期望型需求、魅力型需求、无差异需求、反向需求。
1）必备型需求（基本型需求）：
顾客对产品或服务的基本要求，即用户认为产品或服务“必须有”的属性或功能。
2）期望型需求：
用户的满意状况与需求的满足程度成比例关系的需求，这是处于成长期的需求，客户、竞争对手和企业自身都关注的需求，也是体现竞争能力的需求。对于这类需求，企业的做法应该是注重提高这方面的质量，要力争超过竞争对手。
3）魅力型需求（兴奋型需求）：
指不会被顾客过分期望的需求。这类需求往往是代表用户的潜在需求，企业的做法就是去寻找发掘这样的需求，领先对手。
4）无差异需求
无论提供或不提供，用户的满意度都不会改变，用户不在意的需求。
5）反向需求
提供后用户满意度反而会下降的需求。
1.2 需求的九种属性
需求作为一种特殊的信息，具有一些重要的属性。而大部分管理需求的活动，就是围绕需求的属性展开的，所以深入了解需求的内在属性，对于如何开展需求管理是至关重要的。需求有多种属性，最重要的属性可以总结为如下9点：
1）基础属性：二重性
需求=“问题”+“解决方案”
“问题”是“广义”的问题，不一定是缺陷，也可能是一种愿望，是“用户期望”和“现状”之间的差距。澄清问题比澄清解决方案更加重要和优先。“问题”是根源，是出发点。对于一个问题，其解决方案通常不只一种。如果我们无法得到明确的“问题”，就无法找出正确的“解决方案”。
这有一个误区：大多数人由于过于关注解决方案，在描述需求时往往会直接描述自己拟制好的解决方案，以解决方案来代替整个需求，这是导致需求被误解和失真的主要原因之一。
2）需求属性：易变性
需求的易变性是指需求从提出以后到实现以前，可能部分或全部发生变化。根据需求的二重性，其易变性可以总结为如下三种情况：
> “问题”发生变化或者消失。
> “解决方案”被替换。
> “解决方案”的细节发生变化。
在IT需求分析中，如果已经看到需求易变性的风险，可以通过以下方式规避：
需求取消
需求简化
IT功能上增强配置性
3）需求属性：约束性
需求的“问题”和约束条件，可以比喻为浮在海面的冰山。露出水面的“问题”占整个冰山的20％，而隐含在水下的约束条件却占冰山的80％。例如第三方依赖条件、网络准入规范、请求并发数、设备兼容性等，这些就是需求的约束性。
如果在分析问题时未能充分把握约束条件，则解决方案将面临多次返工的风险，甚至推倒重来。
做好需求的约束条件分析，应采取至少如下三种基本方法：
> 有计划、系统性收集可能对解决方案有影响的业务相关信息，建设业务信息知识库，以便在分析需求时进行查询。如业务文档，接口规范等。
> 在具体的需求分析中加强场景分析，模拟用户的行为过程来寻找更多的隐含条件，并考虑在现场进行专题调研。如场景分析，功能时序图。
> 利用DEMO等方式，将解决方案原型与客户进行确认，以便发现更多的隐含因素，并验证解决方案的正确性。可以参照相近的系统，或者用低保真方式展现方案的关键部分。如原型机、UCD原型设计稿。
4）需求属性：关联性
需求分析前，需要将收集的需求划分“需求集”：
“需求集”：通过不同渠道产生的需求是一个个颗粒度不同的独立信息，而这些独立的需求信息，也可能是相关或雷同的。在初步整合、归纳雷同的需求后，所得到的一组需求，就构成了“需求集” 。
“需求集”的可以按照不同维度划分。如，同一个业务功能的需求，同一个客户的需求，同一个产品的需求等等。按照“需求集”分析需求，可以更好的考虑分析需求之间的关联关系，如雷同需求、冲突需求、前后依赖等。
5）需求属性：演进性
什么是需求的演进性？
> 正如上面所提到的，需求包括“问题”和“解决方案”，“问题”中还包含约束条件。随着需求的澄清、分析、实施过程，这三要素会不断发生演进，沿时间轴的先后顺序进行转化。这就是需求的演进性。
> 这个逐步明晰化的过程，不是一次完成的，而是经过了若干中间步骤。只有清晰地定义出所需的中间步骤，才能有效指导需求的分析过程管理。
> 需求的演进性，就是将需求从不明确到明确的中间过程进行了定义。定义的目的，就是为了指导这个“逐步明确化”的过程循着科学的方法论、规范的过程来进行。
根据需求演进特性，可定义如下四个演进关键步骤：
Step1：业务构想idea（识别领域）
问题域：开始意识到问题的存在
解决方案域：寻找初步的解决办法
Step2：业务策略tactics（问题细分与选择/指出目标）
问题域：对问题进行了概括，初步识别了问题的范围
解决方案域：找出了多个可能方案，尝试进行选择
Step3：行动计划action plan（方案与步骤）
问题域：识别出问题的表象及根源，区分主要矛盾与次要矛盾
解决方案域：对选定的方案进行优化完善并拟制了计划里程碑
Step4：任务task（聚焦点/具体工作）
问题域：对所有要解决的问题点识别出了细节性的约束条件
解决方案域：将里程碑计划分解为可实施的具体工作单元
6）需求属性：多维性
> 需求的多维性，简单说就是可以从多个不同的角度来看待同一组需求。只有意识到需求可以从多个维度看待，才能避免在分析、分类时陷入误区。
> 由于需求具备上述提到的多种属性，而每条需求本身也有具体的客户、相关的产品与技术、所属地区等具体特征，所以可以从很多种维度来分析需求，或者说可以将需求分成很多种类别。
> 需要注意的是，每次只能使用一致的维度去分析一组需求，而不能混用多种维度。在一种维度使用后，可以换用第二种维度来分析，直到使用过足够多的维度，将需求各方面都考虑完全为止。
> 需求的多维性，在对需求集分析时，我们可以想像需求的金字塔模型，每次只看到金字塔的一个侧面，然后再换到另一个侧面
二、常见的需求收集方法
2.1 启发式评估
2.2 用户访谈（需求调研）
2.3 数据分析
2.4 研讨会
2.5 竞品分析
2.6 实际观察
三、需求分析
需求分析，是经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。需求没分析透彻可能会导致南辕北辙，修复成本被层层放大。下图是各阶段的需求修复成本示例：
3.1 需求分析方法：5W1H方法
1、用户识别（Who）：该需求的使用角色是谁？需求满足的是不是我们的目标用户？
2、使用场景（Where/When）：需求的使用场景是什么？什么时间使用？使用的频次？
3、问题分析（What/Why）：在业务场景下遇到什么问题？为什么要解决这些问题？
4、解决方案（How）：需求的解决方案是什么？包括页面UI、业务规则、第三方接口、异常处理、非功能需求（DFX）。
3.2 需求分析：非功能需求（DFX）
3.3 需求文档
需求分析后需要输出需求文档，即“功能需求说明书” （FRS，Functional Requirement Specification ），并与用户确认。
3.4 需求分析：需求分析输出的质量准则
3.5 需求排序
1、KANO模型法：基本型需求 > 期望型需求 > 兴奋型需求
2、矩阵分析法：重要且紧急 > 重要不紧急 > 紧急不重要 > 不重要也不紧急
3、经济收益法：经济收益高且紧迫的功能需求 ＞ 经济收益高但不紧迫的功能需求 ＞ 紧迫但经济收益不高的功能需求 ＞ 不紧迫且经济收益不高的功能需求
4、前/后置需求分析法：前置需求的优先级 > 后置需求的优先级
5、二八原则：满足核心用户的需求优先，先做能够满足80%用户的需求，边缘用户的需求往后排