需求是整个产品的源头，需求分析的结果决定了产品的成败。如果没有正确的把握客户需求，可能会一步错，步步错。
什么是需求？
我们日常在项目中，经常会听到“需求”这个词，比如说：
- 项目经理对产品经理说：用户给我们提了一个需求，想要一个给三个孩子玩的秋千，你分析一下；
- 产品经理对架构师说：我们现在有一个需求，在树上栓两绳子，再吊一块板子，你做一下设计。
很明显，这两个需求的意思不一样，前面这个需求是用户需求，后面这个需求是产品需求。
- 用户需求是由用户提出来的，期望满足自身一定需要的要求，例如用户说：“想要一个给三个孩子玩的秋千。”这种原始的用户需求通常是不能直接做成产品的，需要对其进行分析提炼，最终形成产品需求。
- 产品需求就是在分析提炼用户真实需求后，提出的符合产品定位的解决方案。就像上面“在树上栓两绳子，再吊一块板子”，就是产品经理针对用户需求提出的解决方案。
需求分析是要分析什么
其实对用户需求的分析，不是一个动作，而是一个过程。需求分析，就是对用户需求进行提炼分析，最终形成产品需求的过程。
而针对每个用户需求的需求分析过程，需要讲过三个步骤
第一步：挖掘真实需求
大部分用户提的需求，都不见得是真实的需求，需要透过现象看本质，去挖掘其背后真实的需求。就像福特汽车创始人亨利福特说过的：如果我最初是问消费者他们想要什么，他们应该是会告诉我，“要一辆更快的马车。
这里“要一辆更快的马车”就是一个典型的用户需求，但这并非是用户的真实需求，用户的真实需求，需要通过分析才能得到。
要分析用户的真实需求，可以从三个角度入手：
- 目标用户：用户不同，诉求也不一样
- 使用场景：使用场景不一样，解决方案也不一样
- 想要解决的问题：用户背后想要解决的问题是什么
我们假设目标用户是普通乘客，使用场景是日常出行，那么用户想要解决的问题其实并不简单是“要一辆更快的马车”，想要更快的马车只是用户自己能想到的解决方案，而他想解决的问题是“更快更舒适的出行方式”。
而现实项目中，大多数人需求分析的不正确，就是因为没有挖掘出用户的真实需求。
我们再看之前的秋千项目，目标用户是三个孩子，使用场景是一起户外玩耍，想解决的问题其实是能有一起玩的娱乐设施。
第二步：提出解决方案
我们知道了目标用户，其使用场景和想要解决的问题，就可以结合产品定位，提出相应的解决方案。
比如针对想要“更快更舒适的出行方式”日常出行的乘客，我们就可以提出汽车的解决方案，而不一定要局限于马车，汽车能更好的满足用户需求。
针对三个孩子想有一个在户外一起玩的娱乐设施这个需求，我们可以提供一个轮胎式的秋千，就可以很好的满足他们的需求，我们甚至可以建一个小型游乐园。
第三步：筛选和验证方案
在提出方案后，我们需要对方案进行筛选，比如对于秋千项目，建小型游乐园的方案虽然能满足需求，但是成本太高，需要排除掉。
在选好方案后，还需要对方案进行验证，以确保方案能解决用户需求。
在传统瀑布模型中，选定方案中，会写成产品设计文档，走相应的评审流程，评审完成后再进行设计、开发和测试，测试完成后会让客户再进行验收。而敏捷开发，在整个开发过程中，每个迭代或者关键的里程碑，也一样需要客户进行验收。
通过以上三步，就可以对用户需求进行提炼分析，最终形成产品需求。
所以在需求分析过程中，分析的就是一个个用户的需求，找出背后的真实诉求，再有针对性的提出解决方案
对于解决方案，要进行筛选和验证，有些不可行的用户需求不会变成产品需求，可行的用户需求会按照优先级进行实施阶段，最终变成产品
怎样做需求分析？
上面介绍了对单个用户需求的分析，主要经过三个步骤：
- 第一步：挖掘真实需求；
- 第二步：提出解决方案；
- 第三步：筛选和验证方案。
而软件项目的用户需求，从来就不是单一的，而是一系列需求，所以对于软件项目的需求分析，还需要增加收集整理的步骤。整个过程是迭代进行的，如下所示：
- 收集需求：对用户需求进行收集整理；
- 分析需求：对需求进行分析，挖掘用户真实需求；
- 需求评估：筛选过滤掉不可行的需求；
- 需求设计：针对用户需求提出解决方案，设计成产品方案；
- 验证需求：验证方案是否可行。
收集用户需求有很多方法，这里列举部分：
- 头脑风暴：就是大家一起开会头脑风暴讨论；
- 用户调研：通过调查问卷或者访谈，通过问用户一些问题收集反馈；
- 竞品分析：通过分析其他同类产品的功能获得需求；
- 快速原型：通过原型来收集反馈，收集确认需求。
收集了需求，就要分析用户的真实需求，这是最难的部分，也是最体现产品经理需求分析水平的地方。用户需求背后的真实需求有三个层次：
- 表层需求：用户对解决问题的期望，例如马车更快；
- 深层需求：用户的深层次动机，诉求产生的原因，例如乘客对出行速度的要求；
- 底层需求：人性本能的需求，例如对安全感对舒适的追求。
要分析好用户需求背后的真实需求，就是要结合“目标用户”和“使用场景”，按照上面三个层次去思考。
需求收集分析完了后，还需要进一步评估，以决定做还是不做，优先级如何，先做哪些再做哪些。需求评估考虑的因素有：
- 可行性：技术能否实现；
- 成本：人力成本、时间成本；
- 商业风险和收益：有没有商业上的风险，收益是否合理；
- 紧急性与重要性：是不是用户迫切的需求。
如果确定可行，还需要评估其优先级。评估优先级一个简单的方案就是用“紧急重要四象限”的方法来区分：
复杂一点的有 KANO 模型，如下图所示：
- 红色曲线，是用户认为必须要有的功能；
- 绿色曲线，就是用户明确提出的需求；
- 黄色曲线，属于兴奋型需求，就是用户自己没想到，超出预期的功能。
在分析和评估完需求后，还需要提出解决方案，也就是对需求进行设计，做出来有效的产品设计方案。
- 在需求设计的时候，可以用草图、原型设计工具、界面设计工具进行设计。
- 在需求设计阶段，可以参考其他成熟的产品。
在需求设计好后，还需要进行验证，看解决方案是否能满足用户的需求。
- 对需求的验证方式其实是贯穿整个软件项目生命周期的，在需求分析阶段，会反复验证确认设计好的需求是否满足用户的真实需求，比如各种设计评审
- 产品开发完成之后，也需要有需求的验收，以确保开发出来的软件产生是客户想要的，满足客户需求的
- 现在很多互联网产品，还有一种基于数据的验证需求方式，也就是AB测试：
- 设计好一个功能上线后，并不直接让所有用户使用，而是先给一小部分用户使用，然后分析数据，看使用这个功能的用户群和不使用这个功能的用户群，在营收、访问量、活跃度等关键数据上是更好还是更坏。
- 如果好，就加大比例，如果数据不好，可能就会调整甚至取消这个功能。
需求分析 VS UML
不建议把需求分析和UML放一起理解，UML是一种用来做设计时的手段，是偏向对已经设计好的产品需求进行建模分析的。
-
收集需求通常是指的用户原始需求，产品经理需要进一步分析处理才能变成最终的产品需求。
-
用例模型一般是针对已经设计好的产品需求，对用例进行建模。
原型设计只是对产品设计的一种有效手段，但也不是唯一的手段，比如有的程序员，自己在脑子里就能构建出产品的模型，然后代码实现，都不需要借助原型。
总结
- 需求分析，就是一个将用户需求变成产品需求的过程。要做好用户需求的分析，需要找出来隐藏在用户需求背后的真实需求，还要针对用户的真实需求提出解决方案，最终验证方案是否能满足用户需求
- 需求是整个产品的源头，很多软件项目失败的原因就是因为没有做好需求分析，软件中很多浪费也来源与需求没想清楚导致的返工。做好需求分析对软件项目来说非常重要
- 要做好软件项目的需求分析，需要做好需求的收集整理工作，然后对收集好的需求进行科学的分析，评估是不是可行以及划分优先级，对可行的需求项进行设计，最后还要验证设计出的结果是不是满足需求