需求文档撰写指南

一、需求文档描述三层次

① 是否设计正确：设计的需求是否正确（重要性：60%）；
② 是否设计全面：产品模块与业务规则描述是否全面（重要性：30%）；
③ 设计是否高效：设计的是否有可优化点（重要性：10%）。

• 第一个点实际上就是要求我们去设计对的需求，比如我们需要一个用户下单功能，我们以是否完整的讲通这个下单模块作为依据，也就是在需求描述的过程中，我们来看你所设计的方案是否能跑通发是否可以实现样称之为需求的设计正确。
• 第二个点就是要求我们。对我们所定义的需求，例如下单需求在设计的过程中，不仅要描述主流程还要将与该流程相配合的相关其他模块都描述清楚。
  例如，下单过程中涉及的用户中心，支付中心，风控中心都与你的订单流转有密切的关系，所以我们都应该去描述与之交互的规则。
• 第三个点实际上是在前两者的基础上进行一个升级，也就是当我们能正确的完整的描述一个需求之后接下来希望你所描述的需求能是最优方案，也就是能给用户带来更好的用户体验的一种方案。
  例如我们下单可以设计的很麻烦，也可以在 站上增加一键快捷下单的方式那么明显后者就是优化后的设计方案。

二、需求文档公式

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

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

• 界面交互：指的是原型加对应的交互规则，常见的如按钮的交互样式，错误提示，字段长度限制等等。
• 系统规则描述：指的是一个系统在各个节点运作时信息流处理逻辑。大家都知道计算机的本质或者说软件系统的本质就是一个信息黑盒。

三、需求文档组成元素

四、需求评审评什么/h2>

实际上，需求评审本质上就是在评审下边这三个方面：

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

角色2：技术方
评审中关注方向：开发可行性。

角色3：上级
评审中关注方向：投入产出比。