PRD为Product Requirement Document的简称，其中文翻译为：产品需求文档。
该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。广义上讲，产品需求的描述，应该包含有产品的战略和战术：
战略是指：产品定位、目标市场、目标用户、竞争对手等。
战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等，本文主要讨论的是战术部分。
PRD的主要使用对象有：
开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前，必须要通过评审确定的最重要文档。
产品经理的PRD，就像建筑设计师的设计图纸，是整个设计和思考的结晶，也是思考过程呈现。PRD的另一个重要的作用：定义产品需求，在团队内达成共识。
PRD文档的形式常见的有以下三种：Word、图片、交互原型
Word版PRD是传统意义上的PRD文档，主要主要内容包括：
↘ 信息结构
↘ 限制条件
↘ 业务流程
↘ 产品用例
↘ 非功能性需求
↘ 需求文档评审
PRD文档的阅读者更多是偏向于技术人员，因此PRD文档目的性很明确，就是要描述产品的功能需求，所有PRD文档是没有关于市场方面的描述，减少不必要的文字，让阅读者看懂并且了解产品意图，文字越少越好。
绝大多数人没有足够耐心认真看完PRD文档的，因此我们要尽量减化文档内容。
信息结构
产品结构就像建楼，设计时，要考虑整个建筑的结构，如是否包含美食区、服装区、百货区、休闲娱乐区等，然后每个区域又可以按商家或类型细分。
产品也一样，由功能和内容组成，所有的功能和内容，按照纬度组成频道/模块，最终形成产品整体结构。
产品结构一般用MindManger梳理。由于产品结构一般较大，这里以部分产品结构内容为例展示给大家参考：
限制条件
描述产品的全局性需求，例如网站产品的页面编码、用户角色，移动产品的缓存机制、下载机制，这类全局性需求说明。
例如：移动产品“状态维持与恢复”的例子，示例如下：
状态的维持与恢复
用户退出产品时（误操作、Home键、锁屏、自动关机），产品需要维持用户操作前的状态，当用户返回产品时仍可以恢复到之前状态，并继续使用。
维持状态包括流程操作、信息浏览、文本输入、文件下载。
锁屏状态时，如果用户在产品中有下载任务时，仍然保持下载。
业务流程
每个产品都包含业务，分析梳理出核心业务的流程，帮助产品经理了解产品逻辑。
B端产品的核心业务流程一般都会涉及到多个角色，而C端产品，核心流程的用户则比较单一。
涉及到多个角色的业务流程，可以使用泳道图，单个角色可以使用普通的活动图。
在分析业务流程的时候，还可以配合使用状态图和顺序图，具体使用什么工具，视情况而定，重点是梳理清楚逻辑。
产品用例
产品用例是更具体也更重要的一步，产品用例针对流程上的某个节点具体描述。
例如：会员中心→内容管理模块，模块包含用例有：
↘ 新增文章
↘ 修改文章
↘ 删除文章
↘ 查看文章列表
↘ 查看文章详情
一个完整的用例应该包含以下主要内容：
用例编号：
用例名称：
使用角色：
优先级：
描述：
前置条件：
后置条件：
界面：
规则描述：
其它说明：
详细需求的描述有两种方式：
↘ 用例描述
↘ 功能点描述
用例描述和功能点描述最大的区别在于描述的角度不一样，用例从人和系统的旁观者来描述，功能点是从产品的角度来描述。
用例描述最好用文档，即word版需求文档。而功能描述不但可以在word版中，还可以在Axure里以注释的方式描述。
不论是用例描述还是功能描述，规则都是最重要的一部分。
如何能完整无误的阐述需求并让阅读者看懂？
规则的描述，主要是从3方面描写：
-数据规则：指页面从数据库调取数据并展现的规则。比如查看文章列表这个用例，需要描述文章列表页面展示哪些字段、每个字段的类型及长度、列表的排序规则刷新频率等。
-状态逻辑：不同状态之间切换的触发点是什么，如：状态为已发布的文章，要变为下架，可能的触发条件有：发布时间已过期、手动操作下架等。
-交互规则：对界面上存在交互的元素一一列举说明，如链接、按钮、滑动、下拉的具体交互规则及异常处理。
另外，整个场景由于网络问题、系统问题导致的异常也需要说明。
非功能性需求
非功能需求涉及比较广，如：
性能需求：访问速度达到多少、最大能支持多少人同时访问；
设计需求：产品要设计成小清新风格还是成熟稳重的风格等；
统计需求：产品要统计哪些字段，形成哪些报表等。
本次产品的文档的内容暂时讲到这里，文档能力是产品经理的最基础的能力之一，写好产品文档能帮助大家在团队协作中有效提高沟通效率，以上这篇文章供大家参考消化一下。