产品需求文档(PRD)的写作方法之笔记一

1、写前准备(思维导图)：

http://www.woshipm.com/?p=80070

1.在写之前，请先很区分清楚什么是MRD文档（市场需求文档），BRD文档（商业需求文档），什么是PRD文档（产品需求文档）

可查阅知乎https://www.zhihu.com/question/19655491

2.规划产品的思维导图（信息结构图）

　　在写作这份文档前，我们需要先做一些准备，把BRD、MRD的相关需求消化并融合规划出产品的结构图。因为这些准备工作是属于思维类的，所以我推荐使用思维导图软件(MindManager)进行规划工作。

　　规划产品的第一步就是梳理出产品的信息结构，有了信息结构我们才能继续往下规划产品结构，并且信息结构是服务端技术人员创建数据库的依据，是数据结构的辅助文件。

　　信息结构图是产品层面的理解，如果要入库这些信息，还需要进行数据结构的讨论。一条信息的存储有很多附加属性，具体是存成字段还是数据表，还是说存在中间表或者关联表，这些都需要在完成PRD文档后和数据库技术人员共同讨论。讨论时除了展示信息结构图，还要讲解产品原型和功能需求，以便数据库技术人员了解产品意图，方便他们做数据库规划时考虑到以后的扩展。

　　信息结构图是我们将概念想法形成结构化的第一步，也是我们接下来几步工作的辅助文件，同时在接下来的几步工作中，我们还会不断的完善信息的结构。

2、梳理需求(产品结构图和用户流程图)：

http://www.woshipm.com/?p=80078

当对产品的信息结构了解后，规整脑海中的产品需求，让想法更加结构化，梳理产品的需求。

我们首先要罗列出产品的频道及页面(产品结构图)，其次再基于产品结构图梳理出频道及页面中的功能，并延伸构建出用户的操作流程(用户流程图)。

以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。

PRD文档写前准备就是让我们先通过思维导图梳理思路，明白产品有多少个频道、有多少个页面、页面有多少个功能模块、功能模块有多少个元素，逐步的将脑海里的想法明确梳理成结构。

虽然已经明确了产品的结构，但是这样的思维导图对于设计与技术人员依旧是抽象的，他们仍然看不懂，同时对于产品经理自己来说，这样的结构图也是没有经过推演的，具体是否符合产品逻辑，是否符合用户体验，都是没有深思过的，因此我们接下来就要进行原型设计，开始具体的考虑结构方案的可行性。

3、原型设计(手绘原型,灰模原型,交互原型)：

http://www.woshipm.com/?p=80086

当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。

首先我建议通过手绘的形式快速在草纸上绘制出产品的原型，推演和讨论方案的可行性，当有一定的进展之后，我们再通过软件工具进行更深入的设计。移动产品可以考虑灰模原型，网站产品可以考虑交互原型，对于这两种原型方式，无论是移动产品还是网站产品都可以使用，具体取得于你的个人习惯和团队要求。

对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案的可行性，同时也是为了避免产品宣讲时，抽象的语言描述导致听众理解困难和理解偏差。

原型设计是将结构化的需求进行框架化，因此原型也被称为线框图，具体的表现手法有很多种，相关的辅助软件也有很多，例如：Axure RP、Balsamiq Mockups、UIDesigner等等。

原型设计的表现手法主要有三种：手绘原型、灰模原型、交互原型。

4、撰写文档(PRD文档)：

http://www.woshipm.com/?p=80091

当我们通过以上三个大的步骤之后，我们就已经非常清晰产品的需求了，一般情况下，通过原型加描述的方式就已经完成了PRD文档的目的(很多产品经理直接使用Axure制作PRD)。

当然也会有一些个人或团队的要求不一样，对PRD文档有特定的规范标准，这类情况可能是需要存档归类。无论什么样的规范标准，PRD文档的目的都是相近的，因此功能描述的方式也是相似的，所以在这里我分享了三种撰写PRD文档的方式。

5、用例文档(UML用例图、流程图)：

http://www.woshipm.com/?p=80096

《产品需求文档(PRD)的写作方法》的补充文章，主要讲解PRD文档中的重要辅助文档“用例文档”。

　　用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他是PRD中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。

　　用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。

　　用例文档中有两个关联文件，分别是用例图和流程图。

　　用例图是UML的一种类图表现方式，是从用户角度描述产品功能，并指出该用户在产品各功能中的操作权限。

　　流程图是通过线框图形的方式描述产品功能的处理过程，主要是描述功能的执行顺序、分支和循环的逻辑。

一份完整的用例文档分别是由以下三点内容组成，其中第3点的“用例”是描述功能逻辑的部分，根据功能的多少决定有多少个用例。

用例文档的大概组成部分如下：
　　1、修改记录：每次修改的备注记录，同PRD文档。
　　2、角色介绍：描述参与系统中的各个角色
　　3、用例：同下方步骤的第4步，其中第3步中的流程图是直接插入到第4步的流程图表格项中的。

用例文档的模板格式如同以上三点内容，通过Word文档绘制表格，在表格中撰写用例描述，表格的格式和样式参考以下示例图。

1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。（如下图）

2、第二步是以用例图的方式注明角色在前后端的用例关系。（如下图）

3、第三步是以流程图的方式注明角色在各个功能环节的活动过程。（如下图：以活动报名为示例）

4、第四步则是以用例文档的方式将以上三步整合到一起，并撰写各个功能环节的用例描述。（如下图）

表格说明：
4.1、用例名：此功能环节的名称
4.2、用例编号：在此产品中该用例的编号
4.3、行为角色：参与或操作(执行)该功能的角色
4.4、简要说明：用最少的文字描述一下该用例的需求
4.5、前置条件：参与或操作(执行)此功能的前提条件
4.6、后置条件：执行完毕后的结果条件
4.7、流程图：该功能的角色活动过程(处理过程)图（第三步中的图）