本文作者写了大概一年的需求文档，对需求文档也有了不同于一开始的认识，也积累了一些经验，在此分享给大家。
到目前为止，大概写了一年的需求文档。
整个过程从零开始，通过自己的探索（反复练习与参考资料），也算能产出一份比较满意的需求文档，接下来需求文档的作用说起。
需求文档的作用
很多人会认为需求文档是给开发同学与设计同学看的，目的是让他们更好地理解需求。但经过一年的实践，越发觉得产品同学才是需求文档最大的受益者。
写需求文档过程，也是构思产品的过程。需求文档中包含『产品结构图』与『逻辑流程图』，产品结构图展示的是产品的具体模块与功能，而逻辑流程图则说明了功能的具体步骤。将他们写清楚后，产品的骨架也搭建了起来。
另外，在画产品原型、补充产品逻辑的过程中，能够帮助产品同学理清产品的细节，确保产品在最初的设计上尽可能的完善与流畅，最大限度避免了后续出错的可能。
在进行需求评审的时候，需求文档是辅助产品同学阐述产品需求的重要支撑，类似于演讲的PPT。很多时候单靠口头描述，很难说清产品的具体细节与逻辑，如果结合着产品原型图，则会事半功倍。
十分建议将产品逻辑背后的『理由/产品解释』写到需求文档中，例如弹窗的『确定』与『取消』按钮，突出『确定』按钮的原因是想让用户完成期待的操作；添加『功能结果页』的原因是为了增加广告的展示频次等。
这样做有两个好处：一是能让产品同学在设计功能的过程中，不断的自我质疑，减少功能逻辑潜在的缺陷；二是能让别人更好理解需求本身，增加沟通的流畅性。
3. 减少沟通成本
需求文档对于设计与开发的同学来说，更像是一份参考文档或者需求词典。在他们困惑的时候，能够通过翻阅需求文档，解决疑惑点，从而省去了询问的过程。这就要求产品同学在编写需求文档的时候，要尽可能细致。
一份需求文档，除了原型图外，还应该写清楚『开发注意事项』与『设计注意事项』。开发注意事项包含页面间的跳转逻辑，每个组件的操作响应，操作之间的避让逻辑等；而设计的注意事项应该包含页面组件的表现优先级，组件的不同状态等。
另外，如果牵扯到广告变现，还要将广告的请求时机，展示时机说清楚。
在产品实现正式开始之前，产品同学一定要对开发同学与设计同学说清楚原型图中的每个要点，确保他们对于需求的理解和自己达成一致。这样在推进产品落地的过程中，才能充分发挥需求文档参考作用。
4. 产品存档
处于维护期的老产品，如果没有相关的文档，对于刚接手的人，简直是一个灾难。因为一款产品从发布到成熟，期间经历过各种坑，缺少对应的文档的解释，很多功能逻辑都无法理解，可能需要重新趟一次浑水，才能将老产品彻底的掌握。这个过程本身是痛苦的，成本也是巨大的。
但是，如果有比较完备的参考文档，接手过程就会顺利很多。另外，在遇到产品问题的时候，也能够通过翻阅备份文档，快速定位问题，极大提高了工作效率。
5. 需求文档构成元素介绍
1）逻辑流程图
将产品目标拆解实现步骤，将相关的步骤聚合为产品模块，每个模块之间低耦合，高聚类；
模块内使用流程图将具体的逻辑串联起来，每个模块内的逻辑流程基本上都可以从头到尾执行完毕，少有交错的情况；
如果有重复出现的逻辑流程，要使用子流程进行概括，并且在主流程中使用子流程进行替换；
2）原型图
画清楚页面的组件布局以及文案信息；
各个组件的展示优先级，通过组件的大小、颜色的深浅表现出来；
页面/组件的不同状态展示（选中状态）；
页面之间的跳转逻辑（使用跳转）；
每个组件的操作响应（使用简单的流程线）；
广告的展示位置。
3）开发注意事项
控件的操作响应；
页面间的跳转逻辑；
状态更改的时机与条件；
广告的请求、展示逻辑。
4）设计注意事项
组件的优先级说明；
组件自身在各种场景下的变化。
5）产品解释
说清楚页面/组件要实现的产品目的
小结
虽然写出一份完整的需求文档，看起来要花很长的时间。但实际纯粹输出文档的时间并不多，大概一到两天的时间。真正耗费时间的是产品框架的搭建与逻辑的梳理，而这一块对于任何产品都是必不可少的。
需求文档如果做得比较完善，节省出的沟通成本是巨大的。在实践的过程中，一份完整的需求文档，加上充足的前期沟通，大致能节省后期70%的沟通成本。省下来的沟通成本所带来的是成倍的效率，因为沟通前后的精力转移成本是非常巨大的。
当然，需求文档的详略主要取决于团队成员对于项目的理解。
如果项目本身就很小，每个人对于项目都有着较深的理解，需求文档只需要简单的概述需求本身；对于比较大型的、复杂的产品，需求文档则越完善越好。
