【收藏】需求文档（PRD）终极撰写指南-技术圈

对每位产品经理都知道需求文档是最基础的基本功，但是要想写好需求文档还真不是一件简单的事情，那么本篇文章我就向大家来分享一下这么多年做产品经理以及带产品线新人得出的经验，要如何去写一份完整的需求文档。

需求文档描述层次

要想写出好的需求文档，那我们首先要明白什么样的文档才算是一个好的需求文档。在我看来，一份顶级的需求文档至少要讲清楚三个层次的问题：

（1）是否设计正确：设计的需求是否正确（重要性：60%）；

（2）是否设计全面：产品模块与业务规则描述是否全面（重要性：30%）；

（3）设计是否高效：设计的是否有可优化点（重要性：10%）。

我们来一个一个讲。

第一个点实际上就是要求我们去设计对的需求，比如我们需要一个用户下单功能，我们以是否完整的讲通这个下单模块作为依据，也就是在需求描述的过程中，我们来看你所设计的方案是否能跑通？开发是否可以实现？这样称之为需求的设计正确。

第二个点就是要求我们。对我们所定义的需求，例如下单需求在设计的过程中，不仅要描述主流程还要将与该流程相配合的相关其他模块都描述清楚。

例如，下单过程中涉及的用户中心，支付中心，风控中心都与你的订单流转有密切的关系，所以我们都应该去描述与之交互的规则。

第三个点实际上是在前两者的基础上进行一个升级，也就是当我们能正确的完整的描述一个需求之后接下来希望你所描述的需求能是最优方案，也就是能给用户带来更好的用户体验的一种方案。例如我们下单可以设计的很麻烦，也可以在网站上增加一键快捷下单的方式那么明显后者就是优化后的设计方案。

需求文档公式

前面我们主要给大家谈了需求文档撰写的，原则以及对应的重要性。接下来我们要谈一谈写需求文档经常会遇到的一些情况。

需求文档其实本身撰写没有什么复杂性，问题在于很多人撰写需求文档都写不完整。这里的写不完整不是指他没有遵循我们上面提到的全面性原则，也就是少了哪对哪个模块的描述。

而是在他描述需求的时候描述的规则不完整。要么是缺少对于某个环节具体的计算逻辑，要么是缺少对于页面上错误提示的描述。那么这种问题的出现，实际上就是他对需求文档的一个完整框架没有建立一个认知。

我们写需求文档除了描述能看到的交互外，更多的要深入系统定义运行规则。因此我们可以用一个公式来解读需求文档：

需求文档 = 系统规则 + 界面交互

（1）界面交互：指的是原型加对应的交互规则，常见的如按钮的交互样式，错误提示，字段长度限制等等。

（2）系统规则描述：指的是一个系统在各个节点运作时信息流处理逻辑。大家都知道计算机的本质或者说软件系统的本质就是一个信息黑盒，例如像下面这张示意图。

其实拆解一下需求，需求的本质就是将用户所输入的信息在一系列的规则处理情况下得到了用户希望想要的信息结果。

像图中我们就是将用户想要计算的两个数输入到了一个系统中，在我们用程序定义的规则——除法规则的运算处理下，得到了用户希望的信息输出也就是商。

所以说，需求文档中最重要的部分其实就是规则的描述，一个规则描述的完整与否决定了这个系统是否是用户所需要。

需求文档组成元素

在前面说了这么多之后，我们具体来看一下一份完整的需求文档到底有哪些组成部分？我用这样一张表来概括需求文档的完整组成部分。

需求评审评什么？

除了需求文档之外，另一个相信大家都是有一定阴影的就是需求评审会。可能有无数同学在初次上需求评审会的时候。在面对各个评审方提出的种种质疑下，让自己对自己的设计丧失了信心。

所以我来为大家解读一下需求评审。实际上，需求评审本质上就是在评审下边这三个东西。

评审中关注方向：是否符合业务要求

评审中关注方向：开发可行性

评审中关注方向：投入产出比

因此只要我们在实际评审和需求设计的阶段，围绕这三个角度去进行思考，就能大大避免一会少了这个部分逻辑说明，一会少了这个流程说明的局面。

最后

作为一个产品经理，我们的工作核心是围绕产品方案输出的，不断的通过一个新产品或者产品迭代来开展自己的持续性工作。不管是日常的沟通，还是参加各式的会议，以及输出相关的方案，我们的很多工作都需要通过一个核心中介来产出，这个核心中介产出就是：PRD。因此请大家练好基本功，这也是产品人最基本的职业要求了。