文章开头：本文主要内容摘自Kevin个人号发布于产品壹佰的文章（http://www.chanpin100.com/article/104318），原文实在太长，所以基本只选取了对我当前有用的地方进行了"翻译"和摘录，仅供自己学习用，侵删~
一、什么是需求文档？
主要用于完整描述产品需求，向研发部门明确产品的功能和性能。文档质量将很大程度上决定了产品的最终质量。
二、怎么写？
1、需求概述
先简述文档状况
①背景概述
你要做什么？为什么要做？准备怎么做（尽可能精简）
②需求来源
来源负责人：?
来源部门：？
③关联负责人(暂不清楚写这块是为了什么)
初创公司大家知根知底，一般不用写
④需求执行成员、职责
初创公司大家知根知底，一般不用写
⑤需求执行周期
交给开发前就已经商量好了排期
2、更新记录
非常关键，要实时更新，否则一旦开发问你都改动了哪些内容，你既要花大把时间梳理，也容易产生疏漏，这个坑我已经多次踩了
下表我认为还少了一点，需要说明为什么要改，后续回顾起来才能知道是哪些问题影响了开发进度
新增、删除、修改为记录的主要变更方式，其中新建为默认，对应V1.00版本，在表里应该仅做对照用
3、需求结构图
主要是设计和技术开发人员了解需求的结构用，不用过于仔细
4、数据间关系
这块没尝试做过，仅做记录了解：
方便测试和开发人员指导哪一个数据是哪一个对象的，在哪一些流程中会增加或判别什么数据
这一点对于大功能模块来说比较常用，但一些小的功能模块，这一块可以忽略不梳理，比如很常见的一个广告BANNER等小功能模块，想用的数据关系可以不用展示，与开发直接沟通好就行
5、全局说明
每个PM都会有一个全局流程被梳理出来，入职后熟读熟用即可
全局说明主要分3类，如下图
细分内容通常有弹层对话、加载、弹层菜单、搜索、导航、表格、按钮、列表、进步器等
6、功能清单（我还没到这段位，写不到这里）
主要方便设计、开发人员以及测试人员对工作量的评估
层级不用分得太细，2层即可，再多的放描述里
7、业务流程（写过比较初级的，需要按照以下思路重新画一次）
默认是以用户开始，依照用户的操作，将其流程分为前端和服务端，告知相应端开发人员应该做什么、不应该做什么
泳道图涉及的多角色流程图也可以了解下
注意：流程图要清晰，不要扭成一团
需求/功能描述
不要忽略页面上任何一个元素，除非开发与你很有默契
页面需求描述
什么条件出现、是干啥的、该出现在哪儿
交互手势
善用手势可以极大提高绘制线框图的效率，以前死脑筋非要整啥动态效果，要分清线框图和原型图的作用
用例描述
emmm...没画过，待实践
异常情况、
大多数PM或许会将该异常情况统一交给测试来处理，这一点是产品专业与否的体现之一
数据统计需求
即埋点，虽然写过，但这块缺乏足够实践，先空着
最后附上我曾经做过的交互图，按时间顺序我给标好了12345（图片展示是倒序）
线框图的话，果然还是黑白灰上眼
