一、PRD文档概述

PRD（Product Requirement Document）：产品需求文档，是产品文档中最底层最细致的文档。文档侧重对产品功能和性能的说明，主要是把产品规划与设计中的产品流程、界面、功能等定义向研发、设计、测试等团队做清晰的描述说明。

二、PRD文档常见面向对象

产品经理：可以通过产品功能描述自查清单来系统的梳理产品功能点和描述，更加透彻和完整的梳理产品；同时，产品经理可以通过PRD和其他人员进行高效的沟通。

交互设计师：通过功能点及其描述自查来检查自己的交互稿是否遗漏特殊情况、异常情况、极限情况等。

开发工程师：检查自己的程序开发是否符合PRD中的相关要求。

测试工程师：PRD中的功能描述和用例转化为测试用例的一部分，进行产品可用性测试。

三、PRD文档作用

1、概念化”阶段进入到“图纸化”

市场需求文档（MRD）中阐述到的功能，都是表达的一个意向，不考虑实现方法和细节。而PRD则是将概念图纸化，需要阐述详细的细节和实现模型。产品人员可以通过撰写PRD，梳理清楚方案实现过程中的各种问题和影响。

2、向项目成员传达需求的意义和明细

PRD的主要面向对象是项目经理、开发、设计和测试。如何向这些不同的角色表达清楚需求明细，就需要一份规范的PRD文档来描述。项目经理通过文档可以迅速了解任务的规模和相关接口，而开发设计人员通过文档可以了解页面元素和用例规则，测试人员可以提前根据文档撰写测试用例。PRD文档在形式上是项目启动的必要元素之一。

3、管理归档需求

大都数的新需求都需要迭代几个版本后才能走向成熟稳定的阶段，如果没有PRD文档，在大型项目中，需求的迭代变更将变的无据可循。PRD的文档修订编号和命名也是项目规范化管理的主要方法之一。

四、PRD文档的基本要求

一份优秀的PRD文档应该满足五个方面的要求：完整、准确、清晰、简洁、稳定。 在项目开发中，如果产品需求发生变化（这种可能性是很大的，但是一般来说，都会将需求变化放到下一版本中），那么在修改PRD的时候，也应该就修改PRD内容进行必要的确认。

• 完整：必要内容无遗漏、功能描述完整
• 准确：表述没有歧义、同一内容前后表述一致
• 清晰：做好版本管理、文档结构清晰、使用技术化语言、表述不能过于含糊
• 简洁：多用图表、语言简练
• 稳定：开发前对内容进行充分确认

五、确定PRD文档格式

当我们的产品为APP形态，用RP版本较多，但是当产品流程及规则较为复杂，则更适用于word版本。

• RP格式

借助原型绘制工具（例如：Axure、墨刀）绘制原型，并在原型上直接撰写对应页面的内容说明。

• 文档格式

先借助原型绘制工具绘制好原型，在将原型整理到Word文档中，在文档中去撰写具体的需求说明。

六、PRD文档撰写基本步骤

撰写PRD产品需求文档可按搭框架、定流程、扣细节思路。

① 搭框架

首先遍历出所有用户角色，再针对每个角色，提供相应的系统/功能，然后按照某种维度进行结构划分，输出产品的系统架构图及系统的功能结构图。产品由一个个功能组成，功能是逻辑结构，一个完整的功能具备输入、处理、输出三大特性。从大到小的划分是：系统>功能模块>功能，用户+功能组成了用例。

② 定流程

每个产品都有一个核心业务流程，这个核心业务流程涉及多个角色，这个步骤就是把各个角色和功能联系起来。通过核心业务流程，阅读者可以了解产品全貌，对产品有个宏观的认识。每个系统也有各自的核心业务流程，全业务流程+子系统业务流程，可以概括产品的业务逻辑。输出产品核心业务流程图，子系统核心业务流程图，活动图，状态机图，与外部系统交互可能还有时序图。

③ 抠细节

画原型和功能设计，通过原型表达产品的界面和交互。推荐使用Axure、墨刀绘制原型图，通过简单拖拉创建事件即可做出多样的交互设计。

七、PRD文档具备要素

1、命名与编号

文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。 文件命名的方法一般是通过版本号定义，比如简单的方法是，XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号。稍微详细点可以定义成，XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名，这样更便于阅读和记忆。

2、修订记录（版本历史）

包括，编号、文档版本、章节、修改原因、日期、修改人。编号只是为了记录修改的顺序，文档版本显示的当前修改的内容属于文档的第几个版本(或第几次修改，一次修改一般为一个版本)，章节是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修改原因说明为什么要修改该需求，让阅读者直观的了解原因。日期是指需求文档修改的时间，修改人是指需求内容的修改者。

3、目录

不需要自己新建，文档完成后直接更新模版中的目录即可，用来了解文档结构。

4、引言

这部分内容包含产品概述及目标、产品规划、预期读者、成功的定义标准和判断、参考资料、全局说明等。

① 产品概述：解释说明该产品研发的项目背景、现状、目标等。可以帮助项目成员更好了解项目的价值及意义。

• 项目背景：主要介绍为什么要做这个项目，也就是说清楚用户或业务的痛点及诉求
• 项目现状：介绍当前项目的一个实际情况及存在问题
• 产品目标：期望获得多少价值指标提升，产品上线后的效果，期望达到的目标

② 产品规划：为产品规划的蓝图，每个关键阶段完成的核心任务。产品研发是个不断迭代的过程，需要经过若干个版本的迭代，对一个功能点做了N个迭代后最终又回归到了第一个迭代是很常见。产品经理需要做好心理准备。产品规划并不需要全部规划好所有的阶段目标，但是对产品未来发展趋势的一种预估，要达到目标，需要更多的更新和迭代。清晰的呈现产品的规划可以帮助产品经理把握产品的全貌，更好的控制研发过程。

③ 预期读者：文档的使用对象

④ 成功的定义和判断标准：旨在说明产品的目标

⑤ 参考资料：PRD的参考资料

⑥ 全局说明：包括名词解释、统一异常处理、列表默认数据规则等。

• 名词解释：提前将晦涩难懂的术语提前做好解释，便于达成共识，更好沟通；
• 统一异常处理：网络异常、后台服务异常的交互逻辑；
• 列表默认数据规则：默认列表排序方式，默认显示条数，超多少条翻页，缺省值展现
• 以及所有涉及全局的描述，都可以罗列在这里。

5、需求概述

需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等。需求概览：分两部分，一是业务流程图，对产品整个业务流程的发生过程做图形化的展示，是对产品整体功能流程的阐释。二是需求清单，对本次要开发的需求任务做分类，给出简明扼要的需求描述并标注优先级。

用户类与特征：产品的最终用户，确定产品的最终使用者，并对使用者的角色和操作行为做出说明。

运行环境：该产品上线后的使用环境，比如支持的浏览器及其版本，操作系统、数据库的要求等等，测试人员在看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运营环境告知给用户。

设计和实现上的限制：比如控件的开发环境、接口的调用方式等。

项目计划：对于prd中要开发的内容，给出关键里程碑，比如需求评审通过的时间、开发的完成时间、上线时间等。

产品风险：描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不当使用的风险等等。

6、功能需求

功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容：

• 简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题

  场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。这也是产品经理讲“好”故事的必备条件。

• 业务规则：每上产品在开发时都有相应的业务规则，将这些规则清晰的描述出来，让开发、测试人员能够直观的明白该规则，且没有产生歧义。业务规则必需是完整的、准确的、易懂的。业务规则的描述上如果涉及到页面交互或者页面的修改，建议给出页面的草图或者页面截图在图上说明要修改的内容。另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明，什么时候可见，不可见，灰掉或点亮的条件在文档中都给出说明。方便阅读者理解业务规则。

• 界面原型：如前所述，涉及到页面交互的部分，产品经理需要设计页面原型。原型设计通常需要产品经理和UI设计师一起来完成。建议的做法是，产品经理可设计一个页面框架，将该页面要呈现的字段及其特征以及页面要使用的场景向交互设计师解释清楚。之后交互和视觉设计师完成产品的原型设计。

• 使用者说明：对产品使用者做出说明，可融入简要说明中。

• 前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像文件。

• 后置条件：操作后引发的后续处理。

• 主流程：结合上面所说的，做出主流程说明，对每个功能流程走向分点说明(非常重要)。

7、非功能性需求

数据需求：常见的就是数据埋点，产品经理需要梳理出埋点事件表，告知开发，让开发在编码过程中进行埋点。

监控需求：需要监控某个接口或某些服务，当出现异常时可以发送报警信息至相关人员。

性能需求：需要支撑多大的并发，运维人员可以提前准备部署方案。