需求文档俗称 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.要深刻的理解撰写文档的目的。
写文档的目的在于把事情说清楚，且有记录，可传阅，文档并不能生出花儿来！现在我想告诉大家，把问题与想法表述清楚才是王道，要占多少比例，花多少时间，格式正确与否，都取决于你要怎么把问题讲清楚。
网友评论