产品需求文档

一、产品需求文档

产品需求文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。

PRD的主要使用对象有：开发、测试、项目经理、交互设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前，必须要通过评审确定的最重要文档。是向研发部门说明产品功能和性能指标。

  二、产品需求文档的要素

  （一）文档的命名和编号

每个产品都是经过若干个迭代才完成的，需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。文件命名方法一般是通过版本号定义。

  （二）文档的版本历史

包括，编号、文档版本、章节、修改原因、日期、修改人。编号只是为了记录修改的顺序，文档版本显示的当前修改的内容属于文档的第几个版，章节是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修改原因说明为什么要修改该需求。

1、目录，目录是用来了解文档结构的，文档完成后直接更新模版中的目录即可。

2、引言

（1）产品概述：解释说明该产品研发的背景以及核心功能。

（2）产品roadmap：为产品规划的蓝图，每个关键阶段完成的核心任务。产品研发是

个不断迭代的过程，需要经过若干个版本的迭代，，对一个功能点做了N个迭代后最终又回归到了第一个迭代是很常见。产品经理需要做好心理准备。产品roadmap并不需要全部规划好所有的阶段目标，但是对产品未来发展趋势的一种预估，要达到目标，需要更多的更新和迭代。清晰的呈现产品的roadmap可以帮助产品经理把握产品的全貌，更好的控制研发过程。

（3）预期读者：文档的使用对象

（4）成功的定义和判断标准：旨在说明产品的目标

（5）名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是

对这些名称进行解释。

  3、需求概述

（1）需求概览：分两部分，一是业务流程图，对产品整个业务流程的发生过程做图形化的展示，是对产品整体功能流程的阐释。二是需求清单，对本次要开发的需求任务做分类，给出简明扼要的需求描述并标注优先级。

    （2）用户类与特征：产品的最终用户，确定产品的最终使用者，并对使用者的角色和操作行为做出说明。

（3）运行环境：该产品上线后的使用环境，比如支持的浏览器及其版本，操作系统、

数据库的要求等等，测试人员在看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运营环境告知给用户。设计和实现上的限制：比如控件的开发环境、接口的调用方式等等。

（4）项目计划：对于prd中要开发的内容，给出关键里程碑，比如需求评审通过的时

间、开发的完成时间、上线时间等等。

（5）产品风险：描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不

当使用的风险等等。

  4、功能需求

功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容：

（1）简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题。

（2）场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。

（3）业务规则：每上产品在开发时都有相应的业务规则，将这些规则清晰的描述出来，

让开发、测试人员能够直观的明白该规则，且没有产生歧义。业务规则必需是完整的、准确的、易懂的。业务规则的描述上如果涉及到页面交互或者页面的修改，建议给出页面的草图或者页面截图在图上说明要修改的内容。另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明，什么时候可见，不可见，灰掉或点亮的条件在文档中都给出说明。方便理解业务规则。

（4）界面原型：如前所述，涉及到页面交互的部分，产品经理需要设计页面原型。原型设计通常需要产品经理和UI设计师一起来完成。建议的做法是，产品经理可设计一个页面框架，将该页面要呈现的字段及其特征以及页面要使用的场景向交互设计师解释清楚。之后交互和视觉设计师完成产品的原型设计。

（5）使用者说明：对产品使用者做出说明，可融入简要说明中。

    （6）前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像文件。

（7）后置条件：操作后引发的后续处理。

（8）主流程：做出主流程说明，对每个功能流程走向分点说明。

开发和测试中提出的各类问题均与对分支的定义不明有关。一个合格的PRD不仅要描述主流程，同时对分支流程所出现的各类问题都要做详细阐述并给出解决办法。

  5、效益成本分析

产品经理不仅要具备行业知识，还需要有财务知识。一个产品的成本衡量一般包括三个方面：效益预测、产品技术成本和其他成本支出。效益预测是指所提供的功能在未来能产生的效益，可通过对比以往的产品或者竞争对手的产品来做预估，效益预测的指标，如每个功能点的潜在用户数、使用频率，吸引到的新的用户特征及数量。产品技术成本是指研发设计以及上线后的运营需要的资源需求，包括人力，软硬件(带宽、服务器、机房)支出。其他的成本还包括支持成本，比如上线后的运营资源投入、市场推广投入以及客服服务投入等。

  6、整合需求：系统登陆使用公司的域用户登陆，或者付款使用财付通、支付宝付款，解决好整合需求也是体现产品经理核心竞争力的一大重要表现。

  7、BETA测试需求

产品在正式上线前有BETA版本或者内测版本，或者叫灰度版本，目的是在测试产品的一些核心功能或者性能。需要给出在此阶段要实现的目标或测试、衡量标准。非功能性需求：产品营销需求、运营需求、财务需求、法务需求、使用帮助、问题反馈等。这些信息构成了产品上线的完整内容，很好的体现产品经理的综合素质。

 8、运营计划

产品上线后如何运营，目标受众，推广策略、问题反馈途径、风险监控、亮点宣传等等，以及与运营人员的协作方式。需求不是一成不变，在产品研发过程中需求变更正常，在做需求分析时，尽可能把每个问题都考虑透彻，提前做好需求变更的预估及应对方案。

主要内容：即传统意义上的需求分析，主要指UC（use case）文档。主要内容有，功能使用的具体描述（每个UC一般有用例简述、行为者、前置条件、后置条件、UI描述、流程/子流程/分支流程，等几大块），Visio做的功能点业务流程，界面的说明，demo等。文档核心侧重于对产品产品功能和性能（即“产品需求”）的说明。

四、产品需求文档的写作方法

 （一）写前准备

1、先罗列出产品功能的信息内容，文本形式、思维导图形式等等都可以。

例如文章的信息内容有：文章标题、文章正文、文章作者、发布时间、所属分类等，在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减。

2、梳理需求，让想法更加结构化。先要罗列出产品的频道及页面(产品结构图)，其次再基于产品结构图梳理出频道及页面中的功能，并延伸构建出用户的操作流程(用户流程图)。

 （二）原型设计

产品的原型，移动产品可以考虑灰模原型，网站产品可以考虑交互原型，具体取得于个人习惯和团队要求。原型设计是为了帮助细致方案，并论证方案的可行性。

 （三）撰写文档

一般情况下，通过原型加描述的方式就已经完成了PRD文档的目的。有些个人或团队要求不一样。