经验总结：产品需求文档的编写四步法思维导图

也就是需求的结构化可视化处理。

通常，产品经理会有一个需求池。我们根据需求的重要性和紧急性从需求池中挑选出部分需求，作为产品迭代版本的工作内容。确定了要纳入版本开发的需求点之后，接下来要做的并不是编写需求，而是画需求树。

这一步要用到的工具便是思维导图软件。我们将从需求池取出来的零散需求，以分类别的方式进行结构化处理。如按模块化分，按用户角色化分等，从而让一个个的需求点组成一个个较完整的功能。这样的好处是，让需求点之间形成联系，而这个过程则可能会演化出新的必要性需求，也将之纳入到版本需求中去。

这个时候的需求导图，类似于树干加上枝干，已经形成了产品需求树的大概样子。

将零散需求结构化处理之后，便要进行进一步的细化，也就是画出需求细枝。

在每个需求点之下，都会有些关键的，重要的元素构成。将这些元素画出来，有利于后面的需求文档编写工作，避免产生遗漏。

把所有的细枝都画完之后，我们的需求树便已完成。看到这个需求树，自己心里已经大概知道需求文档要写些什么了。

需求文档的目录结构，就是用来确定文档的内容和表达形式的一种有力手段。在写需求内容前先把整个文档的目录结构确定后，编写文档的效率会大大提高，也会使得文档的表达逻辑更为清晰明了。

一般情况下，产品经理都会有自己的一套比较常用的目录结构，用于快速地建立文档框架。但是在很多时候，通用目录结构可能并不能满足特定需求下的表达效果。因为不同的需求所需要使用到的表达方式是不一样的，只有针对性地采用合适的表达方式才能使你编写的需求文档产生事半功倍的效果。

比如，针对用户端APP形态的功能定义，则更侧重的是信息架构、页面展现、用户体验，所以在原型设计和关键交互要求是需要重点说明的。因此，在这部分需求的内容结构上，需要将“原型设计”及“交互说明”单独列入到目录结构中去。

比如，针对后台功能，侧重的是数据处理和存储，所以在数据项定义、数据流转、规则说明等方面需要进行完整说明。而如果这几部分内容较多，则也是需要进行划分，最终体现在目录结构中。

再如，涉及到多系统间业务交互的，或者业务流程较为复杂的，则可能需要考虑加入系统间业务交互说明、接口定义、业务流程描述等内容。

如此这般，都是需要针对不同类型的需求采用不同的表达方式来描述需求。最终的目的也都是为了让文档使用者（开发工程师）更容易理解你所定义的需求。

所以，我们在写文档之前进行目录结构设定，是为了框定文档的内容和表达方式，相当于我们建筑里的框架结构。搭建好之后，便可以进行快速填充了。

做好以上两步，那这一步就变得简单多了。因为你知道了要写什么，而且还知道要怎么写，剩下的无非就是时间问题了。

这一步，最重要的就是把需求描述得更容易理解，要站在开发工程师的角度来考虑如何表达。另外就是逻辑要严密，不要产生需求漏洞。

产品需要迭代，需求文档也一样。当你的需求文档发出去之后，经过评审，以及在后续项目进行过程中都有变更需求定义的可能，这就涉及到了文档的更新问题。

我们可以称之为需求文档迭代。这个工作最重要的就是版本管理。每次文档更新，我们都需要像产品版本一样给予定义一个版本号。这个版本号跟产品版本要区分开来，文档版本号是在产品版本之下的，所以只需要进行简单的命名即可。

通常，我会将需求文档版本号命名为Rx，如R1，R2，R3等等。R表示requirements，即需求。默认将首次发布的需求文档版本定为R1，后续每次变更修改则依次命名为R2，R3……且要说明此次版本变更的说明。另外还有就是修改人，修改时间等信息。

而在具体内容修改的地方，最好能把改动的地方标识出来，比如用高亮的字体颜色进行区分。这样能让开发人员一目了然，便于阅读。

最后，对于需求文档的编写，还需要明白如下几点：