博客地址：http://caligo.cc
PRD的书写
PRD介绍
英文Product Requirement Document
中文：产品需求文档
定义：基于BRD、MRD的延续文档
地位：产品设计的最终表述的形式
读者：执行层面的工作人员，设计与技术人员(包括测试工程师)
次要设计师：依赖于产品原型进行交互或视觉的设计
主要技术人员：需要一份详细的产品功能需求说明文档
技术人员不太关注产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、元素等等内容
产品需求文档是没有标准规范的，也没有统一的模板，每个公司都不一样和每个人也不一样，这个取决于个人习惯和团队要求。目的是能够明确产品的功能需求，便执行人员理解任务要求。
PRD写作
罗列信息（信息结构图）
形式：文本、思维导图->信息结构图
目的：->设计功能的辅助信息
->辅助服务端技术人员创建数据库
但是初步，不需要太细，继续改进和完善
梳理需求（产品结构图）
1.罗列出产品的功能结构
使用思维导图软件，内容包括频道、页面、模块及元素。
2.从频道到页面，再细化页面功能模块和元素
产品 -> 频道 -> 页面 -> 模块元素 -> 操作 -> 元素
3.梳理
梳理思路，通过这种方法可以明确产品有多少个频道、有多少个页面、页面有多少个功能模块、功能模块有多少个元素，逐步的将脑海里的想法明确梳理成结构。
原型设计（界面线框图）
Axure RP，sketch etc.
1.手绘原型
验证可行性，敏捷开发时快速出原型
2.灰模原型
灰模原型缺少交互效果，仅仅是将产品需求以线框结构的方式展示出来，让产品需求更加规整的直观展现
3.交互原型
通常情况交互原型的设计要早于产品需求文档，是产品经理想法推演的重要一步
一般产品经理与交互设计师共同讨论确定，然后由交互设计师制作
但一般没有交互设计师这个职位，因此这类工作最终是由产品经理来负责的
对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案的可行性，同时也是为了产品宣讲时让听众能够清晰直观的了解产品，避免抽象的语言描述导致听众理解困难和理解偏差。产品原型也是为了确保产品在执行过程中，是按产品经理最初设想的需求和期望完成的，因此产品经理的原型是没有很高的要求的，只要对方能够听懂看懂就可以了，所以使用手绘原型是最高效率的方法。
用例模型（产品用例图）
用例(Use Case)是一种描述产品需求的方法，使用用例的方法来描述产品需求的过程就是用例模型，用例模型是由用例图和每一个用例的详细描述文档所组成的。
产品人员的用例主要是为了方便技术研发和功能测试时，让参与者更好的理解功能的逻辑.
UML(Unified Modeling Language):统一建模语言或标准建模语言
常用：Microsoft Office Visio
产品用例是一种通过用户的使用场景来获取需求的方式，每个用例提供了一个或多个场景，该场景说明了产品是如何和最终用户或其它产品互动，也就是谁可以用产品做什么，从而获得一个明确的业务目标
1.用例图
用例图包含一组用例，每一个用例用椭圆表示，放置在矩形框中；
矩形框表示整个系统。
矩形框外画人or其他物件，表示参与者。参与者不一定是人，可以是其它产品、软件或硬件等等。
某一参与者与某一用例用线连起来，表示该参与者和该用例有交互。
2.用例描述文档
对于产品的功能有一个总体的认识除了图外，还需要描述每一个用例的详细信息
用例名称：本用例的名称或者编号
行为角色：参与或操作(执行)该用例的角色
简要说明：简要的描述一下本用例的需求(作用和目的)
前置条件：参与或操作(执行)本用例的前提条件，或者所处的状态
后置条件：执行完毕后的结果或者状态
另外状态图、流程图或序列图也可以用来辅助说明。
只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其它图形。
流程图有助于描述复杂的决策流程
状态转移图有助于描述与状态相关的系统行为
序列图适合于描述基于时间顺序的消息传递。
在互联网产品和设计中，用例的使用越来越少，通常有了产品原型再加上功能流程图和功能说明文档就能够将产品需求详细的表述清楚，所以也没有必须撰写用例了。但是在大公司里，往往会追求产品流程的规范性，要求撰写用例，不过在敏捷开发的时候也会采用其它更有效率的方式，不一定非要撰写用例。
逻辑流程（功能流程图）
一个完整的使用图形的方式表示算法逻辑的图表，可以直接转换成程序需求描述文档
需求文档
1.表现形式
常见的有Word、图片和交互原型这三种形式，文档内容通常包含信息结构图、界面线框图、功能流程图、功能说明文档。
虽然产品需求文档没有标准的规范，文件标识和修改记录必不可少。方便大家查看和了解改动的内容。
参考格式
|产品名称|文件标示|序号|版本|编写/修订说明|修订人|修订日期|备注|
1.1 word
传统意义上的产品需求文档，主要有四个部分组成(具体根据产品要求进行划分)，分别是：
结构图
全局说明
频道功能
效果图
没有市场方面的内容，尽量减化文档内容
1.1.1 结构图
信息结构图：主要是辅助服务端技术人员创建或调整数据结构的参考文件
产品结构图：主要是辅助设计和技术开发人员了解产品的全局结构。
1.1.2 全局说明
讲解产品的全局性功能的说明
如“状态维持与恢复”功能
状态的维持与恢复
当用户退出产品时（误操作、Home键、锁屏、自动关机），产品需要维持用户操作前的状态，当用户返回产品时仍可以恢复到之前状态，并继续使用。
维持状态包括流程操作、信息浏览、文本输入、文件下载。
锁屏状态时，如果用户在产品中有下载任务时，仍然保持下载。
1.1.3 频道功能
以频道为单位，页面为子项，描述产品的频道、页面及页面模块元素的功能需求。
1、频道名：频道介绍及需求说明
2、页面1：页面介绍及需求说明
2.1、页面模块1：模块功能需求说明
2.1.1、页面模块1-元素1：功能说明
2.1.2、页面模块1-元素2：功能说明
2.2、页面模块2：模块功能需求说明
例如一个“完成”按钮，我们需要描述他完成后，系统要不要给出反馈提示(反馈提示是什么样的形式反馈，内容显示成什么，有没有内容需要调取数据库)，或者要不要跳转页面(跳转到哪个页面，这个页面是其他频道页面，还是这个功能的子页面，如果是子页面就需要再描述这个子页面的模块及元素内容)
1.1.4 效果图
由设计师完成的产品图，和实际开发完成的产品保真度一致
2.图片
基于效果图的说明文件，将传统Word形式的功能需求说明标注在效果图上
3.交互原型
通过Axure PR制作出产品原型后，加上元素的标注，在标注中说明功能需求，这样导出的HTML文件相比Word文档更直观易懂，是非常高效的产品需求说明方式
参考
