产品的需求文档撰写方式

需求文档俗称 MRD,PRD,BRD,有些已经开始用Axure的方式表现，所有使用什么工具表现不重要，重要的是你得有这三种文档。在做新产品时，都需要经过MRD,PRD,BRD阶段，只有BRD评审通过了，项目才会立项。

这里简单介绍一下三种需求文档的内容：

BRD：Business Requirement Document，市场环境分析， 我们要做什么，要解决什么问题，  这问题是迫切的问题吗？这个问题是强烈的问题吗？这个问题出现的频率高不高？如果要这么做，我们的优势在哪里？

•    技术优势

•    经验优势

•    资源优势

•    ……

–    得到可行的结论

MRD：Market Requirement Document，市场需求文档，最完善的产品诞生分析描述文档，以后的一段时间，产品的各种衍伸文档、产品依据、团队判断，都有可能参考MRD文档， 产品参与成员了需要了解产品的各种背景、数据、方法依据，MRD就是经过一系列的分析后，拿出一套你认为最合理的干某个事情的方法与指导实施的文档。

PRD：产品需求文档(Product Requirement Document，PRD)的英文简称 PRD文档向上是对MRD内容的继承与发展，向下则是要把MRD文档里面的各种理论要求技术化，向研发部门与设计部门说明产品的的功能和性能要求。PRD文档是产品文档中最底层最细致的文档，所以写作的时候，需要细致耐心。

本章只针对于PRD的撰写，那么如何才算写好一份PRD需求文档呢？

1、结构：逻辑清晰，层次分明

2、背景：需求背景描述清楚，项目背景与需求分析

谁提的需求？什么场景？遇到什么问题？

简要描述分析过程：决策过程和依据是什么？解决方案是什么？

有没有相关的背景数据资料？

明确本次需求：用户，场景，需求，解决方案是什么？

3、本次需求的目的及功能列表

这个需求整体是什么样的，是否要分阶段？还是需求文档里面所描述的需求都要实现？

本次需求需要做哪些，前后关系是什么？一定要区分出来轻重缓急，先做优先级高的需求，后做优先级低的需求。

本次需求的功能清单是什么？

涉及的功能或页面是什么？

4、流程图：业务流程，页面流程都有，流程与所处的产品模块关系

业务逻辑图、业务流程图、页面流程图，尽可能都要有，而且简洁完整无残缺。

5、具体功能详细描述

交互设计图，原型图

6、简要的测试用例

关键的用例是什么？重点关注点，错误提示表等。

7、目标：考核指标清晰

本次需要统计哪些指标，怎么计算，怎么埋点？

常见PRD文档包含内容：

文档说明

产品说明

全局功能说明

详细功能说明

文档说明

–    产品版本号 （1.0）

版本号 （ 1.0.0）

重大调整升级

产品结构功能等有调整

子版本号（ 1.1.0 ）

修正版本号（ 1.0.1）

局部小范围优化与Bug修复

一般是不动功能性的东西

历史修订

编号

版本号

修订章节

修订原因

修订日期

修订人

历史修订的作用

•    对修改前后进行比较

•    有利于维护和管理PRD

•    修订人

•    修订日期

•    方便查阅，可以只看修订部分

最后有几句话需要说一下，

产品需求文档没有统一答案，但是往往新入行的产品经理都想找个模板往里套，似乎是找到了一个标准答案，但是殊不知，他们这样做很有可能是错的，因为产品经理这个工作就是具体问题具体分析的工作，没有所谓的标准答案，即便是业内盛传的基本产品经理书籍，其实也是作者站在自己的工作维度撰写的，有明显的个人工作环境特色，也不是什么标准答案。也写文档也是，要具体的公司，具体对待。

2.要深刻的理解撰写文档的目的。

写文档的目的在于把事情说清楚，且有记录，可传阅，文档并不能生出花儿来！现在我想告诉大家，把问题与想法表述清楚才是王道，要占多少比例，花多少时间，格式正确与否，都取决于你要怎么把问题讲清楚。