产品需求文档（产品需求文档中不包括）

本文目录

• 产品需求文档中不包括
• 产品需求文档不包括
• prd文档是什么
• PRD产品需求文档_PRD产品需求文档
• 产品经理写需求文档的意义是什么
• 产品设计-（5）需求文档

产品需求文档中不包括

产品需求文档中不包括：测试内容。

产品需求文档的要素： 

1、文档的命名和编号：文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。

2、文档的版本历史：包括，编号、文档版本、章节、修改原因、日期、修改人。

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

4、引言：这部分的内容有：产品概述及目标、产品roadmap、预期读者、成功的定义标准和判断、参考资料、名词说明。

5、需求概述：需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等等。 

6、功能需求：功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容：简要说明、场景描述、业务规则、界面原型、使用者说明、前置条件、后置条件、主流程。

7、效益成本分析：通过这一点上能看出产品经理必须是个全才，不仅要具备行业知识，还需要有财务知识。一个产品的成本衡量一般包括三个方面：效益预测、产品技术成本和其他成本支出。 

8、整合需求：产品整合能力是产品经理很重要的一个能力，业务合作通常是不可避免的，将隶属于两个不同来源的业务功能做整合也是常见需求。 

9、BETA测试需求：很多产品在正式上线前都有BETA版本或者内测版本，或者叫灰度版本，目的是在测试产品的一些核心功能或者性能。这部分内容不是必须的，但如果需要，需要给出在此阶段要实现的目标或测试、衡量标准。

10、非功能性需求：一般情况下非功能性需求包括以下几个部分：产品营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等。这些信息构成了产品上线的完整内容，也很好的体现了产品经理的综合素质。

11、运营计划：产品上线后如何运营，目标受众是什么，建议的推广策略、问题反馈途径、风险监控、亮点宣传等等，以及与运营人员的协作方式。作为产品的设计人员不是开发完产品就能画句号的，让产品用起来、用得好，有口碑更为重要，所以非常建议运营计划的制定上有产品设计人员的参与。

产品需求文档不包括

产品需求文档不包括测试内容。

1、PRD（Product Requirement Document）即产品需求文档，是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。

2、在产品项目中，PRD有“喊差承上启下”的作用，“向卜知上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。

3、在该文档中，基点依然是MRD中的内容，只是把重型渗消心放在了“产品需求”上，而产品需求本身是在MRD中有所体现的。

4、然而区别就是在于，PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。

差异对比：

1、BRD不同于常见的MRD和PRD，既然是用于产品实施之前的决策评估依据，必然对其文档（报告）的内容和格式要求够直观、精炼，要点突出。

2、作为报告的撰写者，你必须让高层明白，你的报告中将展现出怎样的商业价值，如何用有力的论据来说服企业对你这个项目的认可，并为之慷慨的投入研发资源及市场费用。

3、如果说PRD的好坏，直接决定了项目的质量水平，那么BRD的作用，就是决定了你的项目的商业价值。

4、优秀的BRD文档，可以让决策层充分被你的报告观点所吸引，或许财务主管会因为报告呈现的低投入高产出的经济效益预测而蠢蠢欲动。

prd文档是什么

prd文档是指产品需求文档。

产品需求文档是产品项目由“概念化”阶段进入到“图纸画”阶段的最重要的文档，其作用就是对MRD（市场需求文档）中的内容进行指标化和技术化，这个文档的质量直接影响到研发设计部门是否能够明确产品的功能和性能。

prd文档是将商业需求文档和市场需求文档（MRD）用更加专业的语言进行描述。在该文档中，基点依然是MRD中的内容，只是把重心放在了产品需求上，而产品需求本身是在MRD中有所体现的，区别就是在于，PRD要把MRD中的产品需求的内容独立出来加以详细的说明。

优秀PRD文档的特点

确保文档中的表述与产品经理的思路是对应且正确的。获得授权后，而且已经确定了要走的路线，剩下的就是打造产品了。把产品的需求给研发人员，对产品的要求讲清楚。文档的表述方便阅读理解，不会产生歧义。MECE原则尽量保证对产品功能需求表述的系统完整。

文档中用词用语一致，对于同一失误的表述应该一样，避免混用同义词。产品的功能需求是有先后主次的，对于一次性规划多功能，应该注明功能性需求的先后主次。

对于功能性的描述，是可以进行测试的，可以验证的。利于后期的修改与升级，每个功能性需求的来源应该清晰明了。

PRD产品需求文档_PRD产品需求文档

PRD产品需求文档(ProctRequirementDocument，PRD)的英文简称。是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。文档撰写在该文档中，基点依然是MRD中的内容，只是把重心放在了“产品需求”上，而产品需求本身实在MRD中有所体现的，区别就是在于，PRD要把MRD中的“产品需求”的内容独立出来加以详细的说明。

这部分是PD写得最多的内容，也就是传统意义上的需求分析，我们这里主要指UC（usecase）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块），Visio做的功能点业务流程，界面的说明，demo等。Demo方面，可能用dreamweaver、ps甚至画图板简单画一下，有时候也会有UI/UE支持，出高保真的demo，开发将来可以直接用的那种。

文档核心：

该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。

在一些国外的公司，是允许把MRD和PRD合并成一个文档的，通常叫做“Marketing&ProctDocument”。错误认识1）PRD无原始数据（MRD为体现载体）支持，只是个人经验、部门要求或者领导指示进行撰写。

2）在PRD中，只重视“产品功能”的描述，而缺乏对产品其它指标项的说明。在一个完整的PRD中，一共需要对产品的10个产品需求项指标进行说明，分别是“功能要求、开发要求、兼容性要求、性能要求、扩展要求、产品文档要求、产品外观要求、产品发布要求、产品支持和培训要求、产品其它要求”。

3）照搬国外的PRD模板，来源于何处，不知道，将去向何处，也不知道，无头无尾，一个被割裂的文档。VISIO概述MicrosoftOfficeVisio2007是微软公司出品的一款的软件，它有助于IT和商务专业人员轻松地可视化、分析和交流复杂信息。它能够将难以理解的复杂文本和表格转换为一目了然的Visio图表。该软件通过创建与数据相关的Visio图表（而不使用静态图片）来显示数据，这些图表易于刷新，并能够显著提高生产率。使用OfficeVisio2007中的各种图表可了解、操作和共享企业内组织系统、资源和流程的有关信息。Axureaxure概述AxureRP能帮助网站需求设计者，快捷而简便的创建基于网站构架图的带注释页面示意图、操作流程图、以及交互设计，并可自动生成用于演示的网页文件和规格文件，以提供演示与开发。

产品经理写需求文档的意义是什么

1、需求文档是产品管理26个常见文档之一，先说说大的意义，一句话：产品文档管理就是产品管理工作流程的唯一线索；

2、接下来再说说需求文档，《产品需求文档》是产品经理产品战术工作-图纸化的输出物，它上一个文档是《市场需求文档》，《产品需求文档》主要作用是确定产品规格，指导研发、UE、UI、测试部门进行工作；

3、大家可以从《产品需求文档》内容去理解它的意义，具体就不细说了。

产品设计-（5）需求文档

PRD(Product Requirements Document)通过文字的形式将产品的需求特性与逻辑描述出来。

需求文档定位，就是把我们之前做过的所有东西除了UI设计之外都囊括进来，把它文档化的点。

 我的产品规划是什么、我的产品发展方向是什么、我的阶段性目标是什么、Feature List是什么、可能把有些图也要附上来、交互设计的原型也要附上来，把他文档化的点。它是最基本的、最基础的、归档性质的文档。

 需求文档，产品经理必须能写。

回顾整个流程：从市场分析、竞品分析、用户分析反馈、产品数据收集到很多需求到需求池，周期性的到需求池。再加上目标、阶段性的目标，加上产品规划的因素，得到RoadMap，下一阶段做什么、重点做什么、下个版本做什么，再到画原型，然后再到写需求。画原型与写需求没有强的先后顺序，先画原型，更方便理解。

需求文档给谁看？自己、开发人员、测试人员、项目经理、运营人员、设计人员、其他产品经理。

 需求文档的作用是什么？

1.传达产品开发需求

 2.保证各部门沟通有理有据

3.产品质量控制的具体标准

4.归档

为什么有了原型还要写需求？原型大部分表达的偏正向的，背后的逻辑需要写到需求文档，有些是很底层的逻辑无法通过原型表达。

需求文档的主要结构

 1.需求背景、项目目标：简单介绍背景，明确项目目标

2.核心内容

  需求列表：版本需求清单-Feature List

  逻辑展示：功能流程图、原型图

  详细逻辑描述：文字化描述细节、边界逻辑

3.性能需求、数据需求：根据需求情况撰写

需求文档包含哪些内容 :

1.修订记录

(1)标题 更新版本号，方便区分查阅

(2)修订记录 备注更新时间 区分版本号 描述改动内容（删除注明） 写明撰写人员 注

意颜色：每次修改用不用的颜色，方便查阅

2.目录

目录，要把章节的区分清楚。章节的区分有主章节和次章节的区分。1.1、1.2为同一个层次的、同一个平级的逻辑，把相似的逻辑放一起。哪些是并行的，哪些是串行。V1.1 V1.1.1 V1.2 V1.2.1 V1.2.2

3.需求背景及目标

需求背景：让大家了解为什么要做

项目目标： 可量化的目标让大家更清楚价值 上线后验证数据完成情况的依据 项目目标尽量可量化

4.功能特性列表

 拆分标准：内部功能模块的划分、重要的部分特性单列、数据需求，技术需求单列

特性列表的作用：对涉及的模块有一个初步的认知、方便参与者理解需求并开发需求

5.需求表达

需求表达，可以考虑图+文字的形式，只写文字比较生硬，把流程图和原型图放上去，增加理解。注意图文的配合。

图+文字的发挥各自优点，防止细节遗漏。

6.细节逻辑文字撰写

描述细节功能点 描述正常逻辑、不同状态的逻辑 描述异常逻辑 描述边界情况 描述性能指标 细节逻辑描述的作用 开发、测试的关键依据

例如：登录 写一个基础登录的逻辑描述，写出正常逻辑、异常逻辑、边界情况。

7.性能需求

 打开速度、服务器访问速度、Crash率 、负载能力

8.数据需求

注意：埋点数据不可逆！！！

首先埋点，有三类数据埋点：按钮点击、基础数据、页面路径，怎样分别进行埋点，埋点的逻辑，需要考虑清楚。

然后分析数据。