PRD(开发需求文档）的作用
①概念化”阶段进入到“图纸化”
市场需求文档（MRD）的功能，都是表达的一个意向，不考虑实现方法和细节。
PRD则是将概念图纸化，需要阐述详细的细节和实现模型
产品人员可以通过撰写PRD，梳理清楚方案实现过程中的各种问题和影响
②向项目成员传达需求的意义和明细
PRD文档在形式上是项目启动的必要元素之一
③ 管理归档需求
PRD的文档修订编号和命名也是项目规范化管理的主要方法之一
PRD的表现形式
企业内部的PRD文档选择wiki系统或word文档
wiki在协同和保密方面会有优势，而且能够记录修改文档的每一次变更
而word在阅读修改方面比较有优势，一般使用Word加SVN的方式来管理更新文档
案例介绍：旅行箱–目的地攻略
需求目标：在APP中展示相关国家/城市的旅游资讯内容
引言
需求描述
1、目的地攻略以城市/国家为单位，展示八个栏目下的文章列表。
2、初期运营指标为编辑所有涉及城市的归属国家攻略内容，相关城市暂不编辑；APP前台默认显示国家内容卡片，城市内容卡片无数据时隐藏。
3、运营系统提供内容生成对应的触屏网页，App读取和下载对应网页内容；
业务模块
文章列表页共包含一个页面，四个用例
描述结构
分享文章用例
查看文章列表
查看文章（太简单可不描述）
产品需求文档的要素
文档的命名和编号
文件命名的方法一般是通过版本号定义，比如简单的方法是，XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号。稍微详细点可以定义成，XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名，这样更便于阅读和记忆
文档的版本历史
包括，编号、文档版本、章节、修改原因、日期、修改人
目录
文档完成后直接更新模版中的目录即可
目录是用来了解文档结构的
引言
内容
产品概述：解释说明该产品研发的背景以及核心功能。
产品roadmap：为产品规划的蓝图，每个关键阶段完成的核心任务。产品研发是个不断迭代的过程，需要经过若干个版本的迭代，，对一个功能点做了N个迭代后最终又回归到了第一个迭代是很常见。产品经理需要做好心理准备。产品roadmap并不需要全部规划好所有的阶段目标，但是对产品未来发展趋势的一种预估，要达到目标，需要更多的更新和迭代。清晰的呈现产品的roadmap可以帮助产品经理把握产品的全貌，更好的控制研发过程。
预期读者：文档的使用对象
成功的定义和判断标准：旨在说明产品的目标
参考资料：PRD的参考资料
名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。
需求概述
需求概览：分两部分，一是业务流程图，对产品整个业务流程的发生过程做图形化的展示，是对产品整体功能流程的阐释。二是需求清单，对本次要开发的需求任务做分类，给出简明扼要的需求描述并标注优先级。
用户类与特征：产品的最终用户，确定产品的最终使用者，并对使用者的角色和操作行为做出说明。
运行环境：该产品上线后的使用环境，比如支持的浏览器及其版本，操作系统、数据库的要求等等，测试人员在看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运营环境告知给用户。设计和实现上的限制：比如控件的开发环境、接口的调用方式等等。
项目计划：对于prd中要开发的内容，给出关键里程碑，比如需求评审通过的时间、开发的完成时间、上线时间等等。
产品风险：描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不当使用的风险等等。
功能需求
简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题。
场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。这也是产品经理讲“好”故事的必备条件。
业务规则：每上产品在开发时都有相应的业务规则，将这些规则清晰的描述出来，让开发、测试人员能够直观的明白该规则，且没有产生歧义。业务规则必需是完整的、准确的、易懂的。业务规则的描述上如果涉及到页面交互或者页面的修改，建议给出页面的草图或者页面截图在图上说明要修改的内容。另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明，什么时候可见，不可见，灰掉或点亮的条件在文档中都给出说明。方便阅读者理解业务规则。
界面原型：如前所述，涉及到页面交互的部分，产品经理需要设计页面原型。原型设计通常需要产品经理和UI设计师一起来完成。建议的做法是，产品经理可设计一个页面框架，将该页面要呈现的字段及其特征以及页面要使用的场景向交互设计师解释清楚。之后交互和视觉设计师完成产品的原型设计。
使用者说明：对产品使用者做出说明，可融入简要说明中。
前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像文件。
后置条件：操作后引发的后续处理。
主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明(这是非常重要的)。
效益成本分析
整合需求
BETA测试需求
非功能性需求
运营计划
