PRD全称Product Requirement Document，中文名为「产品需求文档」。其核心目的是帮助开发、测试、运营、产品人员理解该需求的背景和具体要求，减少产品实现过程中诸多不必要的重复解答，从而提升整体项目推进效率。那么，一份合格的PRD应该包含哪些内容呢？

一、更新记录

由于项目在实际推进过程中会出现多方并行，以及需求的变更和完善等情况，一份最终版的PRD可能经过了多次编辑和更新。所以需要在文档中添加更新记录，方便团队成员了解完整的需求信息。更新记录中一般包含版本号、更新时间、核心变更内容（尽可能添加文档索引）和操作人。需要注意的是，由于大型项目的版本更新需求涉及的业务相对较多，所以产品不同版本的PRD一般分成不同的文档进行汇总，而此处的版本号指文档变更的版本，并非产品对应的版本号（如合并到同一文档可在前面再添加一列记录）。

二、目录

此处的目录指带索引功能的目录（方便团队成员快速锚点到文档对应位置），可通过文档自动生成。

三、概述

1. 需求说明

主要说明项目的背景和原始需求，帮助团队成员理解需求的出发点。

2. 产品结构

用于描述该产品或需求的主体结构（该结构应和后文的功能性需求或非功能性需求说明目录保持统一），可使用MindManager/Xmind等脑图工具绘制，如结构图过大可考虑通过添加附件的方式提供。

3. 主业务流程

通过流程图、泳道图（可用visio工具绘制）对核心业务流程进行表达。需要注意的是，此处并非详细的逻辑/交互流程，而是对主业务流程的示意，如示意图过大可考虑通过添加附件的方式提供。

四、名词释义

如文档内包含特定的专有名词，包括全新定义的、已有的非常见的名词，以及常见名词的衍生定义，则需要对相应的名词进行解释。

五、功能性需求

1. 全局性交互和数据规则

1）交互

全局性交互更多见于一些载入、网路、提醒情况下，某些特定的交互和场景下也可能存在特殊的全局性需求（如微信的悬浮窗功能）。

附：APP产品设计中常见的全局状态

2）数据规则

全局性数据规则常见于最高优先顺序（相对）的数据，用于限制下级数据的下发，如黑名单管理、用户状态等。

2. 各个模块的详细说明

对于各个模块的层级划分需和前文的产品结构保持一致，需详细描述业务模块的展示、交互和数据逻辑，一般包括以下几个方面：

1）原型

具体该模块的原型，若与实际设计图有变化（包括信息元素的变动或布局的较大变动），应替换为设计图截图或修改后的原型。

2）信息/显示规则

基于原型所见内容或规则需要，模块中会用到哪些信息，以及展示时候有哪些类型或限制，具体说明为：

A.信息展现形式：文字、图片、图标；

B.信息展示内容：具体文案、图标的需求；

C.同一信息如果存在不同类型或状态的说明，比如性别男、女；

D.信息展示的规则限制，常见有：字数限制、行数限制、高度限制、宽度限制、缩放限制、颜色限制、格式限制、隐藏限制等。

3）交互规则

交互的范围很广，常见的交互需求应包括以下内容，但可能很多交互情况的处理方式可以标准化，但在需求中仍需说明，具体应根据实际产品/需求而定。

A.交互操作：点击、载入（载入中、载入失败、载入超时）、滑动/拖动（左滑、右滑、上拉、下拉）、长按、双击、多点操作等；

B.交互响应：变色/变暗/变数、区域响应、文字响应、动画响应、效果响应、文字显示；

C.响应结果：指的是交互操作后的各种结果，某些情况下如果需求特殊的交互响应过程/动画，应特别说明；

D.技术实现：专指特殊的交互动作/动画需求，应提前找到案例或与开发人员沟通，避免不具备可实现性。

4）数据规则

与「信息」的差异在于，信息更偏于直接显示的、以及落地到每一个文字/图标细节的元素，而数据规则是更整体化的规则说明。数据规则制定时，应首先确定好方向定位，再拟定初版规则并进行完善，同时数据规则的设定一般对技术依赖严重，因此需提前和技术沟通。（一般而言，数据规则至少包括数据如何获取、数据如何缓存两部分）。

5）异常状态

异常状态常见包括载入失败、无数据、超时等，同时，部分特定场景下的产品/功能还有特别的异常状态，比如未获得相关许可权、无相关设备、空间存储不够、文件丢失、文件格式不支持等。

六、非功能需求

非功能性需求基于不同类型的产品/项目，差异性可能较大，常见的类型包括：

1）性能需求。如大致响应时间需求、最大并发数要求等；

2）兼容性需求。通常情况下，PC端网页要求对主流浏览器如IE、Chrome、360、QQ的兼容，H5网页要求对UC、QQ、微信、Safari等浏览器或客户端兼容，iOS APP要求兼容iOS891011系统以及iphone5、5s、6s等以上设备，安卓APP要求兼容4.2/5.x/6.x/7.x/8.x/9.x等主流系统以及华为、小米、三星、oppo、vivo等设备；同时移动网路都要求兼容电信、移动、联通三大运营商基本网路类型等；

3）网页的URL和TKD；

4）大页面/模块的缓存规则（但如果部分模块的缓存规则是独立的，则应在具体模块的数据规则说明中直接说明）；

5）纯文字/图片设计内容（比如设计礼物、表情等）；

6）风险控制需求。部分业务有可能存在一定的风险，比如被刷注册、刷评论等，这类风险可提前在技术实现时做一定的兼容可控性。

七、数据统计需求

数据统计有的可直接在伺服器统计，有的则需要前端/客户端上报统计，有的还可以直接使用第三方统计工具，需根据实际情况区分。但一般包含以下四部分：

1）基本数据统计：如用户新增、活跃、留存等统计；

2）业务数据统计：如业务收入、支出、付费率、退款率等统计；

3）事件行为统计：以操作类统计为主，可组合成相应的路径统计；

4）统计展示后台：主要用于展示数据报表，方面产品、运营和管理人员直观查看数据。

八、交付与上线

1.交付说明

交付的核心是保证项目/产品在推进过程中有对应的人员进行对接，所以需要针对涉及到的不同部门，明确相应的交接人员，如：开发、测试、运营、财务等。

2.上线方案

为确保产品的最终效果，一个优秀的上线方案至少应从以下方面准备充分：

1)历史数据或交叉业务处理；

2)技术支持；

3)运营方案；

4)推广策略；

5)数据和用户反馈跟踪。

结语

PRD的意义在于围绕业务把需求表达出来，把要做的东西说清楚说明白，提前把一些需要准备的事项安排好，其核心的目的是提升项目的沟通和推进效率。不可否认，PRD的编写能力，可以体现一个产品经理对于需求的理解和表达能力，但这并非适用于所有公司和产品。对于一些小型项目或者小版本改动，可能大部分的交互和逻辑描述只需要在高保真原型上示意就够了，编写完整的PRD再推进还可能影响整体的项目推进效率，所以，最重要的还是围绕业务和项目实际情况，选择合适的方式把需求准确的表达出来。

PS：关注产品研究社，回复「PRD模板」即可领取模板。


推荐阅读：
相关文章