PRD： Product Requirement Document 产品需求文档
PRD主要用于产品设计和开发使用，阅读这份文档的人大多是设计（更多依赖于原型进行交互设计）和技术人员（主要读者，主要关注界面、功能、交互、元素等内容），PRD文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。
PRD是一份直入主题的功能说明文档，写之前，根据BRD和MRD的相关需求规划出产品的结构图（思维导图，用Xmind、MindManager）。规划产品的第一步是梳理出产品的信息结构（服务端技术人员创建数据库的依据，是数据结构的辅助文件）。信息结构的考虑有面向前端的，也有面向后端的。在完成PRD文档需要向数据库技术人员展示信息结构图+讲解产品原型和功能需求，便于他们做数据库规划时考虑到以后的扩展。
产品需求文档的写作(二) – 梳理需求(产品结构图和用户流程图)
根据信息结构，规划产品的功能需求，绘制产品结构图和用户流程图。
概念解释：
1、频道：某一个同性质的功能或内容的共同载体，也可称为功能或内容的类别
2、子频道：某频道下细分的另一类别
3、页面：单个或附属某个频道或分类下的界面
4、模块：页面中多个元素组成的一个区域内容，可以有一个或多个，也可以循环出现(例如:文章列表)
5、模块元素：模块中的元素内容，以文章列表举例：文章标题、文章摘要、文章发布时间，这些都是元素，都是组成模块的内容，同时他们也是可以循环出现的。元素的类型可以是：文字、图片、链接等等
前端面向浏览者的用户流程：先规划频道，再从用户视角一步步模拟操作，完善产品的结构导图，即用户流程图。目的：梳理产品逻辑。比如登陆的流程图（使用流程）。
但如果规划的是CMS、BBS之类的平台产品，框架式开发，功能与模板独立，从后台入手模拟管理员的流程。
产品需求文档的写作(三) – 原型设计(手绘原型,灰模原型,交互原型)
用原型（线框图）设计来具体考虑结构方案的可行性，预估项目要花多少人力物力。
原型设计的表现手法主要有三种：手绘原型（在初期验证想法时非常高效，也方便讨论和重构，适合敏捷开发时快速出原型）、灰模原型（软件：PhotoShop和FireWorks，适用于宣讲，常用于移动互联网产品的设计，移动互联网产品的设计通常是灰模原型加交互文档组合成PRD文档）、交互原型（Axure RP）也叫产品Demo版（一般交互原型是产品经理和交互设计师共同讨论确定，然后由交互设计师制作，但大多数公司没有这个职位，或者把视觉设计师叫做交互设计师，所以最终还是产品经历来画产品原型）。网站产品可以考虑交互原型。
具体选择哪种原型设计方法，取决于你的产品需求和团队要求。只要对方能够听懂看懂，就可以。
PRD文档没有标准的规范，也没有统一的模板，取决于个人习惯和团队要求。虽然PRD文档没有标准的规范，但文件标识和修改记录是必不可少的。文档正式发布或交给团队其他成员后，一旦有了修改，为了文档的同步，我们就需要标注出文档的修改内容，备注修改记录。关于文件标识和修改记录，大家的格式都大同小异(如下图)。
PRD文档形式：Word、图片、交互原型
一、Word（传统上的）
主要有四个部分组成(具体视你的产品要求进行划分)，分别是：结构图、全局说明、频道功能、效果图。（牢牢记得读者是技术人员，不要讲废话）
1、结构图：
1.1、信息结构图：主要是辅助服务端技术人员创建或调整数据结构的参考文件
1.2、产品结构图：主要是辅助设计和技术开发人员了解产品的全局结构，他和用户流程图不一样，产品结构图只是罗列出产品的频道和页面。
2、全局说明：主要讲解产品的全局性功能的说明，例如网站产品的页面编码、用户角色，移动产品的缓存机制、下载机制，这类全局性功能的说明。这里我举一个移动产品的“状态维持与恢复”的例子，示例如下：
状态的维持与恢复
当用户退出产品时（误操作、Home键、锁屏、自动关机），产品需要维持用户操作前的状态，当用户返回产品时仍可以恢复到之前状态，并继续使用。
维持状态包括流程操作、信息浏览、文本输入、文件下载。
锁屏状态时，如果用户在产品中有下载任务时，仍然保持下载。
3、频道功能：以频道为单位，页面为子项，分别描述产品的频道、页面及页面模块元素的功能需求(格式如下)：
示例格式
1、频道名：频道介绍及需求说明
2、页面1：页面介绍及需求说明
2.1、页面模块1：模块功能需求说明
2.1.1、页面模块1-元素1：功能说明
2.1.2、页面模块1-元素2：功能说明
2.2、页面模块2：模块功能需求说明
在撰写功能需求时，我们需要考虑用户的流程，例如一个“完成”按钮，我们需要描述他完成后，系统要不要给出反馈提示(反馈提示是什么样的形式反馈，内容显示成什么，有没有内容需要调取数据库)，或者要不要跳转页面(跳转到哪个页面，这个页面是其他频道页面，还是这个功能的子页面，如果是子页面就需要再描述这个子页面的模块及元素内容)。
4、效果图：效果图是由设计师完成的产品图，和实际开发完成的产品保真度一致。
二、图片
图片形式的PRD文档是基于效果图的说明文件，将传统Word形式的功能需求说明标注在效果图上，这种方式经常使用在移动互联网领域，实际上是图文形式的交互需求文件，只是在此基础上更深入的描述出功能需求。
对于图片形式的PRD文档，我们只需要另外再描述一下全局说明，其他频道页面的需求直接以图片形式展示，这种方式相对于Word文档的纯文字更加生动易读并且直观，因此有一些产品经理非常喜欢用这种方式代替Word形式的PRD文档。
三、交互原型（Axure RP）
直接在原型上标注说明功能需求。
无论你采用哪种方式产出需求文档，最终的目的都是为了方便团队成员理解产品的意图，因此哪种方法能够避免细节黑洞，高效完成产品的设计和研发，那么这种方法就是最有效的方法。
产品需求文档的写作(五) – 用例文档(UML用例图、流程图)
用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他是PRD中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。
用例文档中有两个关联文件，分别是用例图和流程图。用例图是UML的一种类图表现方式，是从用户角度描述产品功能，并指出该用户在产品各功能中的操作权限。流程图是通过线框图形的方式描述产品功能的处理过程，主要是描述功能的执行顺序、分支和循环的逻辑。
写用户文档的常用软件是Word，其中用例图和流程图的制作软件常用的是Visio，当然也有用Axure RP软件制作的，例如下面的第三步流程图就是用Axure RP制作的。
一份完整的用例文档分别是由以下三点内容组成，其中第3点的“用例”是描述功能逻辑的部分，根据功能的多少决定有多少个用例。
用例文档的大概组成部分如下：
1、修改记录：每次修改的备注记录，同PRD文档。
2、角色介绍：描述参与系统中的各个角色
3、用例：同下方步骤的第4步，其中第3步中的流程图是直接插入到第4步的流程图表格项中的。
用例文档的模板格式如同以上三点内容，通过Word文档绘制表格，在表格中撰写用例描述，表格的格式和样式参考以下示例图。
1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。（如下图）
2、第二步是以用例图的方式注明角色在前后端的用例关系。（如下图）
3、第三步是以流程图的方式注明角色在各个功能环节的活动过程。（如下图：以活动报名为示例）
4、第四步则是以用例文档的方式将以上三步整合到一起，并撰写各个功能环节的用例描述。（如下图）
表格说明：
4.1、用例名：此功能环节的名称
4.2、用例编号：在此产品中该用例的编号
比如在2016年3月份修改了一个页面功能，该页面编号为：A03-3，那么我就知道是A级导航的3级页面的第3个页面修改了，这样可以快速定位到需要查找的页面。
4.3、行为角色：参与或操作(执行)该功能的角色
4.4、简要说明：用最少的文字描述一下该用例的需求
4.5、前置条件：参与或操作(执行)此功能的前提条件
4.6、后置条件：执行完毕后的结果条件
4.7、流程图：该功能的角色活动过程(处理过程)图（第三步中的图）
上面示范的用例描述相对简单，也是最常用和基本的用例描述内容，当然也有稍微复杂一点的用例文档，文档中会详细描述使用场景、事件流和信息字段，也有一些用例文档还会插入产品界面效果图。
使用场景主要描述行为角色在不同情况下使用产品时，根据情况或问题给出相应的系统反馈。事件流类似流程图，只不过是通过文字的方式描述角色的活动过程。信息字段主要是描述用例中所用到的数据字段。
PRD文档标题：XX产品V1.0PRD_V2。前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号
网站产品设计：【未看】
https://tangjie.me/blog/17.html
https://tangjie.me/blog/15.html
移动产品设计：【未看】
https://tangjie.me/blog/36.html
https://tangjie.me/blog/47.html
