标准的产品需求文档在这里！（详细说明版）

虽然word的需求文档已经逐渐被Axure等原型设计稿所替代，但关于word需求文档，在许多公司还同样在使用，一份专业且精致的需求文档能提升面试官对自己的认可度，废话不多说，下面开始讲解标准的需求文档该怎么写，我会一步步带领大家慢慢写出专业的需求文档，并告知专业需求文档的书写细节。

在书写之前，首先要给大家科普一下，需求文档是以需求为单元的，即一个需求（无论大小），则为定义为一份文档，比如一般不会把一个APP从零到最终都写在一份文档，而应该是迭代的文档，不是累积的文档，比如APP新增一项功能，就可起一份需求文档，再多一个其他功能，那就是另一份文档。

比如本期的例子，在某个APP中新增浏览历史的功能，则以这一份为一份需求文档。同学们可以触类旁通，其他功能的需求文档也是参照这么来写。

总览一下需求文档所包含的内容：

信息量有点大，建议收藏慢慢阅读。

这里我给大家推荐一款非常方便的PRD文档制作工具摹客

摹客是“设计+协作”的一站式云平台。摹客支持产品文档在线撰写，你可以新建或上传文档，文档中RP设计稿和流程图可以自动更新。PRD文档支持在线评审，能极大提升团队沟通效率。除开撰写PRD文档，通过摹客，你还可以免费制作高保真原型图、流程图，海量模板一键复用。

封面

先写一个标题，可以叫需求分析说明书，可按照公司要求来定，自由发挥。

再写一个文档编号，方便日后存档看，可以英文加数字，数字可以用年月代替，具体含义表示为是某年某月写的需求文档。

起一个用例描述，描述本次需求文档是实现什么功能，比如本期例子为：我的页面新增浏览历史功能，只要方便大家看得懂，一看标题就知道要做什么就可以了。

修改历史记录

再写一份修订历史记录，注意修订历史记录是发布1.0版本的需求文档后，如果发生了变更，才增加1.1版本，并且告知所有团队成员需求文档有变更，自己在没发第一版本的文档之前所做的修改都不要记录为历史记录，不然修订历史记录会很长，而且可以几个修订历史记录的改动点都积攒到一起改，当然需求文档是追求发布了，如果要修改就要非常谨慎，不然你随意改动开发人员会想抓住产品打，当然也是不利于项目开发进度。迫使产品经理在写需求文档时想清楚再写。

目录

目录不多说，当word的层级建立好之后，word能自动生成目录，不懂怎么操作得去学习一下word的使用技巧，本文不针对word的使用进行讲解。

1. 摘要

先来个大大的标题，然后再讲讲怎么写摘要。从这里开始就是正文啦。

标题不用多说了，摘要主要分为五部分：适用对象、业务背景、实现范围、关键词和重要说明风险。

1.1 适用对象

可以简单一句话描述一下，比如是适用于企业员工，或者面向C端用户，这样就简洁明了了的了解了谁会用到这个功能。

1.2 业务背景

一两句话介绍一下为什么要做这个需求，出于什么背景和目的等，让看文档的人（研发人员或者未来几年忘记这个需求的自己回忆起来）能了解当初做这个需求的原因是什么。

1.3 实现范围

从实现版本和范围出发，版本一般有:安卓还是IOS，PC端还是小程序，这些得说明清楚，范围可以分为用户类型，比如是会员或者什么类型的用户，如果有一些是有针对海外用户的还得考虑语言版本，当然如果是国内的用户群则不需要这么详细区分。

1.4 关键词

关键词主要是写一些内部术语的解释，因为各个公司不同，会说一些只有公司内部才听得懂的缩略词，这个时候可以在这里说明，方便新人或对项目不熟悉的外部成员也能看得懂。

1.5 重要说明/风险

对一些重要的信息事先声明，比如可能会造成什么风险，例如上线了某个功能可会导致系统在某个是时间段不稳定而产生某些重要功能无法使用等，提前写清楚，让领导和团队成员有个提前的认知。

这一块若有则写，若无则可以不写，空着就可以。

2. 业务流程

2.1 用例图

用例图主要是用来述说用户故事，涉及到人物、场景、流程，大白话就是一个人在某个场景干什么。比如本功能为新增浏览历史的功能，那么浏览历史如何产生？那么就有个用户故事，那就是这个用户通过查酒店、查机票、查XXX之类的产生了浏览历史，把这些所有的故事列出来，让研发人员一眼能知道这个需求到底是想做什么。

简单的用例图已附上，复杂的用例图一般会牵涉多个多角色多场景，做任何用例图或流程图都应该秉承着不要去做复杂的事情，尽量简单，文档都是给人看的，尽量做得让大家看的没那么累，容易懂就行。

以下是我常做的简单且普通的用例图。足以满足需求。

2.2 业务流程图（需求文档的骨架）

一般谈到业务流程图，我们说的都是跨职能流程图，也成为“泳道图”，之所以这么称是因为这个流程图长得像游泳池的泳道，每条泳道代表一个角色或系统所要进行的操作，泳道之间还会存在流程的关联。

业务流程图是整个需求文档的骨架，只要把流程图理出来了，整份需求文档其实完成了80%，剩下的无非是对该文档的具体信息的填充，所以务必重视业务流程图。

根据我的经验，无论是新手还是老手，都应该对自己做的需求画一画流程图，只需要画到业务层面即可，不用详细到技术层面。

不要认为这个流程很简单我就不画了，每次我有着想法的时候我都尝试画一画，画完之后我才发现原来有些地方我想漏了，甚至有些流程我本以为可以串起来，但发现是不行的。

所以务必重视业务流程图，脑子里想的，也要动手画出来，这样看文档的开发人员和测试人员也更容易理解。

以下是业务流程图的示例，供大家参考。

若真的认为该功能没有必要画流程图，则可不画，或只涉及到一个角色或系统，并没有交互，那就不必画泳道图，画普通流程图就可以，普通流程图其实就是单单一条泳道的泳道图。

关于流程图的画法相信大家也并不陌生，其实在我们中学时代已经有学习过流程图的画法，比如矩形代表操作，圆角矩形代表开始和结束，菱形代表判断，这些只需要上网搜搜相关教程很快就能知道，一般只用到几个形状即可。

骨架搭建好之后，我们就来看血肉——用例详述，每一个页面每一个细节的讲清楚。

3.用例详述

3.1 使用XXX功能的用例

3.1.1 用例描述

3.1.2 用例条件

3.1.3 业务规则

用例是一个用户使用的例子，一个事件，比如本案例中，用户去使用浏览历史，从操作开始到结束，则视为一个事件，本事件的开始是用户进行了某些操作，这些操作带来的结果就是产生了浏览历史，作为一次用例。

更简单的理解为，从一个入口进入后所进行的所有操作叫做一个用例。

生成浏览历史的操作是一个用例，查看浏览历史的的操作是另外一个用例，因为生成浏览历史时用户是在进行查询，比如查好淘宝宝贝，查找机票等，视为一个用例。另一个用例为用户想去查看前些时候找过的历史的东西，则这个视为另外一个用例。

一个流程可以通过时间分割开的才是两个用例，否则则为一个用例，比如我产生浏览历史，一般都是一个流程走完的，比如我点击查询这个查询那个，哪怕我只查询过一次，我也会留下浏览历史，但我可以隔第二天之后再去翻阅我的浏览历史，这就是另外一个用例，另外一个故事了，这就是两个用例，用例就是这么做区分的。

这个区分很关键。是需求文档是否有条理的核心。

用例描述一般为对用例的简单述说，同时还有用例条件的约束，为前置条件和后置条件。

前置条件为发生这个用例的时候需要满足哪些前提条件，比如查找浏览历史，首先得是登录用户，不然不会对浏览的历史进行记录。

后置条件则为发生了这个用例之后，会记录或关联上什么，比如历史记录产生后，需要把数据记录到后台系统，或者只记录到手机APP。

关于前置条件与后置条件，如果对系统信息传达不是特别熟悉可以不写，当然表述清楚会让开发人员更不容易出错。

关于业务规则，则是关于此用例是否有特殊的业务规则需要说明，若无可不写，若有则可以在此处进行描述。

3.1.4 基本流

3.1.4.1 入口

所谓的基本流，可想象成一条流水，每个用例，都是对某些页面的新增或改动，比如对于A页面，有多个入口可以进入，先描述进入的入口，紧接着描述A页面的界面说明、逻辑说明和异常情况处理。

描述完毕，继续描述其他页面，直到把所有页面都描述完毕为止。

注意此处只是对所有页面的具体界面与逻辑进行描述，对于页面之间的逻辑逻辑，则在最前面的流程图早已贯穿，所以此处不用再重复说明这个问题，基本流就是对该用例的所有页面进行详尽的描述。

注意入口如果只有1个则写一个即可，若有多个需要罗列出来，并且最好能对每个入口在哪里页面进行贴图，这样才更加清晰明了。

紧接着，从入口进入之后，则是上主菜了，入口进去之后，则是本次用例（需求）真正进行改动的地方，比如这个页面是新增的还是修改的，都要说明清楚，先贴个图，毕竟图对看文档的人简洁明了。