编辑导语:作为产品经理，写需求文档是必不可少的。那么如何写一份完整的需求文档呢？作者总结了四个部分，并详细介绍了需求文档的编写指南。让我们来看看感兴趣的童鞋们。
每个产品经理都知道需求文档是最基本的技能，但是要写好需求文档真的不是一件简单的事情。那么在这篇文章里，我就和大家分享一下做产品经理和产品线新人这么多年的心得，以及如何写一份完整的需求文档。
一、需求文档描述层次要写好需求文档，首先要明白什么样的文档才是好的需求文档。在我看来，一个顶级的需求文档至少应该清楚地解决三个层次的问题:
一个一个说吧。
第一点实际上需要我们设计正确的需求。例如，我们需要一个用户订购功能。我们以是否充分理解订购模块为依据，也就是在需求描述的过程中，看看你设计的方案能不能行得通。发展能实现吗？这叫做需求的正确设计。
第二点是问我们。对于我们定义的需求，比如订货需求，在设计过程中，不仅要描述主流程，还要清晰描述与流程相匹配的其他相关模块。
比如下单过程中涉及到的用户中心、支付中心、风控中心，这些都与你的订单流转有着密切的关系，所以我们都要描述好与它们的交互规则。
第三点其实是在前两个基础上的升级，就是当我们能够正确完整的描述一个需求的时候，我们希望你描述的需求能够是最好的解决方案，也就是能够给用户带来更好的用户体验的解决方案。
比如我们可以用很麻烦的方式设计订单，也可以在网站上添加一键快速订单。显然，后者才是优化的设计方案。
二、需求文档公式前面主要讲了需求文档的写作原则和对应的重要性。接下来我们就来说说我们在写需求文档时经常遇到的一些情况。
事实上，编写需求本身并不复杂。问题是很多人写的需求文档不完整。这里写的不完整并不代表他没有遵循上面说的全面原则，也就是缺少了哪个模块的描述。
但是当他描述需求时，描述的规则是不完整的。要么是对某个环节缺乏具体的计算逻辑，要么是对页面上的错误提示缺乏描述。那么，这个问题的出现，其实就是他还没有建立一个需求文档完整框架的认知。
除了描述可见的交互之外，在写需求文档时，我们还需要深入系统定义操作规则。因此，我们可以用一个公式来解释需求文档:
需求=系统规则+接口交互
其实把需求拆解一下，需求的本质就是通过一系列规则得到想要的信息结果。
如图，我们只是将用户想要计算的两个数输入到一个系统中，在分程序规则定义的规则的运算处理下，得到用户想要的信息输出，也就是商。
所以需求文档中最重要的部分其实是规则的描述，一个规则描述的完备性决定了系统是否被用户所需要。
说了这么多，我们来具体看看一份完整的需求文档有哪些组成部分？我使用这样一个表格来总结需求文档的完整组成部分。
除了需求文档，另一个我相信大家都有一定阴影的就是需求审查会。需求评审的第一次会议可能会有无数的学生。面对所有人。评委提出的各种问题让我对自己的设计失去了信心。
所以让我为你解释一下需求评审。其实需求评审本质上就是评审下面的三样东西。
角色1:业务方评审的重点:是否满足业务需求。
角色2:技术方面检讨重点:发展可行性。
角色3:上级评审重点:投入产出比。
所以，只要在实际审查和需求设计阶段围绕这三个角度去思考，就可以大大避免这部分逻辑描述一会儿缺失，这部分流程描述一会儿缺失的情况。
五、最后[/s2/]作为产品经理，我们工作的核心是产品解决方案的输出，通过一个新产品或者产品迭代，不断的进行自己的持续工作。
无论是日常沟通，还是参加各种会议，输出相关程序，我们很多工作都需要通过一个核心的中介来输出，这个中介就是PRD。所以请练好基本功，这也是产品负责人最基本的职业要求。
#专栏作家#
散叶，微信微信官方账号:散叶茶馆，人人都是产品经理专栏作家，2019年度作者。《中台产品经理集》作者，前万达高级产品、MBA特聘讲师、独立创业者，现为购物B端产品线负责人，拥有从零到一的多种集团项目经验并引领实现商业布局。
本文原载于《人人都是产品经理》。未经许可，禁止转载。
图片来自Unsplash，基于CC0协议。
