说在前面的话：上两篇文章讲了市场调研、竞品分析，肯定收集了一堆的需求，那么我们怎么去分析这些需求了？从哪些维度去分析？接下来这篇文章主要是说一下我个人对做需求分析的一些方法和步骤。
需求分析是整个项目计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。
需求分析的目标是把用户对待产品提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。
此外，软件的一些非功能性需求（如：软件性能、可靠性、响应时间、可扩展性等），软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。
上面这张基本就是讲大道理的，接下来这张图是我整篇文章的分析步骤：
首先我们来看下面一张图，看看需求的来源有哪些：
在通过上面的各种需求的收集，会收集一堆的需求，俗称需求池。在收集的过程中，记录需求大部分都是先拿笔记本记录，最后在汇总到电脑里面，所以会很分散，这个时候需要一张表格来规范所有的需求，做成一个列表。
示例如下：
列表字段：编号、需求分类、需求描述、场景描述、需求来源、提出时间、是否解决、优先级、备注。
文档说明：
（1）需求分类：一般需求可以划分为五类。
（2）场景描述：主要描述需求发生的场景。
（3）需求来源：主要是记录需求产生的方式。
（4）优先级：这个地方我用的是我司的优先级排列方式，P0最高、P4最低。这个地方可以灵活处理，换成自己公司的就可以了。
（5）备注：一般用于抒写，不解决的原因。和如果解决需要注意什么。
分析方法：需求分析自己分析需求的方法我没有写，因为网上有一堆讲这种自我分析需求的方法。
下面我在网上找到的一篇需求分析，感兴趣的可以点击看看，我文章只是讲述怎么让需求落地。
其他说明：
一般产品都会分为用户端与后台，所以在做Excel表格的时候，需要分为两个模块，分别列对应平台的需求。这样会让各个平台的需求清晰明了。开需求大会的时候，分平台的评审需求。
第二步：需求大会汇总完所有的需求到需求池，这个时候产品经理就需要组织需求大会了，邀请相关同事参会，讨论V1.0版本需要做哪些需求。
参会的人员：相关领导、项目经理、产品相关人士（产品汪、产品助理、产品专员）、研发leader、运营。
会议时长：2-4个小时。
会议记录：产品经理。
会议说明：
（1）这种需求大会，会针对每一个需求进行探讨，V1.0版本做与不做，所以会议时长一般会很长。产品经理需要对每一个讨论过的需求标记优先级，是否需要第一个版本实现做备注，延后处理的需求，需要标明延后原因等等。一般都是在我之前列表的需求池列表的后面做处理。
（2）针对需求一般会围绕以下几个维度进行讨论：
会议结束，产品经理需要做的事情，就是把需求池列表的需求进行过滤，把V1.0版本初步需要做的需求进行进行一个需求的整理，单独做成V1.0需求列表。
我简单做了一个需求列表的Excel的表格，仅供参考：
列表字段：编号、所属模块、子模块、需求描述、场景描述、优先级、备注。
备注说明：分别把前端和后台的需求分开列。这样展示会更清晰明了。
第四步：V1.0需求确认会汇总完所有的V1.0需求，又是产品经理主持会议的时候到了，这次的会议室确定上一次会议的确定下来的版本需求。
参会的人员：相关领导、项目经理、产品相关人士（产品汪、产品助理、产品专员）。
会议时长：1个小时左右。
（1）确认需求的过程中一般又会爆发新的一轮需求的讨论，别问为什么。（上次讨论需求的脑细胞已经死亡了，新的脑细胞又会有新的意见。）
（2）产品需要记录这次会议上针对需求提出来的一些讨论结果的记录。
第五步：最终需求表有些公司需求的确认会，需要经过很多次的需求会议，才会确认下来。本文只是理想化的做了2次，但是不管经历了几次需求确认会，都会走到最终定下来的这一稿。
我简单做了一个最终需求列表的一个Excel表格，表格如下：
列表字段：编号、所属模块、子模块、需求描述、场景描述、优先级、产品负责人、完成时间、预计用时、对应开发人员、完成情况。
备注说明：
题外话：研发leader拿到这个需求列表后，召开研发的会议，然后分配任务给对应的开发人员，就可以直接在页面天对应的天数、开发人员了。
结尾本篇文章讲解了产品从汇总需求池到需求确认的整个过程，接下来的一篇文章，会全面讲解我们在做0到1的产品需要输出哪些产物。
联系客服
