对于软件开发团队而言，软件开发的全过程是：做什么 -> 怎么做 -> 做 -> 成果检验 -> 交付部署；其中，“做什么”对应的是需求分析过程，“怎么做”对应于软件架构设计过程，“做”对应于开发过程，“成果检验”对应于测试，部署由运维团队执行后，如果达到用户的要求，则软件上线后进入软件的运行生命周期。
而在实际的软件项目开发中，“做什么”，“怎么做”和“做”是紧密结合在一起的，“做”，“成果检验”和“交付部署”通常也会是一个持续交付过程，“成果检验”的内容会受到“做什么”的影响，开展“做什么”阶段的时候，也要考虑到如何部署和交付。所以软件开发的全过程，都是紧密结合在一起的，如果刻意划分为独立的几个阶段，忽视其作为一个整理的综合影响，每个环节的实施过程必然会遇到因上一阶段考虑不周全带来的问题，从而影响整体开发效率。
今天，我们首先来谈一下软件项目中，需求究竟该怎么分析？
正确的需求分析决定了我们产品的方向，需求分析搞错了，做再多都是浪费。只有方向对了你才能走出迷途，方向错了，你只能迷失！基于此，我们的需求分析可分为两个阶段，第一个阶段是收集需求，第二个阶段是处理需求。
收集需求
需求的来源有很多，需求的处理方式也不尽相同。有效的收集需求，将收集到的需求去伪存真，是产品设计环节中最重要的一环，如同大厦的地基，地基不坚实，大楼是盖不起来的。而且我们在收集到需求时，要第一时间与用户交流沟通，尽量走到用户中去了解他们的想法，深入了解目标用户在真实环境下的感受，尽可能地挖掘用户的原始需求，充分了解用户真实场景，才能真正更好地服务用户，打造出他所想要的产品。
1、还原场景
如果只是单独看用户提出的需求，你很难分析到用户的真实需求，就像有些英语单词一样，你必须放到那个语境下面去了解，才能找到用户背后真实目的。
我们可以从以下场景进行分析：
基于什么环境：地铁/办公室/室内/公共场合/走路/夜晚/户外…深入情景周围的细节中去。
基于什么用户：具备什么特征，比如身份、收入、区域…
基于什么行为：行为或操作流程，比如购物流程、操作习惯、行为认知…
场景分析也就是需要考虑具体什么环境（时间、地点、情境）什么类型用户的什么动机，想达到什么目标，以及人与人的关系。如实地分析记录下来，如果偏差或缺乏信息，之后的分析就会有所偏差。
2、多问几个为什么
用户需求的传递过程中总是存在着无法完全理解吸收的问题，导致所收集的需求不一定就是用户的真实需求，这时你需要做的是找到需求的提出人，多问几个为什么。这个需求提出人可能是用户，也可能是运营，也可能是技术，你多问几个为什么的时候，也就能发觉用户背后的需求。
3、数据分析
数据是客观反映产品的重要指数，也是收集需求的重要来源，前期收集的数据需要是可靠、客观的，而且数据是零散的，在进行数据分析前一定要有明确的中心，划定一个界限，收集同一个框架内的数，同时单独的数据是死的，有对比的数据才有意义。为了避免主观意识的影响，同一份数据可参考其他人员的分析结果。
4、多和别人沟通/头脑风暴
一个人的力量是有限的，当我们吃不准的这个用户需求的时候，可以把这个需求拿出来和用户讨论一下，进行头脑风暴一下，人多力量大么，当我们吃不准一个需求的时候，大家都认为的那个结果就是需求分析的结果。
处理需求
处理需求的阶段，也是产品经理将需求进行筛选，梳理业务流程，设计产品架构的阶段。
1.需求筛选、分类
尽管我们保持严谨的态度收集大量的需求，其中还是有很多需求是“伪需求”，甚至是不合理的，我们第一步就需要将这些需求进行“清洗”，择优去重、去伪存真。
2.设置优先级
一般来说，从需求类型来看，基本型需求>期望型需求>兴奋型需求；
从需求来源来看，战略性需求（用户提出）>功能性需求（核心功能）>业务性需求（拉活、存留）>体验性需求（提升用户体验）。需求优先级判断最常用的是用四象限法则去评定优先级，另外可以使用RICE评定方法，KANO模型等。
3.竞品分析
由于在这个阶段，产品经理不仅要定义目标用户、产品使用场景，还要确定核心功能，产品流程等等，因此通过竞品（如果有）来辅助处理需求是一种很有效的方法。
通过相似竞品的用户定位、功能反推竞品的需求，与自己的需求进行对比；将自己的需求代入竞品中，看流程是否符合逻辑；与竞品进行对比，分析需求的异同。
4.需求评审
在这个阶段之前，作为产品经理对于产品应该有了一个完整的模型，但仅仅是理论上的模型，确保UI、UE、前端开发、后台开发、测试参与，从产品开发流程的各个角度对需求进行拆解、分析。需求评审可以看作是产品开发的初始化或者预开发。
需求分析是基于用户沟通、背景认知、人性理解，层层还原一个需求本源的过程。我们对一个需求的还原程度越高越准，越有机会在后续产品设计给出合理的方案。