对每位产品经理都知道需求文档是最根本的基本功，但是要想写好需求文档还真不是一件大略的事情，那么本篇文章我就向大家来分享一下这么多年做产品经理以及带产品线新人得出的履历，要如何去写一份完全的需求文档。
一、需求文档描述层次
要想写出好的需求文档，那我们首先要明白什么样的文档才算是一个好的需求文档。在我看来，一份顶级的需求文档至少要讲清楚三个层次的问题：
是否设计精确：设计的需求是否精确（主要性：60%）；是否设计全面：产品模块与业务规则描述是否全面（主要性：30%）；设计是否高效：设计的是否有可优化点（主要性：10%）。我们来一个一个讲。
第一个点实际上便是哀求我们去设计对的需求，比如我们须要一个用户下单功能，我们以是否完全的讲通这个下单模块作为依据，也便是在需求描述的过程中，我们来看你所设计的方案是否能跑通？开拓是否可以实现？这样称之为需求的设计精确。
第二个点便是哀求我们。对我们所定义的需求，例如下单需求在设计的过程中，不仅要描述主流程还要将与该流程相合营的干系其他模块都描述清楚。
例如，下单过程中涉及的用户中央，支付中央，风控中央都与你的订单流转有密切的关系，以是我们都该当去描述与之交互的规则。
第三个点实际上是在前两者的根本上进行一个升级，也便是当我们能精确的完全的描述一个需求之后接下来希望你所描述的需求能是最优方案，也便是能给用户带来更好的用户体验的一种方案。
例如我们下单可以设计的很麻烦，也可以在网站上增加一键快捷下单的办法那么明显后者便是优化后的设计方案。
二、需求文档公式
前面我们紧张给大家谈了需求文档撰写的，原则以及对应的主要性。接下来我们要谈一谈写需求文档常常会碰着的一些情形。
需求文档实在本身撰写没有什么繁芜性，问题在于很多人撰写需求文档都写不完全。这里的写不完全不是指他没有遵照我们上面提到的全面性原则，也便是少了哪对哪个模块的描述。
而是在他描述需求的时候描述的规则不完全。要么是短缺对付某个环节详细的打算逻辑，要么是短缺对付页面上缺点提示的描述。那么这种问题的涌现，实际上便是他对需求文档的一个完全框架没有建立一个认知。
我们写需求文档除了描述能看到的交互外，更多的要深入系统定义运行规则。因此我们可以用一个公式来解读需求文档：
需求文档=系统规则+界面交互
界面交互：指的是原型加对应的交互规则，常见的如按钮的交互样式，缺点提示，字段长度限定等等。系统规则描述：指的是一个别系在各个节点运作时信息流处理逻辑。大家都知道打算机的实质或者说软件系统的实质便是一个信息黑盒。实在拆解一下需求，需求的实质便是将用户所输入的信息在一系列的规则处理情形下得到了用户希望想要的信息结果。
像图中我们便是将用户想要打算的两个数输入到了一个别系中，在我们用程序定义的规则——除法规则的运算处理下，得到了用户希望的信息输出也便是商。
以是说，需求文档中最主要的部分实在便是规则的描述，一个规则描述的完全与反对议了这个别系是否是用户所须要。
三、需求文档组成元素
在前面说了这么多之后，我们详细来看一下一份完全的需求文档到底有哪些组成部分？我用这样一张表来概括需求文档的完全组成部分。
四、需求评审评什么？
除了需求文档之外，另一个相信大家都是有一定阴影的便是需求评审会。可能有无数同学在初次上需求评审会的时候。在面对各个。评审方提出的各类质疑下，让自己对自己的设计损失了信心。
以是我来为大家解读一下需求评审。实际上，需求评审实质上便是在评审下边这三个东西。
角色1：业务方
评审中关注方向：是否符合业务哀求。
角色2：技能方
评审中关注方向：开拓可行性。
角色3：上级
评审中关注方向：投入产出比。
因此只要我们在实际评审和需求设计的阶段，环绕这三个角度去进行思考，就能大大避免一会少了这个部分逻辑解释，一会少了这个流程解释的局势。
五、末了
作为一个产品经理，我们的事情核心是环绕产品方案输出的，不断的通过一个新产品或者产品迭代来开展自己的持续性事情。
不管这天常的沟通，还是参加各式的会议，以及输出干系的方案，我们的很多事情都须要通过一个核心中介来产出，这个核心中介产出便是：PRD。因此请大家练好基本功，这也是产品人最基本的职业哀求了。
#专栏作家#
三爷，微信"大众号：三爷茶馆，大家都是产品经理专栏作家，2019年年度作者。《中台产品经理宝典》作者，原万达高等产品、MBA特约讲师、独立创业者，现叮咚买菜B端产品线卖力人，拥有多款集团项目从零到一履历并带领实现商业化布局。
本文原创发布于大家都是产品经理。未经容许，禁止转载
题图来自Unsplash，基于CC0协议