需求文档可能是很多产品的学习第一课，到底怎么写好一份需求文档，还是要追根溯源从根本上说起
本着万物可追溯，万物可分解的原则，这个问题可以分解成三个问题
1、不写行不行
推动需求落地的一般来说需要以下几个步骤
1）前期沟通
2）宣讲
3）原型+文档
4）后续沟通
所以原型+需求文档在整个落地过程中处于中流砥柱的位置，起的是承上启下的作用
承上：阶段性成果交付
启下：定调（项目周期开始的标志）
原型和文档之间互为补充，一起完成了这个任务，那要不要写文档就要综合考虑以下情况
1）考虑公司情况
每个公司的规模和制度不一样，有些公司强制要求文档且有固定模板，这种就不能省了
有些公司强调敏捷开发，可能不会做太多要求
2）考虑需求类型
大需求还是小需求
流程优化还是页面改动
为了节省沟通成本，一般大的需求还是要写的
从表达力上来说
流程类需求更适合 流程图+需求文档为主，原型为辅
页面改动则原型为主，文档为辅，直接在原型上做标注，看起来也轻松些，不用两个文件来回对照
最终目的是为了将信息有效的传递开，使整体效率达到最大化，这个传递的载体不限于原型、文档等任何形式，关键是根据情况来选择合适的载体
2、写了给谁看
完成一个项目需要多方角色协作完成，一般来说，是以下几个角色为主
UI、前端开发、后台开发、测试人员
首先提取共性，他们都需要知道的是什么？
1）为什么要做这个需求？解决了什么问题或者实现了什么目标？
2）需求内容是什么？
3）做到什么程度？未来是否有拓展和改进
如果是打磨很久的紧密合作型团队好说，不过很多时候开发和运营之间会存在一个壁垒，互相不了解彼此的工作情况，这个时候开发人员对这个需求究竟了解多少，也要考虑进去，充分叙述项目背景是很有必要的，只有大家的认知偏差足够小，最后出来的成果才会更接近理想
上面说的是共性，不同的角色之间对一个需求的侧重点也是不一样的
从上面各个角色的侧重点可以总结出文档内容需要包括哪些东西
项目背景
预期目标
流程图
需求大纲
功能需求（需求内容、功能类型、极限情况处理）
非功能需求（性能要求、拓展性说明等）
像版本记录（作者、时间、版本号、修改记录）、设计规范（字体大小、全局说明）、角色说明（目标人群）这种可以根据不同的项目、不同的情景选择加入
3、怎么写比较好看？
好看有两种含义
1）内容好看
其他人看文档的时候等于是跟着笔者的思路在走，如果逻辑混乱，东一榔头西一棒子，看的人也就不知所云
一个好的文档结构可以使内容看起来上下连贯、逻辑通顺，有个好的文档结构这篇文档也就成功了一半
文档结构可以遵循由浅入深、由大及小的原则，增加内容的层次感，尽量避免上下文来回引用
而另外一半就在功能需求的详细描述中，详细写功能需求的其实更考验一个人的提炼能力，尽量用准确简洁的语言描述内容，避免大段文字，多用短句，多提炼123
2）页面好看
而视觉效果上，清晰的目录、统一的字体和行距、该加粗加粗、该换颜色换颜色、该用小标题就用小标题，这些都是不太花时间却加分很多的东西，毕竟人都是视觉动物嘛
小结
汝欲学诗，功夫在诗外
这个道理放在这里也行得通，在基于对需求的深刻理解前提下，前期的思考和准备也是一篇优秀的文档的必备工作，这些都想好了，真正去写才能下笔如有神
初学的时候可以上网多找几个模板，然后根据自己的项目情况进行删改，这样能最大程度避免错漏，但是最根本的还是要知道为什么要这么写，这样遇到不同的项目和情景时才能做到有的放矢、松弛有度。