一、需求文档的意义是什么？
把正确的东西交给正确的人，满足协同人员的诉求，即是需求文档存在的意义。如何写出满足协同人员诉求的需求文档？首先，需要观察不同的协同人员具体的工作场景，基于他们工作场景中的冲突，发现他们的需求，从而输出的解决方案，就是较好的需求文档。
1.产品经理的诉求
（1）产品部门的版本需求讨论、需求评审会。
在版本任务的讨论中，在与其他产品经理讲述所规划的功能时， 版本记录、项目背景、项目框架图、流程图，可以快速让其他产品经理了解整体项目，并根据项目背景，给出意见。
（2）与其他产品经理所负责的内容有交叉点。
当一个完整项目，每个产品经理负责部分内容的时候，各自负责部分功能的需求文档有助于其他产品经理从文档中发现交叉点中的衔接是否合适，各功能模块的整体融合性。
（3）Bug处理。
再厉害的程序员也不敢保证产品上线后不出现任何问题，当产品上线后出现问题，需求文档有助于产品经理快速找到规划的初衷，根据之前的情境给出精准的解决方案。
（4）版本迭代。
当产品在不同时期，做不同的版本迭代时，之前的需求文档尤为重要，有助于负责该项目的产品经理快速熟悉往期规划的初衷、目的和当前的效果及不足，并在迭代版本中对往期问题进行修复，在新的规划中避免不必要的坑。
（5）人员异动。
如果出现人员异动（人员项目变更、人员离职等），有助于新接手的产品经理快速熟悉项目，确保项目规划不会因个人经验、个人喜好、习惯等原因，出现太大的偏差。
基于以上场景和目的，其他产品经理对需求文档的诉求需要得到的信息：谁、在什么时间、因为什么原因，做了什么内容，满足了什么人的需求，变动内容及节点、阶段性规划。
2.设计师的诉求
设计师是项目实施阶段的名列前茅步。确定版的需求在落地执行时，首先是由设计师开始制作设计图。项目的整体功能有哪些、基于什么背景、未来的规划方向，需要在文档中给出建议和说明，有助于设计师按照产品经理的设想，设计出符合或高于期待的产品设计图。
基于上述场景和目的，针对设计师角色，产品经理在编写需求文档时，需要告知的信息：因为什么原因，给什么特点的群体，做什么图，当前竞品什么情况、公司什么情况、市场什么情况，想达到什么效果，后期发展方向（业务、功能、设计方向等）。
3.开发人员的诉求（前端、APP、后台、测试）
前端开发：开发过程中，侧重了解涉及前端部分的页面功能、交互效果、交互逻辑；
APP开发：开发过程中，侧重了解页面元素、页面样式、功能、与后台间的接口参数传递；
后台开发：开发过程中，侧重了解功能、这些功能在后台的数据结构搭建、如何建表、功能逻辑、与前台兼的接口参数传递；
测试工程师：在产品实现过程中，侧重从产品规划中了解整体功能，从而写测试用例，以及产品上线前根据设计图的样式、文档表述的功能规则，做功能测试。
基于删除场景，产品经理在编写需求文档时，需要告知开发人员的信息：因为什么原因，针对什么项目，做什么功能，包含哪些页面元素、页面样式、交互逻辑、实现效果。
尽信书不如无书。各公司的组织架构、部门角色划分、业务开展的推动因素、公司发展所处的阶段均不相同，虽大道同源，但总有差异化表现。需要产品经理针对协同人员做好分层、分类，切实与相关人员深入沟通，了解他们的习惯，了解他们的认知，输出他们需要的需求文档，才能够确保信息的透明化，保证开发人员全面了解规划的内容。同时，辅助以良好的沟通机制和技巧，则有助于开发效率的提高和产品上线的进度保障。
二、如何写需求文档
1. 写文档先看人
需求文档与产品经理前期做用户调研时的用户画像很相似。在做用户画像时，通过与目标群体各种方式的沟通，获取用户的基本信息、兴趣、习惯、家庭情况、对产品相关业务的了解程度、接受程度、烦恼和期待等等，从而建立用户档案，输出用户的判断结果。在写需求文档前，面对我们的用户——相关协同人员，产品经理需要去了解他们。了解他们的工作方式、工作习惯、工作态度、工作认知、工作能力等与工作相关的内容，同时，对他们与人相处的方式、生活习惯、兴趣爱好等等的了解，有助于产品经理更全面的了解，从而建立更加立体的用户画像。在输出判断结果时会更准确，写需求文档会更有侧重点——哪些是他们需要知道的，哪些是他们需要特别详细表述的，哪些是需要特殊标注的，哪些是省略表述即可的。
2. 文档规范
（1）版本记录
- 谁：该文档是谁编写的，便于快速找到对应的负责人员，同时，后期有助于在需求文档库中建档分类。
- 时间：什么时间编写的该文档，旨在告知该功能是什么时间要开始做，便于后期溯源时，快速定位。
- 事件：针对什么产品、什么功能做的规划，其实就是文档标题。
- 版本号：便于记录产品不同版本的节点做了什么内容及调整，同时，针对不同的系统，有助于使用统一的版本号做管理。
- 上线计划：依据上线计划倒推测试周期、开发周期、设计周期，从而给参与该项目的协同人员约定好时间，便于更好的把控项目进度。
- 评审及修改：项目完成后的需求评审建议和结果，针对初稿内容做了哪些修改。此处一定要详细，后续调整内容时，评审建议和修改事项是很重要的可参考的细节点。
（2）版本说明
- 项目背景：清楚地写出为什么要做该项目，谁要求做的。
- 核心需求：为了解决什么冲突。
- 预期目的：想达到什么结果，后续有什么进一步的规划。
详细的项目背景有助于所有参与人员快速地了解项目是怎么回事。
（3）设计规范
设计规范来源于产品经理对该产品的整体了解：在做完市场分析、行业分析、竞品机构分析、用户调研之后，针对自己要做的产品，产品经理会形成自己的整体构思和产品走向模型。
而这个构思就是需要表达给设计师的理念——要做一款什么样的产品，要达到什么效果。
关于设计理念的表达，不同的公司有很大的差别，以及整个行业对这块内容都没有统一的观点。
一种观点认为，产品经理只需要输出黑白灰原型图即可，其他的都交给设计师处理，给设计师足够的发挥空间；
另一种观点认为，设计师对要做的产品，不了解缘由，直接去设计会有偏差，最终交付的产品大部分都不符合；
还有种观点认为，要看设计师的水平再来决定，水平高的不需要产品经理说什么，都可以交付足够让人惊艳的设计，水平低的说再多，也做不出效果，而大部分公司都属于第二种情况。
综上所述，岗位不同、职位不同、个人认知的不同，以及最重要的信息接收到处理个人间都是有差异的，最终呈现在产品上的内容就会有很大的差异。
而规避这类问题，较好的方式还是沟通。充足且有效的沟通，确保产品经理与设计师间的已知信息达到一致，双方的理念、想法、建议等越碰撞越容易做出更好的产品。
主要对接的内容包含两个部分：
- 信息与意向：传递产品信息，告知设计师关于该产品的设计原因、行业情况、要做的产品对标竞品是哪些，以后对产品的规划是什么、产品经理的意向是什么。
- 基础设计理念：产品主题、整体色调、各样式的字号、色号、全局页面的建议等。
（4）功能列表
功能列表为产品经理在经过足够多的调研和分析，从汇总的产品需求池中筛选出的当前应处理需求列表。
功能列表的作用为便于相关人员全面了解产品的功能，从而评估项目周期、处理优先级等。
功能列表主要表述都做什么功能，哪些重要且紧急。列表参数包含：
- 模块
- 功能点
- 功能点描述（详细）
- 优先级（高、中、低）
（5）角色列表
角色列表为表述清楚该产品上线后，参与到该产品中的群体有哪些。列表参数包含：
角色名称
职责：在产品参与中的简要说明
备注：特殊情形
（6）框架图
框架图为该产品包含什么内容：模块、功能。便于开发人员快速、便捷的了解产品全局。
框架图没必要做的很高大上，高大上固然很好，会让使用的人赏心悦目。但是，功能介绍简单易懂和开发人员能看懂、看明白更重要，千万不能舍本逐末。
（7）流程图
流程图分两个部分：
整体流程图：整体流程为将产品各大模块之间的交互流程，一般做正向流程居多，辅助以部分判断流程和异常处理机制
功能流程图：功能流程为涉及到具体的功能点的交互流程，包含：正向流程、规则、判断流程、异常流程。
（8）功能需求
功能需求为具体的各功能点，是需求文档的核心。主要是详细的分解各功能点，包含两个方面：
前端：针对前端部分，页面如何来、页面元素、各功能点的规则、交互、跳转规则、非常规流程的页面元素、交互、跳转规则等等。
后台部分：前端功能的实现，依靠后台的哪些逻辑和数据，是否需要做新功能模块、新功能模块的内容、数据的调用、存储、接口数据传值等等。
（9）非功能需求
非功能需求为用户常规操作产品时的极端情况，涉及很多内容，以下列举几个比较重要且常规规划中需要考虑的点：
产品性能：产品对用户操作的响应、对群体操作的并发预防等。
安全性：公司数据、用户信息的保密性处理，不同角色的权限设置、使用中的限制等。
可靠性：用户操作中出现异常情况，是否可继续操作，遇到异常情况时数据或使用状态是否可被恢复等。
拓展性：拓展性主要针对公司内部而言，产品完成后，无论是设计师、开发人员，还是测试人员，针对产品所做的工作，是否可以被复用到其他地方。用户在产品中的使用情况是否可被系统获取后用作不同维度的分析等。
以上就是关于需求文档的全部内容希望对大家有所帮助。
