需求文档不会写？手把手教你学会！
副标题[/!--empirenews.page--]
一、需求文档的作用之前提到过『结构流程图』是产品的骨架，非常重要，但团队中很多成员对其实无感的，因为产品本身就是一个故事，仅仅有故事的构思是远远不够的，要想把故事讲好，还需要赋予故事更多的细节与血肉，这就是需求文档的作用！ 二、好故事的组成要素童话书里最吸引眼球的是插图，而非文字。甚至只看插图，就能把情节完整的串联起来。而原型图就是需求文档中的插图，是产品方案最直接的体现，故事书中除了插图，还有对应的描述，以便读者能够更好地理解细节。 需求文档也是如此，只是需求文档的读者可以明确划分为：开发、设计与测试。不同读者想从中获取的信息也有所不同，开发想了解产品的功能逻辑；设计想确定交互与布局，而测试则想知道具体的测试点。 所以需要针对以上三类人群，需求文档要进行三种不同的描述，分别为：开发注意事项、设计注意事项、测试注意事项。 而实际的操作中，测试注意事项多数会被开发与设计注意事项所涵盖，所以测试注意事项多数可以不写。 另外，方案背后的理由解释也很重要，这样能够让开发、设计、测试对产品方案的理解更加深刻，与产品经理在方案理解上达成最大的公约数。同时在陈述产品解释的过程中，也是产品经理二次检验与自我质疑，对于方案的严谨性与完善性有很大的益处。 三、需求文档的编写3.1 原型图原型图是需求文档中最核心的部分，所有的解释说明，都以原型图为基础而展开，合格的原型图应该满足清晰的表达出以下信息 （1）页面包含的组件与布局； 这一点是最基础，同时也相对简单，因为只要产品骨架确定下来，通过参考大量的竞品，确定页面内相关的组件与布局，往往是水到渠成的事情。 （2）组件的展示优先级； 原型图中的各个组件一般会通过大小，布局，颜色深浅的形式来传达相应的优先级。一般来说，颜色越深，优先级越高；组件越大，优先级越高；组件越靠近页面的视觉中心，优先级越高。 （3）展示出组件的不同状态； 很多组件会因场景的不同，而展示不同的状态，下面的页面是某个音频播放器的主页，主页下方是音频列表，列表中每个音频通过颜色深浅的方式，区分了『选中』与『未选中』两种状态。
（4）展示组件在页面内的响应结果； 如果组件的响应结果就在本页展示，则需要将响应结果也展示在原型图中，如果响应结果是另外一个页面，则需要通过文字的形式说清楚跳转关系。 下面的案例中，点击『开始睡觉』的按钮之后，会判断起床时间距离当前是否超过90分钟，如果没超过，则弹出『睡前确认弹窗1』否则弹出『睡前提醒弹窗2』
3.2 开发注意事项对于开发的同学来说，『开发注意事项』的地位和和原型图同样重要，因为原型图只展示静态的结果，但背后的触发条件、触发时机、动态效果等关键信息无法体现，需要大量的描述将上述信息说清楚。所以『开发注意事项』需要将以下信息说明白： （1）组件状态变化的触发条件与时机； 由于多数的触发条件与时机都是抽象不可见的，所以仅参考原型图，开发无法完成预期的业务逻辑，需要通过文字将背后的逻辑说清楚，以插屏广告请求与展示为例：
原型图只表明了广告展示的流程，并没有涉及广告请求与展示逻辑，所以需要在『开发注意事项』中添加如下描述：
（2）组件的交互结果 虽然多数组件的交互结果都能通过原型图表现出来，但也有一些场景需要文字描述的形式才能解释清楚。 下面的原型图展示的是某音频播放器的首页，点击『右上角』的随机播放按钮，会随机播放4首免费的音频。但随机二字显然很难通过原型图表达，所以需要在『开发注意事项』中详细说明
（3）页面间的跳转逻辑； 在一张Axure画板中，通常只展示一个页面的逻辑，如果该页面中某些组件的交互结果是跳转到其他页面，建议使用文字将涉及的跳转逻辑表达清楚。 （4）组件与页面的动态过程； 虽然Axure也能实现一些动态效果，但制作成本较高，动态表达也很单一，通过文字描述的形式，很容易将逻辑说明白。 下图案例中，点击自定义按钮，底部会出现自定义计时器面板，仅靠原型图，开发同学无法得知『计时器面板』的出现效果，直接展示？还是淡入淡出？所以需要在『开发注意事项』中添加如下描述
（5）必要的流程图 所谓一图胜千言，上面提到的4个开发注意事项如果能用流程图表达，则建议尽量使用流程图，这样不仅逻辑清晰，而且简练明快，如下图展示的是某个睡眠闹钟首页：
若用文字描述上面的逻辑，会吧啦吧啦写出下面一段：
|
