renren-fast 完整开发文档_需求文档撰写指南（上）

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

一、需求文档描述层次

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

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

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

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

我们来一个一个讲。

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

第二个点就是要求我们。对我们所定义的需求，例如下单需求在设计的过程中，不仅要描述主流程还要将与该流程相配合的相关其他模块都描述清楚。例如，下单过程中涉及的用户中心，支付中心，风控中心都与你的订单流转有密切的关系，所以我们都应该去描述与之交互的规则。

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

二、需求文档公式

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

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

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

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

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

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

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

其实拆解一下需求，需求的本质就是将用户所输入的信息在一系列的规则处理情况下得到了用户希望想要的信息结果。像图中我们就是将用户想要计算的两个数输入到了一个系统中，在我们用程序定义的规则——除法规则的运算处理下，得到了用户希望的信息输出也就是商。

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

三、需求文档组成元素

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

从下篇开始我们就具体以一个实战示例看看这些部分如何组成一个完整的文档。

最后打一个小广告，我的新书已经上市，对于产品经理进阶技能感兴趣的同学千万不要错过！