产品经理小技巧——详解产品需求文档（BRD）

【文章摘要】之前的文章简单介绍了商业需求文档（BRD），但对于而言，是产品项目中最为重要的文档。

PRD是英文“ProductRequirement Document”的缩写，翻译为中文就是“”，主要用于完整描述产品需求，向研发部门明确产品的功能和性能。

PRD的面向对象是研发部门，用于向他们说明需要开发的产品功能和这些功能的性能要求。PRD质量的好坏，在很大程度上不仅直接影响着研发部门是否可以明确产品的功能和性能，而且在很大程度上决定了产品的最终质量。

NO.1 PRD的主要内容

一份完整的PRD文档主要包含两部分内容：一是对项目的介绍，包括项目概述、项目价值、项目背景等；二是整份文档的主体部分，对产品需求的详细描述，包括功能需求和非功能需求。

对于不同的公司、不同的项目类型，PRD包含的内容会有所差异，但一般来说，比较常见的PRD都会包含版本修订记录、项目概述、项目价值、项目背景、场景描述、功能总表、业务流程图、用户界面、功能描述、非功能描述、附录等模块。

下面是一份比较常见的PRD的目录。

目录

1.项目概述

2.项目价值

3.项目背景

4.功能概述

4.1场景描述

4.2功能总表

4.3业务流程图

4.4 功能描述

4.5 数据监控需求

5.用户界面

6非功能需求

7.附录

NO.2 产品功能的描述

用户界面和功能描述是PRD最重要的两个部分，用户界面主要是以产品原型作为载体，用直观图形的形式展现产品的功能，功能描述则是在用户界面的基础上，以文字的形式诠释产品功能的细节，使开发人员更清晰地明白产品功能性能的要求。

对产品功能进行描述，一般需要两个步骤：

第一， 梳理产品功能描述部分的整体结构，有规律地将产品功能分成多个较小的功能单元，并确定描述的先后顺序。

比如，在产品功能具体的分解时，可以按功能在系统中的位置、按业务流程、按功能主次、按功能所处界面位置等进行分解。

第二， 以用例的形式描述分解后的产品功能。

用例指的是在不展现系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。它的好处是可以将产品功能需求与产品设计彻底分离，不用考虑具体的系统设计与技术细节。

下面是一个关于旅游用例图的展现形式：

除了用例图，还需要一个与之对应的用例表，规范的用例包括用例名称、用例编号、角色、描述、基本流程、备选流程、异常流程、后置条件、备注等。

NO.3 PRD的基本要求

一份优秀的PRD文档应该满足五个方面的要求：完整、准确、清晰、简洁、稳定。具体如下所示：

在项目开发中，如果产品需求发生变化（这种可能性是很大的，但是一般来说，都会将需求变化放到下一版本中），那么在修改PRD的时候，也应该就修改PRD内容进行必要的确认。

NO.4 PRD的模板

很多公司应该都会有PRD模板，供产品经理参考。但我感觉，根据具体项目与产品功能需求的不同，产品经理是需要根据灵活情况进行修改的。比如，我们的产品经理在撰写PRD时，主要是围绕用户界面与功能描述展开的，很简洁，没有用到用例，但是以图文并茂的形式把产品功能介绍的很清楚了。

尹剑利，微信公众号@尹剑利（yinjianli88）。研究生在读，曾创业两次，有过多家知名上市公司的实习经历。热爱人文历史，痴迷互联网。希望遇到志同道合的朋友多多交流。