一.需求分析

1.用户：当想到一个功能，先不考虑如何实现，而是想谁会用；

2.场景：用户在什么情况下使用；

3.问题：用户在上述场景中，使用产品时会遇到哪些问题；

4.方案：用户现在使用方案是？

二.需求分类：

1.有效需求进一步分类就是：需讨论的需求、需开发的需求、已有功能支持的需求、bug fix（这里的 bug 可能是开发代码 bug、可能是产品流程 bug）

需讨论的需求：对于是否需要做不是很确定，需要跟相关人员讨论。

需开发的需求：需求强烈、跟当前规划一致、对短期目标/长期目标有助力、……

已有功能支持的需求：这个是需要反思的，一般出现这种情况说明要么是功能的可见性做的有问题，要么是引导做的有问题，要么是功能不太符合用户的认知模型。有一些需求是合理的要求就需要进行功能的优化，甚至重新确定方案。

bug fix：

fix 后能带来什么

不 fix 能导致什么

其中，确定开发的需求就能顺利的进入到需求池了。需求池字面上来讲就是管理需求的大池子，我觉得这形容词挺形象的。在这个大池子里，你需要对需求进行优先级的维护，方案的制定、补充、完善。

2.需求标签

基础体验类：体验上有问题了，这个一般是需要修改交互或者 UI，要求比较高的公司/产品可能还存在响应速度、流畅性等方面的优化

运营支持类：运营活动支持

功能优化类：产品流程上存在一些问题，导致转化率、响应率等指标过低

新需求类：嗯……就是新需求

数据分析类：埋点需求啊，或者一些公司有大数据部之类的部门还会存在，报表需求啊

3.需求优先级划分

首先需要搞清楚以下内容：

产品的长期/中期规划是怎样的

对于长期/中期规划的意义是什么，是为了达到什么目标

达到目的的 MVP 需要哪些功能

（1）产品未上线

基本型需求>>期望型需求>兴奋型需求

（2）免费型产品已经上线

用户需求重要性的判断标准=用户基数+使用次数+类别重要性（基本型、期望型、兴奋型）

用户需求重要度=功能使用用户百分比（用户使用率）*功能使用次数百分比（功能或内容使用率）*类别重要性百分比（期望型需求、兴奋型需求）（还需要考虑kano模型：重要性与紧急性）

（3）收费型产品

商业价值=投入+成本+收益（经济效益）

4，需求交付

需求交付包括需求文档、需求列表、产品结构图、业务流程图、页面流程图等内容

需求文档需求内容包括：

迭代记录：版本号、修改时间、改了啥、为啥改、修改人（谁知道需求中途会不会换人呢，前面的人挖了个坑，也好去追责啊对不对？）

人员职能（非必须）：产品、交互、UI、前端、后端、客户端（iOS Android） 分别是哪些小伙伴。大公司必备，特别是我们这种组织架构完全看不到的公司……

需求类型：不清楚的同学翻翻前面的标签哈

需求背景：你不说清楚这个，开发和设计心里绝对会怀疑做这个需求的意义。部分产品经理是不是觉得开发和设计的小伙伴不怎么配合你的工作啊？仔细想一下，自己在这部分的『忽悠』是不是不够到位…

需求目标

专业术语和缩写解释（非必须）

功能列表：这个就是一张大表了，需要包含 功能点名称、所在模块、使用场景描述、风险点（风险一定要提前暴露，引起大家的注意，大家能一起想办法规避）、备注（这个你就爱写啥写啥，觉得啥重要写啥）

流程图 及 逻辑图：这个不用多说吧……

文案：保持文案上的一致性

数据埋点（非必须）：哪些关键埋点是需要开发小伙伴帮你埋的呀，埋点名称、埋点内容，都需要写清楚