如何撰写产品需求文档PRD
当产品经理把产品的结构图、流程图、原型图都梳理完毕后，接下来的工作就是撰写PRD文档了，如果说思维导图是把产品条理化，流程图是将业务运转的步骤做出整体的说明，原型是结构布局，将系统脱去朦胧的华纱，具体化，那PRD就是穿针织网，把需求综合起来，整理成最终的产品需求文档。下面就来看看PRD文档的定义，怎么写，包含什么内容？需要注意什么？
PRD其实并没有规定的格式，每个公司都可以根据自己公司的实际需要来写适合自己产品团队的PRD。重点在于明白PRD的基础结构和内容。
PRD介绍说明
产品需求文档（Product Requirement Document的缩写）它是向研发部门说明产品的具体功能和性能指标的说明性文档。主要用于产品设计和开发使用，因此阅读这份文档的人群绝大多数是设计与技术人员。在这类人群中，设计师更多依赖于原型进行交互或视觉的设计，因此看这份文档的人就会偏向于技术的人员。相对于技术人员，他们不太关注产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、元素等等内容，因此PRD文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。
为什么写PRD
从概念到图纸再到具体详尽的描述；
产品人员可以通过对结构图、流程图、原型图的综合整理撰写PRD，对整个项目起到承上启下的作用，在梳理清楚方案实现过程中的各种问题和影响，并对各个功能细节进行详细的描述。产品人员可以通过撰写PRD，梳理清楚方案实现过程中的各种问题和影响。
向项目组成员传达详尽的说明；
PRD的主要面向对象是项目经理、开发、设计和测试，可以向项目成员传达需求的明细，项目经理通过文档可以迅速了解任务的规模和相关接口，开发设计人员通过文档可以了解页面元素和用例规则，测试人员可以提前根据文档撰写测试用例。
归档管理，方便保存，方便迭代，方便传承
大多数的产品都需要迭代几个版本后才能走向成熟稳定的阶段，如果没有PRD文档，在大型项目中，需求的迭代变更将变的无据可循。PRD文档可以在项目前后实现可前后查询的作用。
PRD构成要素
文档内容大致包含以下部分：
产品名称
版本修订历史说明
产品目录
产品简介：背景、目标、术语定义、产品规划说明
功能需求总表：流程图、功能表
功能性需求详情说明：全局说明、功能详情（功能名称、功能概要、业务规则、功能流程、界面原型、前置条件、后置条件、执行人；
BETA测试需求
非功能性需求说明：安全、性能、财务、法律、运营等需求
数据分析及风险评估
其他说明：上下线、运营计划、排期、技术对接方案等
附录（产品原型图&设计稿）
这是一份完整的PRD文档所有需要考虑到的维度，但并不是每个点都要写，根据实际需要撰写即可，以具体产品需要，填写相应的需求内容，好的产品文档都会将内容记录清楚，从而使整个产品顺利执行。
文档内容相关注释说明：
产品名称
产品命名（编号）：文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例）这样命名有利用版本号的迭代，
如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”，比如验证码增加语音验证；
如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”，比如注册增加了一种方式；
当出现产品第二版时，可以命名为“公司名-产品名-PRD-D2.0”，比如增加了商品、直播、钱包等功能；
举例：
电商产品增加了直播业务或者界面改版或者重大调整如增加语音直播可以6.0变7.0，
如果直播业务增加工会和个人主播区分或者增加了直播红包娱乐功能，则可以是0.1的变动，
如果页面可以由静态图片修改为动态视频可以是0.01。
不用纠结具体的版本，只需要根据实际情况进行设置即可，可以和开发人员共同确认即可。
版本修订说明
一般包含：编号、文档版本、修订章节、修订原因、修订日期、修改人、负责人。如果是大型产品一般会新起一个文档进行说明，依据具体企业情况而定；
编号是为了给修改文档一个顺序排列。
文档版本显示的当前修改的内容是在哪个版本中出现。
修订章节是具体到哪个章节哪个功能模块的修改。
修订原因说明此功能修改的问题所在。
修订日期以修改当日的日期为修订日期，
修改人显示修改内容模块的人
负责人：各个业务负责人，PRD做为一个说明 “载体”，会与技术、运营、财务、客服、技术、测试等人员沟通，方便找到相关负责人，并通过沟通把产品的细节落实清晰，并记录在PRD里。
目录：
使用word自带的目录生成功能即可，也可以自己建一个个人通用目录或从其它文档拷贝，不考虑目录的内容，等写完PRD可以再去更新。
只有大型成套产品才有目录，如果单一功能点或模块，目录可以弱化；
产品简介：背景、目标、术语定义（名词解释）、产品规划说明；
背景：解释产品需求的背景，为什么做这个产品，这个产品将会解决什么问题或有什么价值；
产品目标：产品需求的核心任务，也可以说是商业诉求的内在指标。产品想要完成什么任务或功能，或者需要达成什么商业目的。比如预计上线覆盖XX用户等，可选择性填写；
术语定义：特殊名称解释，对文档中会出现的比较新的名称，对这些名词进行解释。如：
交易快照：拍下商品时的交易快照，记录了成交当时商品的全部信息（标题、属性及详情等）。将作为买卖双方发生交易的凭证，任何交易纠纷或者投诉都将以快照为准。如果卖家再对这件商品进行编辑、修改，都不会影响这笔交易的信息，只要成功拍下，就会记录当时拍下时商品的所有信息，作为“交易快照”。内容包含：商品ID、标题、促销活动名称、主图、价格、运费、颜色、尺码、数量、商家发货地、拍下时的商品详情、该商品最后一次编辑日期。
商品伪删除：指定的商品删除操作，商家后台可见，不可操作，用户不可见
商品屏蔽：屏蔽指定商品在瀑布流或搜索列表中的展现
商品指定屏蔽：屏蔽指定商品在特定瀑布流或特定搜索词下的展现
商品降权：指降低商品搜索列表中的排名，搜索排序到最后，可设置降权时间，到期自动恢复
产品规划说明：产品基于时间点的阶段性描述。产品是个不断演进的过程，很多时间一期产品只完成了产品70%的功能，二期才会继续去完善剩下的30%，同时有可能会推翻了重新推出第二版。产品roadmap并不是全部规划好所有的阶段目标，而是更多的通过维护来保持产品的更新和迭代。
需求场景描述
使用者需求对需求的描述。需求描述有以下几项内容：用户特征描述、需求描述、场景描述、需求优先级。
用户特征描述即为产品的最终用户，确定产品的最终使用者及特征。
需求描述是对目标用户的需求描述，表达用户最需要的是什么，找到用户的最根本需求。
场景描述，产品在什么时间、什么地点，使用什么功能，以模拟用户的行为。
优先级是指用户对于当前产品功能需求的优先级，哪些是用户最想要的功能优先级则排前。
功能需求总表
一般包括二个部分，一个是流程图，一个是功能表。
流程图是对产品的整体走向的流程的规划，流程图是用来对产品整体功能逻辑的梳理，所以在做产品前建议所有的产品经理先梳理一下产品流程。
功能表是将流程图文字化，同时将列出产品的功能点。辅助技术人员建立和调整数据库结构和了解产品的全局结构；
功能性需求详情说明
全局说明：主要讲解产品的全局性功能的说明，例如产品的页面编码、用户角色，移动产品的缓存机制、下载机制，这类全局性功能的说明，如果没有可不写。
举一个移动产品的“状态维持与恢复”的例子，示例如下：状态的维持与恢复，当用户退出产品时（误操作、Home键、锁屏、自动关机），产品需要维持用户操作前的状态，当用户返回产品时仍可以恢复到之前状态，并继续使用。维持状态包括流程操作、信息浏览、文本输入、文件下载等。
详情说明：主要讲解产品的全局性功能，描述产品的各个功能名称、各个页面及页面模块元素，功能的规则与逻辑的描述，是产品文档的主体部分。包括以下内
功能概要：告诉此功能叫什么，主要干什么的，以及相关导航。
业务规则：每个产品在使用时都有自己的规则，而产品的业务规则则是将产品的流程细化。将这个功能的业务规则，包括一些细节，如排版形式、日期显示方式全定好，这样方便其它人员的沟通和理解。
功能流程：即该功能对应的流程图，如果没有可以不写
界面原型：产品经理在这时做的原型界面，只需做一个简、单的界面即可，更多的时候只是个框架图。
执行者：产品使用者。
前置条件：具体的操作或逻辑。如不同级别的会员显示的价格不一样；
后置条件：操作后的展示。将前置条件及后置条件结合起来书写说明；
BETA测试需求
很多产品都有BETA版本放出，为了就是收求意见和一些性能测试。这部份内容不是必须的，但现在很多产品已经开始先推出BETA版本再推出正式版，当然也 可以通过升级来解决。所以BETA测试需求并不是一定需要的。如果有BETA测试需求，则需写出BETA版测试的要求和期望达到的目标要求。
非功能性需求说明：
一般非功能性需求包括以下几个部分：产品性能需求、产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需求等，以具体产品需要，填写相应的需求内容，好的产品文档都会将这些内容记录清楚，从而使整个产品顺利执行。
数据分析：阐述产品数据，为产品赢得支持。
风险评估：描述产品可能存在的风险，比如商务谈判的风险，外部合作的风险，不当使用的风险等等。风险级别可设置高中低。以及遇到风险后所对应的解决方案。
其他说明
上、下线需求
上线时限需求：此产品预定上线日期？上线日期有无任何特殊依据或规定？
下线需求（活动类需求必须明确下线时间）：此产品预定下线日期？下线日期有无任何特殊依据或规定？双11发货问题，活动下线问题
运营计划：说明产品的后续运营计划。产品经理是核心需求的把握者，参与到产品整体运营计划显得特别的重要。
排期：明确各个功能点的开发进度及资源的配置，这也是需求评审会的一个重点，时间和责任人确认后，才能更好的推动项目的进展；
技术对接说明：如谁提供什么给谁，在什么时间；
附件：
原型图：仅是开发人员作为页面开发时的参照物，与真实产品并无关系；
效果图（UI图）：效果图是由设计师完成的产品图，和实际开发完成的产品保真度一致。
PRD表现形式：WORD+SVN、WIKI系统协同、原型+标注
WORD+SVN：
传统方式，word在阅读修改方面比较有优势，一般使用Word加SVN的方式来管理更新文档。
WIKI系统协同：
wiki在协同和保密方面会有优势，而且能够记录修改文档的每一次变更。
原型+标注：
将传统Word形式的功能需求说明标注在原型图上，将需求逻辑标注说明，是非常高效的产品需求说明方式，这样更便于去理解需求与表达需求，从而指导UI设计、开发与测试。
PRD模板
写PRD并不是产品经理的全部工作，但却是不可少的一部分，很大程度上反应了产品经理的思维和产品核心功能把握上，同时对产品经理沟通、协调、规划等都得到了一定的验证，但每个产品经理的第一职能是会写一份让其它人员看得懂的PRD。
PRD文档没有标准的规范，也没有统一的模板，每个公司都不一样，并且每个人也不一样，这个取决于个人习惯和团队要求。无论你采用哪种方式产出需求文档，最终的目的都是为了方便团队成员理解产品的意图，因此哪种方法能够避免细节黑洞，高效完成产品的设计和研发，那么这种方法就是最有效的方法。
这些更多的描述内容取决于个人的习惯，最终目的都是为了描述清晰产品逻辑，因此我的原则就是用越少的文字描述清晰越多的需求说明。毕竟这些文档是产品开发中的执行文档，文字不在多，表达清晰即可。
