什么是产品需求文档

1. 什么是产品需求文档

无论做什么事都讲究方式方法，写产品需求文档(以下称PRD文档)也是如此，那么什么是产品需求文档呢？下面就来简单的说一下。
  
  1、 该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然，这个定义针对的是一个全新的产品。广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。
 
  2、 PRD的主要使用对象有：开发、测试、项目经理、交互设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前，必须要通过评审确定的最重要文档。
 
 以上就是关于什么是产品需求文档的全部内容。

2. 什么是产品需求文档 产品需求文档是什么

1、产品需求文档是将商业需求文档（BRD）和市场需求文档（MRD）用更加专业的语言进行描述。
 
 2、该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然，这个定义针对的是一个全新的产品。广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能&内容描述等。
 
 3、PRD的主要使用对象有：开发、测试、项目经理、交互设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前，必须要通过评审确定的最重要文档。

3. 如何写一份易用的产品需求文档

我很少会写传统意义上的产品需求文档；甚至，我连word都很少用。用惯了Axure的任意布局方式，再用word感觉非常别扭，尤其是在添加图片时，简直感到捉急。当然，这不是我不用word写需求文档的根本原因。简单来谈一下，为什么软件开发项目中，需要需求文档这么个东西？在稍微大一点的开发团队中，产品经理未必能向所有开发人员，传达具体的产品开发需求。这时就需要一份文档来供所有的项目参与人员阅读。而产品经理又常常爱拍脑袋、容易变卦，所以文档也是开发人员约束产品经理的一项武器。在产品上线前的测试环节，测试人员也同样会拿产品需求文档来验收产品质量。当团队进入新人时，文档也可以让新人更快地了解产品。总的来说，产品需求文档有三个核心作用：
1.传达产品开发需求；
2.保证各部门沟通有理有据，
3.产品质量控制有具体标准
由此可见，产品需求文档是必不可少的。那一份好的需求文档，就应该能准确传达出产品的开发需求。那么产品需求文档该用什么方式写，才能更好地传达出产品开发需求呢？就我所见，行业大多产品经理都是用Word+Axure原型的方式组成产品需求文档。那这种方式，是否真的能方便地表达出产品需求？我问了很多程序猿，他们在开发时，一般都是看着效果图和原型图写代码，只有在遇到问题时，才会查看word文档。也就是说，开发需要一边写代码，一边看效果图，一边看原型，还要时不时查看文档。而且，大多数程序猿都不会逐字逐句去读产品经理的长篇大论。那产品经理写word真的合适吗？这样的用户体验真的好吗？花费大量时间写word真的有价值吗？在Axure画原型的同时，我们为什么不能直接在旁边标注呢？这样岂不是方便快捷很多吗？其实，当下流行一种直接在原型图上标注的需求文档撰写方式。在新版的Axure8中，也已经推荐了原型加标注的需求文档样式。Axure8新增了一组部件—不干贴，就是方便产品设计人员进行功能标注。这份需求文档是我打磨一年，所产出的。目的就是希望打造出一份易于团队协作的产品需求文档。之所以不贴出源文件的下载链接，也是希望其他产品人看到后，可以有所启发，从而做出合适自己团队的需求文档。不发任何原文件或HTML文件。

4. 产品需求文档应该包含哪些内容

我们先假如产品需求文档（PRD）是一个产品，那么该如何做出一个拥有良好用户体验的PRD？
首先先来考察下PRD的用户群体（User Persona）：主要是开发人员，在繁忙的开发任务中最希望看到“简洁易懂”的产品需求文档。
梳理下PRD的功能：
传达出产品需求；
管理记录产品迭代过程；
各部门共享产品信息，以促进沟通；
因此一个好的PRD的原则是：
结构清晰
语言简洁易懂
实时共享
具体我们该如何制作？
答案很简单——一个PRD文档即可
现在，越来越多的产品经理采用将文本说明和原型结合成一个PRD文档的方式，因为之前的word+原型的方式管理起来繁琐，而且还容易产生信息疏漏。
将原型和文本说明统一，直接分享一个链接，开发人员就能看到所有信息，是理想状态。
多级导航结构展示PRD信息
通常来讲，一个产品需求文档里包含“产品概述”、“流程图”、“功能详情和原型”，“全局说明”，“非功能性需求”。
如何把这些内容清晰有条理地呈现在一个文档里呢？使用一个网页般的多级导航结构即可。
1、产品概述产品概述部分用于展示文档修订历史、版本说明、开发周期、和产品介绍。
「文档修订历史」用来记录产品经理对该PRD文档的修改状况，也方便成员能及时了解到PRD是否有改动；
「版本说明」展示上线产品各版本的核心功能；
「开发周期」用于梳理开发、测试、上线的预计开始和结束日期。
「产品介绍」用来记录产品名称、简介、用户画像、使用场景、产品定位等等。

（墨刀“PRD模版A”中的“版本信息”模块，by 小龙）
2、流程图流程图是产品经理梳理产品逻辑和功能的一个思维Map，一般会有“功能结构图’、“信息结构图”、“任务流程图”。
「功能结构图」 展示产品的功能模块，一般展开用户可见的最小单元。
「信息结构图」则是以信息为维度，用来描述有哪些数据字段，展现用户信息/行为信息等。
「流程图」记录着用户使用产品的路径，也是一种产品线路图，展示着产品的所有页面及对应关系，有助于产品理解。

（墨刀“PRD模版A”中的“结构图”模块，by 小龙）
3、功能详情和原型这个模块是开发人员查看频率最高的模块了。目前一种快捷高效的呈现方式便是“原型”+“注释”。
图文互补，把图片传递不了的信息用文字补充清楚，比如产品的一些使用逻辑，方便同事理解。
使用墨刀的话，可以创建一个大的画布，然后把墨刀制作的原型页面粘贴到画布里，并添加文字注释，在关键位置有一些边界条件的说明。
或者，直接在产品原型项目里通过“批注”添加注释。

（“PRD模版A”中的“交互原型”模块，直接嵌入了墨刀原型，by 小龙）
4、全局说明这个页面用来展示整个产品的设计规范，一些通用的规则可以附在这里。
对于这点，使用墨刀制作的方便之处在于：
可以直接把有关设计规范的原型项目通过网页链接的方式嫁接过来，还能点击“标注”查看各元素的细节信息。

（ 墨刀“PRD模版A”中的“全局说明”模块，by 小龙）
5、非功能性需求对于不同类型的产品，非功能性需求会有各种差异，一般会涉及到的有：
性能需求
系统需求
运营需求
安全需求
统计需求
财务需求
……
这部分就要自己按需要调整。
总结 PRD作为一种重要的公司内部沟通的文档，能把必要的信息汇集在一个逻辑清晰的结构里是提高工作效率的一个优势。语言上的简洁易懂，再结合可视化的结构图和原型，都是为了增强易读性，让沟通更高效。
把PRD当作一个小产品去打磨一下，不是浪费时间，一个好的PRD文档可以继用很久。
墨刀新出了两种产品需求文档的模版，这两种PRD里的各级页面内容、导航和交互都为大家设计好了。
现在大家可以点击“创建项目”，从墨刀模版中选取“产品需求文档A”或者“产品需求文档B”，点击“使用模版”，再按照自家产品需要做一些更改就okay！

通过墨刀的分享链接还能直接让公司内部人员在线实时同步PRD的更新，不用再担心信息滞后或者文档不兼容问题。
让我们着手开始创建或者优化您的产品需求文档吧～希望采纳！谢谢！
配图来自  “运维派”以及墨刀官网截图

5. 产品需求说明书 模板

新人建议收藏
  
 链接：https://pan.baidu.com/s/1pInly_b9oGUTGZaO2226zA
 密码：r1an
                                          
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
  文档版本号： 1.0文档编号：2018080910
  
 文档密级：仅限项目组归属部门/项目： 
  
 产品名： 子系统名： 
  
 编写人：Xxx编写日期： 
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
 
  
  
    
  
    
  
    
  
    
  
  修订记录： 
  
  版本号  修订人  修订日期  修订描述 
  
 V 1.0   
  
       
  
 
  
  
 
  
  
 
  
  
  目录 
  
  一、 简介    4  
  
  1、 目的 4 
  
  2、 范围 4 
  
  二、 用户角色描述    4  
  
  三、 产品概述    4  
  
  1、 目标 4 
  
  2、 总体流程 4 
  
  3、 功能摘要 4 
  
  四、 产品特性    5  
  
  1、 第一部分  功能模块1 5 
  
  1.1产品概述 5 
  
  1.2产品结构（功能摘要） 5 
  
  1.3状态说明 5 
  
  1.4特性说明 6 
  
  1.4.1特性1：功能点1 6 
  
  1.4.2特性2：功能点2 9 
  
  2、 第二部分  功能模块2 9 
  
  2.1产品概述 9 
  
  2.2产品结构（功能摘要） 9 
  
  2.3状态说明 9 
  
  2.4特性说明 9 
  
  2.4.1特性1：功能点1 9 
  
  2.4.2特性2：功能点2 10 
  
  五、 其它产品需求    10  
  
  1、 性能需求 10 
  
  2、 监控需求 11 
  
  3、 兼容性需求 11 
  
  六、 风险分析    11  
  
  七、 相关文档    11  
  
  八、 附件    11  
  
    
  
 
  
  
 
  
  
 
  
  
 
  
  
  [if !supportLists]一、 [endif] 简介  
  
  [ 产品需求说明书 文档的简介应提供整个文档的概述。它应包括此 产品需求说明书 文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。]
  
  [if !supportLists]1、 [endif] 目的  
  
 [阐明此产品需求说明书文档的目的，如：
  
 本文档为“陌生视界v1.0.0”的产品需求文档，主要作为确认需求以及系统分析设计的依据。]
  
  [if !supportLists]2、 [endif] 范围  
  
 [简要说明此产品需求说明书文档的范围、它的相关产品，以及受到此文档影响的任何其他事物。]
  
  [if !supportLists]二、 [endif] 用户角色描述  
  
 用户角色用户描述
  
       
  
       
  
       
  
  [if !supportLists]三、 [endif] 产品概述  
  
 [此节高度概括产品的功能与介绍]
  
  [if !supportLists]1、 [endif]   目标  
  
 [描述产品的目标]
  
  [if !supportLists]2、 [endif] 总体流程  
  
 [描述产品的总体流程图]
  
  [if !supportLists]3、 [endif] 功能摘要  
  
 [简要描述产品的功能点和每个功能点的优先级，参考格式如下]
  
 
  
  
 功能模块主要功能点功能描述优先级
  
 功能模块1功能点1 高
  
 功能点2 中
  
 功能模块2功能点1 低
  
  [if !supportLists]四、 [endif] 产品特性  
  
 [列出产品的特性。特性是为让用户获益而必须具备的高级系统功能。每一项特性都是外部所需的服务，它通常需要一系列输入来实现预期的结果。
  
 此节为设计的系统功能性需求,一般以用例结合自然语言来表达。此节通常按特性来组织，但也可能会有其他适用的组织方式，例如按用户或子系统组织的方式。
  
 这一节应包含所有的产品需求，其详细程度应使架构设计人员和软件需求设计人员能够设计出可以满足这些需求的系统，不包括可选流程和异常流程，不对具体语义做约束。]
  
  [if !supportLists]1、 [endif] 第一部分  功能模块1  
  
  [if !supportLists]1.1 [endif] 产品概述  
  
 [概述功能模块1的产品特性及效果]
  
  [if !supportLists]1.2 [endif] 产品  结构（功能摘要）  
  
 [概述功能模块1的产品结构或包含组件，如：
  
 [if !supportLists]1) [endif]播放区：播放区定义及功能说明；
  
 [if !supportLists]2) [endif]缓冲区：缓冲区定义及功能说明；
  
 [if !supportLists]3) [endif]播放列表区：播放列表区定义及功能说明；]
  
  [if !supportLists]1.3 [endif] 状态说明  
  
 [列出产品的各种状态及状态转换图，如：
  
 [if !supportLists]1) [endif]状态1：状态1定义及可执行操作说明；
  
 [if !supportLists]2) [endif]状态2：状态2定义及可执行操作说明；
  
 状态转换图：
  
 ]
  
  [if !supportLists]1.4 [endif] 特性  说明  
  
  [if !supportLists]1.4.1 [endif] 特性1：功能点1  
  
  用户场景： 
  
 [列出用户通过什么操作或途径触发功能点1，如：
  
 用户点击大学生社区—行政楼，或者点击其他引导到该板块的链接]
  
  输入  /  前置条件： 
  
 [列出用户触发功能点1的前置条件和必要条件，如：
  
 用户已登录，且为社团成员]
  
  流程说明： （用例图、流程图）
  
 [通过用例图、流程图的形式，对功能点1的流程进行说明，如：
  
 ]
  
  需求描述： 
  
 [详细描述功能点1的具体需求，包括约束条件、输入输出、排序规则、状态转换等等，如：
  
 当用户点击“行政楼”菜单时，展示学校的新闻中心和管理层介绍，大致示意图如下：
  
 
  
  
 
  
  
 行政楼主要版块包括：
  
 [if !supportLists]1. [endif]新闻发布中心
  
 新闻发布中心主要展示编辑后台发布的校园新闻及系统公告；
  
 列表形式按发布时间由近到远顺序展示，默认显示前若干条（具体条数视最终页面设计）]
  
 
  
  
  补充  说明：  
  
 [相关需要特殊说明的补充事项]
  
 
  
  
  [if !supportLists]1.4.2 [endif] 特性  2：功能点2  
  
  用户场景： 
  
 
  
  
  输入\前置条件： 
  
 
  
  
  流程说明： （用例图、时序图）
  
 
  
  
  需求描述： 
  
 
  
  
  补充  说明：  
  
 
  
  
  [if !supportLists]2、 [endif] 第  二  部分  功能模块2  
  
  [if !supportLists]2.1 [endif] 产品概述  
  
 
  
  
  [if !supportLists]2.2 [endif] 产品  结构（功能摘要）  
  
 
  
  
  [if !supportLists]2.3 [endif] 状态说明  
  
 
  
  
  [if !supportLists]2.4 [endif] 特性  说明  
  
  [if !supportLists]2.4.1 [endif] 特性1：功能点1  
  
  用户场景： 
  
 
  
  
  输入\前置条件： 
  
 
  
  
  状态说明  ： 
  
 
  
  
  流程说明： （用例图、时序图）
  
 
  
  
  需求描述： 
  
 
  
  
  补充说明： 
  
 
  
  
  [if !supportLists]2.4.2 [endif] 特性  2：功能点2  
  
  用户场景： 
  
 
  
  
  输入\前置条件： 
  
 
  
  
  状态说明  ： 
  
 
  
  
  流程说明： （用例图、时序图）
  
 
  
  
  需求描述： 
  
 
  
  
  补充说明： 
  
    
  
  [if !supportLists]五、 [endif]   其它产品需求  
  
 [从业务视角提出各项可用性指标的大致需求。具体的技术指标会体现在产品的设计文档中（根据项目实际情况增删）]
  
  [if !supportLists]1、 [endif]   性能需求  
  
  [ 如果产品对性能要特殊需求，请详细描述，如：大致响应时间、最大并发数等。]
  
  [if !supportLists]2、 [endif]   监控需求  
  
 [如果产品需要特殊的监控和统计，请详细描述，如：PV、点击、登录数等。]
  
  [if !supportLists]3、 [endif] 兼容性需求  
  
 [如果产品需要对兼容性提出特殊的需求，请详细描述，如：兼容IE8、Chrome等。]
  
  [if !supportLists]六、 [endif]   风险分析  
  
  [风险内容描述，说明风险产生原因，可能造成的危害以及相应出现的频率信息，另外在此处还需要描述相关风险预防措施及风险出现后的应对措施信息。此处不包括任何系统技术实现层面的风险，例如：系统的备份，监控，模块依赖，etc.] 
  
 风险可能性严重性应对策略可应对性
  
 
  
  
 
  
  
 
  
  
  [if !supportLists]七、 [endif]   相关文档  
  
 [产品所需的其余相关文档，如：产品市场需求说明书（MRD）、产品功能介绍PPT、产品规划书。]
  
  [if !supportLists]八、 [endif] 附件  
  
 [将产品需求的demo作为附件。]
  
 m

6. 产品需求文档应该包含哪些内容

规范化软件开发过程中的《需求说明书》的编写，使之成为整个开发工作的基础。

2 适用范围

本规范适用于集团开发项目的（软件）《需求说明书》的编写。

3 编写内容提示

1 引言

3.1.1 背景说明

说明被开发软件的名称，任务提出者，用户及实现该软件的计算机网络。

3.1.2 参考资料

列出有关资料(名称，发表日期，出版单位，作者等)。

3.1.3 术语和缩写词

列出本文件中用到的专门术语的定义，及术语缩写词。

3.2 软件总体概述

3.2.1 目标

软件开发的意图、应用目标、作用范围以及需说明背景材料。

3.2.2 系统模型

图示说明该软件的所有功能及其相互关系和数据传递情况。

3.2.3 假设和约束

说明影响软件开发、运行环境和系统能力（如预告出错类型的能力）的某些假设和约束。3.3 详细需求

详细描述此软件系统的功能需求和性能需求。

3.3.1 功能需求

对系统中每一个功能，要详细描述（图示或文字）。

概述 叙述功能名称，目标和作用。 
输入 输入该功能的信息。 
处理 描述该功能做什么，如何对输入信息进行加工并转换成输出信息。 
输出 列出内部生成的文件。

3.3.2 性能需求

定量地描述此软件系统应满足的具体性能需求。可考虑以下方面：

3.3.2.1精度

说明系统的精度要求，如：

数据的精度要求。 
数字计算的精度要求。 
数据传送的误码率要求。

3.3.2.2 时间特性

说明系统的时间特性要求，如：

解题时间。 
询问和更新数据文件的响应时间。 
系统各项功能的顺序关系。

3.3.2.3 灵活性

说明当需求发生某些变化时系统的适应能力，指出为适应这些变化而需要设计的软件成分和过程。

3.3.2.4系统容量

包括系统的设计容量和理论（计算）容量。

3.3.3 输入和输出

解释各输入输出数据类型，并逐项说明某媒体、格式、数值范围等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。

3.3.4 数据管理能力

说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作估算。

3.3.5 故障处理

列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

3.4 环境

描述所开发软件运行所需的环境。

3.4.1 设备环境

描述运行软件系统所需的设备能力，如：

处理器的型号和内存容量。 
存储媒体的数量。 
通信网络（包括说明网络结构，线路速度及通讯协议等）。

3.4.2 支持软件环境

列出与待开发的软件互相配合的支持软件（包括名称，版本号和文件资料），必要时还应列出测试软件，还要指出该软件用的编程语言，编译程序，操作系统和数据管理系统。

3.4.3 接口

说明本软件与其他软件之间的接口、数据通信协议等。

3.4.4其他

说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。

7. 如何写一份易用的产品需求文档？

产品需求文档分很多种，这里我只说一种让程序员看起来舒服的需求文档格式吧：
作为程序员，在需求文档当中，最关注的内容是哪几种呢？1、流程：包括业务流程和基本流程；2、数据：包括输入数据和展示数据；3、事件流：特别是分支事件流和例外事件流，感觉很多需求文档中，缺少了这部分；
那么，文档的模板是怎么样的呢？1、需求说明：主要阐述为什么要做这个需求；2、业务流程：最好使用VISIO来绘制，画出整个业务的流程图，特别是其中所要涉及的判定，分支等，都要画出来，越详细越好；3、基本流程：继续使用VISIO，画出基本流程即可，一般来说都是业务流程中的最主要部分，但是可以加入更多的细节；4、分支事件流：VISIO，各种分支事件的详细流程，越详细越好；5、例外事件流：这里要使用表格，示例如下：主要是系统判定和对应的提示；6、输入数据：用户可以输入数据的字段，已经相应的定义，包括是否必填，字段长度，录入方式，对应规则等；7、显示数据：页面显示给用户的数据，对应的字段，取数规则，对应规则等;8、补充说明；这个需求文档模板，更倾向于传统的软件模板，而不是网络上比较流行的AXURE文档。

8. 产品需求文档都包含哪些内容？

产品需求说明文档大致有下面9个内容:
目录、修订记录、产品概述(产品背景、产品定位、用户定位)、业务流程图、产品结构图、需求清单、需求明细、其他内容，非功能性需求。
有关上述文档的内容还有更详细的分析，看看传智播客的课程吧。我在传智学的产品，现在在互联网公司做产品。