产品需求文档到底该怎么写？【转】

（转自：https://blog.csdn.net/wendy356115510/article/details/51404468）

博主作为一名产品小白，也被产品需求文档折腾的死去活来，网上也难找一个完美的模板。那么，作为产品需求文档，到底该怎么写，才能让设计让开发都能清晰的了解呢？

产品需求文档，主要目的是说明需要开发的产品功能、UI、交互、性能、运营等要求。产品需求文档质量的好坏，在很大程度上不仅直接影响着研发部门是否可以明确产品的功能和性能、运营部分是否能明确产品的运营思路，而且在很大程度上决定了产品的最终质量。

一、文档的主要内容

产品需求文档，主要包括两部分：一是对项目的介绍，包括项目概述、项目价值、项目背景、用户群体、产品定位、名词解释等；二是对产品需求的详细描述，包括功能需求和非功能需求。

       下面是一份比较常见的产品需求文档结构：

 

  目录

1.项目概述

2.项目价值

3.项目背景

4.功能概述

4.1场景描述

4.2功能总表

4.3业务流程图

4.4 功能描述

4.5 数据监控需求

5.用户界面

6非功能需求

7.附录

二、产品功能描述

 

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

简要说明：介绍此功能的用途，包括其来源或背景，解决什么问题，功能的目的。

场景描述，产品在哪种情况下会被用户使用，就是用户场景设计。

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

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

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

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

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

主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明(这是非常重要的)。

三、产品需求文档基本要求

 

一份优秀的产品需求文档应该满足五个方面的要求：完整、准确、清晰、简洁、稳定。

完整：确保必要内容无遗漏，功能描述完整；

准确：表述没有歧义，不会出现“可能”、“或者”等模棱两可的词；

清晰：文档结构清晰、表述不含糊、版本管理清晰；

简洁：语言简练、图文结合方便阅读；

稳定：开发前对内容进行充分确认；

--------------------- 本文来自 love-pm 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/wendy356115510/article/details/51404468?utm_source=copy