很多朋友说，产品需求文档怎么写？很多公司的产品需求文档要求各不相同，但也是大同小异，其实就是说清楚： 

基于什么样的背景，我们要做什么事情，

满足什么用户哪一个需求？

需求分解出来，产品的逻辑如何？

交互图如何？

设计图如何？

哪些功能点？

哪些细节？

实现进度如何？

产品健康运转的闭环如何形成？

文档，就怕写复杂了，连开发都看不明白的文档，必然不是一份好文档。

抽象了一份文档出来，供大家参考，根据各自公司的具体情况进行修订完善吧。

1. 文档历史

修订日期 修订内容 修订版本 修订人 创建：立项成功后创建需求文档 V1.0 开发排期后修订项目进度； V1.1 修订交互/视觉设计稿后需要修订文档 V1.2 修订有需求变动的时候需要修订文档，同时周知文档关系人，将修订的内容明确标识 V1.3

2.目录

1. 文档历史

2. 目录

3. 项目说明

3.1 项目背景

3.2 项目目标

3.3 项目概述

3.4 项目排期

4. 项目策划

4.1 产品逻辑图

4.2 功能与特性简述列表

4.3 交互/视觉设计

4.3 需求详细描述

5. 数据需求

5.1 数据建设：考核评价指标

5.2 指标定义与计算逻辑

5.3 数据报表

6. 客服文档

7. 运营方案

3. 项目说明

3.1 项目背景

项目需求不是产品经理拍脑袋想出来的，一定有个出处，例如，

l  用户需求驱动，解决哪一种用户什么样的问题？

l  市场竞争驱动，有了什么新的变化？

l  技术驱动，有什么技术创新可以应用在产品上，让解决问题的效率更高？速度更快？

案例：目前繁琐的注册流程导致用户注册成功率仅为20%，本项目主要是优化注册流程，提升注册成功率。

3.2 项目目标

由背景推导出的目标，符合SMART原则，简明扼要，一般通过数据衡量，目标通常是贯穿整个需求的线索，整个需求都应该是围绕目标在进行的，包括优先级的排列，也是综合考虑需求点能实现目标的程度、效率、紧迫性、成本控制等各方面因素。

目标举例，2013年8月10日完成注册流程优化，提升注册成功率10个百分点，从原有的20%提升到30%。

3.3 项目概述

将涉及到的页面做个列表，可以帮助评估设计、开发需求所耗费的时间

文档位置 页面名称 页面数量 所需工作 4.3.1 注册起始页面 3 页面设计+页面制作 4.3.2 注册成功页面 页面设计+页面制作 4.3.3 注册失败页面 页面设计+页面制作

3.4 项目排期

项目进度时间表，也是一个不断推动、修订的过程，协调各方资源，尽量给出靠谱的时间进度，并推动按期完成需求。一般用表格形式，包括字段：项目名称、项目内容、负责人、开始日期、完成日期。

4. 项目策划

4.1 产品逻辑图

按照逻辑线索理出逻辑图，便于阅读者组织对该项目的理解思路，涉及流程的必须给出流程图，一般用VISO绘制。

4.2 功能与特性简述列表

产品需求的核心部分，详细的功能列表对需求评审、开发时间评估、测试用例撰写具有重要价值，列表可以尽量详细，一个功能/特性点都可以单独一项，基本可以和测试用例对应，同时，需要给出优先级和测试重点。

1．功能列表：简洁概要的描述要实现的功能点， 就是让用户做什么，可以按照用户场景和产品流程进行描述，第一步、第二步、第三步……成功、失败。

2．具体描述：给出在某场景下，用户的具体操作实现过程。例如用户身份变化对应的不同产品表现形态、用户每一步操作需要对应的产品功能、产品的数值变化，数值极端情况。尽可能的考虑全面，细化，具体，可操作，可读性强。

3．优先级：最高级，本期必须实现。中级优先，二期需求，视第一期产品表现后决定做哪些优化。低优先级，本期可以不实现或延后实现。

4. 测试重点：从测试的角度，给出具体描述的各个场景下的一些需要关注的主要测试点。一些细节可以在需求详细描述中说明，可以写上详见第几点详细描述，这里只需要给出一些方向即可。

4.3 交互/视觉设计

这个部分，一般会有多个修订稿，注意文档的保存与更新。修订文档的时候应该补充好交互/视觉设计稿，便于其他阅览者清晰还原需求所在的产品场景，文档描述所见和开发出的产品所得相统一。

4.3 需求详细描述

每个产品功能、特性的详细描述，可以和前文的项目概述一一对应，也是对功能与特性概述的详细说明，一般

例如一个注册功能详细描述：

(1)  功能或特性名称：用户注册流程

(2)  需求描述：一句话描述，简化原有注册流程；

(3)  使用者：什么样的用户会使用这个功能；

(4)  前置需求：这个需求的前置需求如何？基于前面的需求，进行功能的进一步开发，说明前一个需求对该需求的影响或者创造的条件；

(5)  后置需求：该需求完成后，会对哪些需求产生影响；例如用户注册后成功后的用户教育引导需求、注册填写信息对构建用户关系链的影响；

(6)  主流程描述与业务规则：用户的主要操作流程，及其每个步骤的规则说明。例如，对展示的内容进行描述，如果有可操作部分，需要单独列出：操作前后的状态，操作后的反馈，链接到具体位置等；如果涉及数值等级，对不同数值等级，不同的状态，不同的操作反馈

举个例子：对注册流程的规则描述：

A.   注册页面打开，鼠标焦点定位在注明名输入框；支持TAB键进行输入框切换；

B.   每个输入框的状态：输入前、输入过程、输入结束；

C.   输入类型：字符、数值；字母、汉字、数字、符号；非法字符；

D.   敏感词问题；输入长度；是否必填；是否联想；是否记忆；是否有默认值？如何对齐？过长后如何显示？

E.   输入后多久给出判断？

F.   一个IP每天可以注册多少个帐号？

G.   是否可以采用OPENID的形式注册？

H.   是否需要邮箱、手机进行注册成功验证？

I.   一个手机或者邮箱是否是唯一绑定关系？

J.   注册成功后，跳转到用户引导页面；

K.   注册失败，引导重新注册；

(7)  产品性能要求：能达到一定的性能指标，比如速度快、软件稳定性、并发使用上限

(8)其他补充说明（视具体情况选择是否需要）

A.   安全需求：能够抵挡黑客攻击，保证用户的数据不会丢失，防止黑客刷等级，暴力注册等；

B.   兼容性需求：如浏览器兼容性、系统版本兼容性；

C.   财务需求：如一定预算，需要提前找财务审批，产品收入与财务的对接

D.   法律需求：需要法务部门协助的需求，如何同审核、用户协议、版权

5. 数据需求

5.1 数据建设：考核评价指标

[考核评价指标是评估产品目标的重要标准，在项目策划的前期就必须制订]

l 访问量

l 转化率

l 留存率

l 用户活跃天

l 产品收入

l 任务、活动完成量、质量

5.2 指标定义与计算逻辑

数据指标的含义是什么，开发上报哪些数据字段，可以通过公式计算出这些指标；

5.3 数据报表

用Excel画出需要查看的报表；如果需要统计图的，说明需要什么类别的图形，柱状图、折线图、饼图等等。

6. 客服文档

让客服了解产品，周知客服本产品有可能遇到的用户问题，给出常见问题解答。

7. 运营方案

需求完成后的功能点说明或描述，用户周知推广。

产品不只是上线，后期的运营需要提前考虑。在产品策划阶段或许很难有一个详细的运营方案，但至少有产品成长运转的运营保障，例如从产品生命周期考虑运营方案，在启动期、成长期、成熟期等各个阶段的运营对策；在启动期，第一批种子用户从哪里来？如何保证产品的灰度放量到健康成长的正循环养成？需要提供哪些运营资源的支持？

一般的运营，都会考虑：拉新、留存、活跃、回流等运营策略。有的只是一个小功能优化，这里可以省略。

END.

一个需求文档的框架，供大家参考吧，各自完善。如果有什么问题或者建议可以给我留言，尤其是开发同学，可以聊聊自己是怎么看待产品需求文档的。