PRD产品需求文档 | 实例撰写指南【非原创】 - MilkeZhang 的网络笔记
一、什么是PRD？PRD就是产品需求文档，取英文Product requriement document 的首字母。简单来说就是一份用来介绍产品是什么，以及怎么实现的文档。“产品”：介绍产品“需求”：阐述需求“文档”：以文档的形式呈现产品需求文档 PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。
一、什么是PRD？
PRD就是产品需求文档，取英文Product requriement document 的首字母。
简单来说就是一份用来介绍产品是什么，以及怎么实现的文档。
“产品”：介绍产品
“需求”：阐述需求
“文档”：以文档的形式呈现
产品需求文档 PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。
在整个软件产品的开发，一定是不同部门、不同角色、不同岗位，协同工作的成果；
因此在过程中，也就需要大家各自在自己的职责范围内，完成相应的工作。
MRD、BRD、PRD就是过程中的比较详尽的交付文档，一起被认为是从市场到产品需要建立的文档规范。
MRD：市场需求文档，英文全称Market Requirement Document。
该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导；
BRD：商业需求描述，英文全称Business Requirement Document。
基于商业目标或价值所描述的产品需求内容文档，其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据，是产品生命周期中最早的文档。
二、为什么要有PRD？
为什么要有PRD？PRD又是如何发挥作用的呢？
在将PRD之前，首先讲述一下产品开发的流程中，核心的几个节点：
需求分析——需求确认——功能拆解——流程绘制——原型绘制——PRD书写——PRD讲解——产品开发——测试验收…
需求来源：产品接收业务需求；
需求分析：产品分析需求是否合理，需求价值点；
需求确认：同业务方确认需求；
功能拆解：产品基于业务需求，拆解产品需求；
流程绘制：产品基于需求，明确系统实现流程；
原型绘制：产品绘制原型图，原型相当于产品的一个最初的demo演示；
PRD书写：产品撰写PRD，需书说明PRD中详尽的写了需求的背景、来源、价值；以及包括的功能范围、功能说明；
PRD评审：产品同业务方、开发团队、UI设计等相关部门，基于PRD文档召开需求评审；
产品开发：研发人员基于PRD文档开发代码；UI人员基于PRD设计页面；测试人员基于PRD写测试用例；产品配合各个部门推进需求开发；
……
需求从开始到结束，期间经过了不同的阶段，需求的提出者、需求的实现者并不会一直同时跟进需求的进度。
所以要确保开发出来的需求，满足提出者的诉求，且参与其中的所有人可以理解一致，这个时候就需要PRD把这些需求描述清楚。
开发可以根据PRD获知整个产品的逻辑；
测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。
PRD是项目启动之前，必须要通过评审确定的最重要文档：
保证一致的需求理解；
提高协同的效率；
版本的记录和留存。
三、PRD文档的撰写
产品经理作为一直参与其中的角色，也作为PRD文档的输出者，需要负责PRD的撰写、文档更新、文档版本记录。
PRD文档侧重的是对产品产品功能和性能的说明，相对于业务需求中的同样内容，要更加详细，并进行量化。
不同的公司、不同的项目对需求实现的流程都不太一样，
有的可能是通过MRD进行沟通、有的是依据于BRD、更多的需求可能是一句话的事情，
无论是哪一种形式，最好还是通过一个正式的方式，将业务需求确认下来，
可以避免很多研发过程中的风险，像是拉扯、甩锅……
同样，不同的公司对PRD文档的形式要求也不一样，有的是word文档形式、有的是原型备注说明，需要根据具体的需求场景、紧迫程度来衡量，无论什么形式，PRD的核心的目的，依旧是把事情说明白。
1. PRD的框架
在我们进入一家新的公司之后，写PRD之前，通常都会向同事询问：“我们这里的PRD模版什么样子，发一份给我看看吧。”每个公司都有自己的PRD模版，有标准的页眉、页脚以及内容框架，包括但不限于：
文档的命名和编号
文档的版本历史
目录
需求概述
产品描述
功能需求
非功能需求
运营计划
当然以上内容是按需自取，任何事情都要讲究因地制宜。
实在没有必要为了套模版，一句话换不同角度去描述，长篇大论，反倒影响到需求的传达。
以自己的工作为例，经常用到的模块像是概述、产品描述、功能需求、非功能需求；
像是一些大型项目，验收标准、运营计划都会有单独的文档说明。
2. PRD攥写
1）文档的命名和编号
这个就不用多说，封面的长相排布都大差不差。
主标题：“XXXX需求文档”，主标题直接明了的说明，这是个什么产品、什么需求。讲究排版的童鞋，也自定义可以写一串“Product Requirements Document”上去；
副标题：当主标题无法说明清楚的情况下，可以通过副标题，更清楚的表达需求的范围；
编号：根据公司的要求书写即可。
2）文档的版本历史
文档信息
版本更新历史：用来记录文档版本的更新，以及更新内容，方便协作以及回溯。
3）目录
一方面目录展示了整个PRD的逻辑，以及PRD的需求概览；另一方面也起到了快速检索、快速定位的作用。
4）需求概述
产品概述及目标：简单明了的说明清楚需求的背景、目标、价值点；
文档阅读对象：该文档主要面对的人员范围，已经明确不同阅读对象相关的职责和负责的事项；
运营环境：本次需求涉及到的各个系统的大概说明；
产品风险：目前已存在的风险，需在文档中记录，以及需确保在评审结束后，项目参与人员已周知。
5）产品描述
在产品描述中的内容，为对整个需求的全局描述，一些涵盖全局的需求描述和设计内容，可以在这个模块统一解释说明。
名词解释：PRD文档中经常涉及到很多专业名词，或者是一些长称呼的简写，这些名词解释对理解产品需求至关重要。
为了更方便、快捷的理解，还是希望在整个文档中，可以使用大家都可以共识的词语去定义功能、描述需求；
产品整体流程图：整体的流程图，可以更快更准确的像开发、参与人员传递出需求的全貌。
产品整体流程图的主要目的，是为了方面阅读者理解整个需求的场景、参与的角色、彼此的关联、核心的主流程。
整体的流程图中，主要表明要完成哪些任务、核心节点…任务或者核心节点的拆解，可以不在这个阶段做详细的拆解。
功能清单：功能清单很好理解，即说明清楚这次的文档中，需要实现的产品功能有哪些的，也就是下一章节的内容概览；
关于功能清单，需要考虑的问题包括，以什么维度去拆解、以及拆解的颗粒度；
无论是以场景去拆解、还是系统框架去拆解、亦或是页面逻辑等，依旧是以“因地制宜”、“理解为上”为核心目的。
上述的几个模块是从需求来源、全局角度，对整个需求的概述，方便阅读者快速的理解需求的目的、价值，且达成一致。功能需求章节则是对每个细项功能点的详细描述，不同角色阅读后，可以根据此进行下一步的工作；例如说开发可根据内容，完成任务的拆解以及代码开发；测试可以根据内容，完成任务的拆解以及测试用例的编写等……
6）功能需求
这个模块毋庸置疑，是这个PRD文档核心发力的模块。
首先是要将需求拆解开，比如说本次的需求是完成“商品中心”的搭建，那么就可以拆解为：
商品列表
新增商品
编辑商品
查看商品
删除商品
……
同功能清单一样，拆解的颗粒度按照实际的需求，拆解完成之后，这部分内容就会生成PRD的目录；
因此在进行的过程中可先把需求的层级先梳理清楚，再填充内容。
先搭框架、再填充的步骤，都已经是被大家熟知的方式，无需多说其好处。
框架构建好以后，就该填充内容了，可按照如下的逻辑顺序按需自取，例如在中后台系统的设计中，需要有对角色权限的描述，就需要新增一个权限说明的模块：如果无需以下内容，也可以删减修改。
场景描述：对该功能的业务需求、使用场景的描述；
流程图：该模块的详细流程图，说明清楚任务、节点、流传；
原型图：相当于需求预览图；
详细说明：如何把需求实现出来，对流程图以及原型图的详细说明。
实例说明（*以新增商品为例）：
① 新增商品
A. 场景描述
新增商品主要面向商品运营人员，新商品需上市，需要运营人员将新的商品信息，新增维护进主数据，包括商品的基础信息等。
② 流程图
③ 原型图
④ 详细描述
路径说明：说明清楚到达此页面的路径，如“商品中心-商品列表-新增”。
填写内容：四个阶段说明：“填写基本信息”-“填写包装信息”……（虽然有图片，但是最好通过文字书写出来，防止图片模糊、文案变动造成的差异）。
基本信息说明：详细到每个需要填写的字段；
字段名称：名称
字段类型：输入框、下拉框…
默认显示
填写限制
填写校验
是否必填
提示信息
使用场景
……
下一步：
填写过程中，点击下一步，顶部高亮说明；
点击下一步，保存上一步的内容/不保存说明；
下一步报错说明；
取消：点击取消的说明。
确认提交：
确认校验说明；
确认成功说明；
确认失败说明。
取消/关闭页面：
取消说明；
关闭说明；
……
在详细说明阶段，除去一开始默认的原型图外，在说明的过程中也需要补充许多交互原型图，如校验提示、弹窗、切换、按钮变化、状态的变化等等。在一些状态和页面复杂的需求中，一定要把每个状态的流传定义清楚，包括不同状态下的页面、按钮、交互的变化等。
功能需求这个章节的形式，可根据个人爱好，有的人喜欢word原始的版式，有的喜欢表格区分块；
如无公司强制要求，可以根据个人的习惯。包括详细文档中字段的介绍，像我个人就喜欢用表格管理，修改更方便，不容易乱序。
7）非功能需求
安全需求
统计需求
性能需求
财务需求
跨部门的需求
……
8）运营需求
个人较少接触需要在PRD中写运营计划的项目，对于这部分有详细了解的友友可以贡献一下相关的经验；
后续的运营方式；
后续的运营计划。
结尾：这篇PRD撰写的文章到这里就差不多结束了，还是需要强调切勿生搬硬套，核心掌握大方向的框架构建、以及细节上的流转，关键词应该是逻辑能力、表达能力，学之以“渔”。
编写于：2024/2/26 15:02:27
发布 IP 属地：广东省深圳市
版权声明
阅读：576 点赞：0 留言：0
一、什么是PRD？
PRD就是产品需求文档，取英文Product requriement document 的首字母。
简单来说就是一份用来介绍产品是什么，以及怎么实现的文档。
“产品”：介绍产品
“需求”：阐述需求
“文档”：以文档的形式呈现
产品需求文档 PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。
在整个软件产品的开发，一定是不同部门、不同角色、不同岗位，协同工作的成果；
因此在过程中，也就需要大家各自在自己的职责范围内，完成相应的工作。
MRD、BRD、PRD就是过程中的比较详尽的交付文档，一起被认为是从市场到产品需要建立的文档规范。
MRD：市场需求文档，英文全称Market Requirement Document。
该文档在产品项目中是一个“承上启下”的作用，“向上”是对不断积累的市场数据的一种整合和记录，“向下”是对后续工作的方向说明和工作指导；
BRD：商业需求描述，英文全称Business Requirement Document。
基于商业目标或价值所描述的产品需求内容文档，其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据，是产品生命周期中最早的文档。
二、为什么要有PRD？
为什么要有PRD？PRD又是如何发挥作用的呢？
在将PRD之前，首先讲述一下产品开发的流程中，核心的几个节点：
需求分析——需求确认——功能拆解——流程绘制——原型绘制——PRD书写——PRD讲解——产品开发——测试验收…
需求来源：产品接收业务需求；
需求分析：产品分析需求是否合理，需求价值点；
需求确认：同业务方确认需求；
功能拆解：产品基于业务需求，拆解产品需求；
流程绘制：产品基于需求，明确系统实现流程；
原型绘制：产品绘制原型图，原型相当于产品的一个最初的demo演示；
PRD书写：产品撰写PRD，需书说明PRD中详尽的写了需求的背景、来源、价值；以及包括的功能范围、功能说明；
PRD评审：产品同业务方、开发团队、UI设计等相关部门，基于PRD文档召开需求评审；
产品开发：研发人员基于PRD文档开发代码；UI人员基于PRD设计页面；测试人员基于PRD写测试用例；产品配合各个部门推进需求开发；
……
需求从开始到结束，期间经过了不同的阶段，需求的提出者、需求的实现者并不会一直同时跟进需求的进度。
所以要确保开发出来的需求，满足提出者的诉求，且参与其中的所有人可以理解一致，这个时候就需要PRD把这些需求描述清楚。
开发可以根据PRD获知整个产品的逻辑；
测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。
PRD是项目启动之前，必须要通过评审确定的最重要文档：
保证一致的需求理解；
提高协同的效率；
版本的记录和留存。
三、PRD文档的撰写
产品经理作为一直参与其中的角色，也作为PRD文档的输出者，需要负责PRD的撰写、文档更新、文档版本记录。
PRD文档侧重的是对产品产品功能和性能的说明，相对于业务需求中的同样内容，要更加详细，并进行量化。
不同的公司、不同的项目对需求实现的流程都不太一样，
有的可能是通过MRD进行沟通、有的是依据于BRD、更多的需求可能是一句话的事情，
无论是哪一种形式，最好还是通过一个正式的方式，将业务需求确认下来，
可以避免很多研发过程中的风险，像是拉扯、甩锅……
同样，不同的公司对PRD文档的形式要求也不一样，有的是word文档形式、有的是原型备注说明，需要根据具体的需求场景、紧迫程度来衡量，无论什么形式，PRD的核心的目的，依旧是把事情说明白。
1. PRD的框架
在我们进入一家新的公司之后，写PRD之前，通常都会向同事询问：“我们这里的PRD模版什么样子，发一份给我看看吧。”每个公司都有自己的PRD模版，有标准的页眉、页脚以及内容框架，包括但不限于：
文档的命名和编号
文档的版本历史
目录
需求概述
产品描述
功能需求
非功能需求
运营计划
当然以上内容是按需自取，任何事情都要讲究因地制宜。
实在没有必要为了套模版，一句话换不同角度去描述，长篇大论，反倒影响到需求的传达。
以自己的工作为例，经常用到的模块像是概述、产品描述、功能需求、非功能需求；
像是一些大型项目，验收标准、运营计划都会有单独的文档说明。
2. PRD攥写
1）文档的命名和编号
这个就不用多说，封面的长相排布都大差不差。
主标题：“XXXX需求文档”，主标题直接明了的说明，这是个什么产品、什么需求。讲究排版的童鞋，也自定义可以写一串“Product Requirements Document”上去；
副标题：当主标题无法说明清楚的情况下，可以通过副标题，更清楚的表达需求的范围；
编号：根据公司的要求书写即可。
2）文档的版本历史
文档信息
版本更新历史：用来记录文档版本的更新，以及更新内容，方便协作以及回溯。
3）目录
一方面目录展示了整个PRD的逻辑，以及PRD的需求概览；另一方面也起到了快速检索、快速定位的作用。
4）需求概述
产品概述及目标：简单明了的说明清楚需求的背景、目标、价值点；
文档阅读对象：该文档主要面对的人员范围，已经明确不同阅读对象相关的职责和负责的事项；
运营环境：本次需求涉及到的各个系统的大概说明；
产品风险：目前已存在的风险，需在文档中记录，以及需确保在评审结束后，项目参与人员已周知。
5）产品描述
在产品描述中的内容，为对整个需求的全局描述，一些涵盖全局的需求描述和设计内容，可以在这个模块统一解释说明。
名词解释：PRD文档中经常涉及到很多专业名词，或者是一些长称呼的简写，这些名词解释对理解产品需求至关重要。
为了更方便、快捷的理解，还是希望在整个文档中，可以使用大家都可以共识的词语去定义功能、描述需求；
产品整体流程图：整体的流程图，可以更快更准确的像开发、参与人员传递出需求的全貌。
产品整体流程图的主要目的，是为了方面阅读者理解整个需求的场景、参与的角色、彼此的关联、核心的主流程。
整体的流程图中，主要表明要完成哪些任务、核心节点…任务或者核心节点的拆解，可以不在这个阶段做详细的拆解。
功能清单：功能清单很好理解，即说明清楚这次的文档中，需要实现的产品功能有哪些的，也就是下一章节的内容概览；
关于功能清单，需要考虑的问题包括，以什么维度去拆解、以及拆解的颗粒度；
无论是以场景去拆解、还是系统框架去拆解、亦或是页面逻辑等，依旧是以“因地制宜”、“理解为上”为核心目的。
上述的几个模块是从需求来源、全局角度，对整个需求的概述，方便阅读者快速的理解需求的目的、价值，且达成一致。功能需求章节则是对每个细项功能点的详细描述，不同角色阅读后，可以根据此进行下一步的工作；例如说开发可根据内容，完成任务的拆解以及代码开发；测试可以根据内容，完成任务的拆解以及测试用例的编写等……
6）功能需求
这个模块毋庸置疑，是这个PRD文档核心发力的模块。
首先是要将需求拆解开，比如说本次的需求是完成“商品中心”的搭建，那么就可以拆解为：
商品列表
新增商品
编辑商品
查看商品
删除商品
……
同功能清单一样，拆解的颗粒度按照实际的需求，拆解完成之后，这部分内容就会生成PRD的目录；
因此在进行的过程中可先把需求的层级先梳理清楚，再填充内容。
先搭框架、再填充的步骤，都已经是被大家熟知的方式，无需多说其好处。
框架构建好以后，就该填充内容了，可按照如下的逻辑顺序按需自取，例如在中后台系统的设计中，需要有对角色权限的描述，就需要新增一个权限说明的模块：如果无需以下内容，也可以删减修改。
场景描述：对该功能的业务需求、使用场景的描述；
流程图：该模块的详细流程图，说明清楚任务、节点、流传；
原型图：相当于需求预览图；
详细说明：如何把需求实现出来，对流程图以及原型图的详细说明。
实例说明（*以新增商品为例）：
① 新增商品
A. 场景描述
新增商品主要面向商品运营人员，新商品需上市，需要运营人员将新的商品信息，新增维护进主数据，包括商品的基础信息等。
② 流程图
③ 原型图
④ 详细描述
路径说明：说明清楚到达此页面的路径，如“商品中心-商品列表-新增”。
填写内容：四个阶段说明：“填写基本信息”-“填写包装信息”……（虽然有图片，但是最好通过文字书写出来，防止图片模糊、文案变动造成的差异）。
基本信息说明：详细到每个需要填写的字段；
字段名称：名称
字段类型：输入框、下拉框…
默认显示
填写限制
填写校验
是否必填
提示信息
使用场景
……
下一步：
填写过程中，点击下一步，顶部高亮说明；
点击下一步，保存上一步的内容/不保存说明；
下一步报错说明；
取消：点击取消的说明。
确认提交：
确认校验说明；
确认成功说明；
确认失败说明。
取消/关闭页面：
取消说明；
关闭说明；
……
在详细说明阶段，除去一开始默认的原型图外，在说明的过程中也需要补充许多交互原型图，如校验提示、弹窗、切换、按钮变化、状态的变化等等。在一些状态和页面复杂的需求中，一定要把每个状态的流传定义清楚，包括不同状态下的页面、按钮、交互的变化等。
功能需求这个章节的形式，可根据个人爱好，有的人喜欢word原始的版式，有的喜欢表格区分块；
如无公司强制要求，可以根据个人的习惯。包括详细文档中字段的介绍，像我个人就喜欢用表格管理，修改更方便，不容易乱序。
7）非功能需求
安全需求
统计需求
性能需求
财务需求
跨部门的需求
……
8）运营需求
个人较少接触需要在PRD中写运营计划的项目，对于这部分有详细了解的友友可以贡献一下相关的经验；
后续的运营方式；
后续的运营计划。
结尾：这篇PRD撰写的文章到这里就差不多结束了，还是需要强调切勿生搬硬套，核心掌握大方向的框架构建、以及细节上的流转，关键词应该是逻辑能力、表达能力，学之以“渔”。
编写于：2024/2/26 15:02:27
发布 IP 属地：广东省深圳市
版权声明
本站内容均来自网络转载或网友提供，如有侵权请及时联系我们删除！本站不承担任何争议和法律责任！
每一个童年的梦想都值得用青春去捍卫！