文章目录

如何写简单实用的产品需求文档PRD
- 前言
- 产品需求文档模板
- - 1. 概述
  - - 1.1 产品概述
    - 1.2 典型使用场景
    - 1.3 功能列表
    - 1.4 目标用户
    - 1.5 名词解释
    - 1.6 参考文档
  - 2. 功能需求
  - - 2.1 XX功能
    - - 2.1.1 用例
      - 2.1.2 流程图
      - 2.1.3 原型图
      - 2.1.4 交互设计
      - 2.1.5 数据
  - 3. 非功能需求
  - - 3.1 兼容性需求
    - 3.2 数据统计需求
    - 3.3 运营管理后台需求
    - 3.4 性能需求
    - 3.5 安全需求
    - 3.6 全球化需求
    - 3.7 法务需求
    - 3.8 帮助需求
  - 4. 附录
- 扩展阅读

如何写简单实用的产品需求文档PRD

前言

产品需求文档（Product Requirement Document, PRD)描述了要开发的产品，包括产品目标、功能和交互行为等。

产品需求文档可以用Word来写，也可以写成Wiki在线文档，也可以用高保真原型加标注，也可以将需求分解成用户故事（User Story）写在项目管理软件（比如JIRA）上。

一般由产品经理来编写产品需求文档，同时产品经理会完成产品原型，并交给用户体验设计师做高保真原型。对小型团队，产品经理通常会兼任用户体验设计师。对比较复杂的产品（比如to B业务）需要需求分析人员（Business Analyst, BA）配合完成需求调研和需求分析。同时，也需要软件架构师（或开发经理）去评估产品开发的技术可行性和开发资源。

总之，一个好的产品应该满足以下三个方面：

价值：对用户有用的；
可用性：用户觉得好用的；
可行性：团队可以交付的（技术、资源、时间和成本可行性）。

产品需求文档模板

每个公司有不同的产品需求文档模板，直接套用模板并不是好的做法，但是参考一些好的做法，可以让产品需求文档更加清晰和规范。

如果用Word来写产品需求文档，在格式方面，通常需要有主标题、多级标题、目录、页眉、页脚、页码、版本号和修订历史。

下面来描述产品需求文档模板的内容。

1. 概述

相当于产品需求文档的前言。

1.1 产品概述

简单地描述产品背景和产品目标。

1.2 典型使用场景

描述产品的典型使用场景。

1.3 功能列表

描述产品的功能架构和功能列表，其中功能列表中包括一级功能、二级功能和优先级。

需要和Sponsor（领导、销售、市场）和开发团队（软件架构师或开发经理）来一起敲定优先级。

1.4 目标用户

描述产品的目标用户、用户目标（用户使用产品可以完成什么目标）、用户任务（用户使用产品来完成目标，需要做哪些事情）。

可以采用人格化的方式来虚拟典型的目标用户来帮助验证产品是否满足典型用户的需求，这一过程也叫用户画像(User Profile或Persona)。

注意：这里的用户画像和精准推荐中的标签化的用户画像是不同的两个概念。

1.5 名词解释

列出文档中用到的专有名词的解释。

为避免歧义，应该同时列出专有名称的中文名称和英文名称，并且在整篇文档和产品开发过程中都使用一致的专有名词。

1.6 参考文档

列出编写产品需求文档时的参考文档。

2. 功能需求

列出产品的功能需求，就是产品有哪些功能。

本章节的功能需求顺序应该和上面的功能架构顺序一致，以方便阅读。

2.1 XX功能

从概念模型方面，本章节描述了该功能需求如何帮助用户完成用户目标，以及给用户带来了什么价值。

可以使用用户故事的描述方法：

作为<用户角色>
我可以<用户任务>
使得<用户目标>

从实现模型方面，本章节可以让前端开发人员很清晰地去开发前端页面，使得完成的前端页面效果和高保真原型一致；让后端开发人员很清晰地知道应该为前端提供哪些接口和数据；让测试人员很清晰地知道测试的标准。

2.1.1 用例

用例图，描述用户角色可以做哪些用户任务。

2.1.2 流程图

业务流程图。

2.1.3 原型图

原型图，直观地描述该功能。

2.1.4 交互设计

交互设计稿（高保真原型）的地址。

体现出功能的入口、交互逻辑、错误反馈和异常处理。

2.1.5 数据

数据需求，包括字段、数据源。

3. 非功能需求

3.1 兼容性需求

兼容不同终端、不同平台和不同版本的需求。

3.2 数据统计需求

报表需求。

该部分需要和产品运营团队讨论确认。

3.3 运营管理后台需求

数据埋点和数据上报，版本更新和广告投放需求。

该部分需要和产品运营团队讨论确认。

3.4 性能需求

比如同时支持多少个用户在线，响应时长。

该部分影响服务器资源规划和软件架构，需要和软件架构师和运维团队讨论确认。

3.5 安全需求

需要遵守相关的安全规范和满足安全测试需求。

该部分需要和软件架构师和安全团队讨论确认。

3.6 全球化需求

如果需要支持多种语言，需要考虑全球化需求。

3.7 法务需求

需要符合法律法规和公司规定。

3.8 帮助需求

引导用户熟悉产品的需求，可能还需要包括帮助弱势群体的特殊需求。

4. 附录

产品需求文档应该简单明了，对其它的相关内容，可以作为附件或URL放在附录中。

扩展阅读

How To Write a Good PRD
Behind Every Great Product
用Axure做一个很棒的需求文档
《启示录：打造用户喜爱的产品》第18章重新定义产品说明文档