需求文档是怎么写的？不同公司有不同的写法，并没有硬性规定，清晰、没有遗漏即可。这篇文章，作者分享了自己写需求文档的经验，供大家参考。

01 什么是需求文档

需求文档是产品经理用来详细描述需求，满足协同人员使用的内容文档。它面向的人群包括：设计、交互、开发、测试、项目经理、运营及其他业务人员。

02 为什么写需求文档

写需求文档本质上是为了提高工作效率和减少沟通时间。没有需求文档可以开展工作吗？其实也可以。如果团队只有两个人，坐旁边当面沟通甚至比文档的效率还要高。但一个需求只有两个人的情况极少，没有文档的话，多方人员之间需要花大量时间不断地进行沟通、信息同步，人越多效率就会越低。

此外，需求实现过程中也会出现遗漏和改动的问题，需要当面沟通，时间长之后沟通的结论可能双方都记不太清楚了，留存到文档中可以避免反复扯皮，让项目中的人员达成共识。

03 如何写需求文档

需求文档没有固定的模版，但是有大致的框架。主要是需求背景、需求范围、需求详细说明、埋点需求四部分。

3.1 需求背景

此模块用来描述需求来源和产生此需求的背景，目的是帮助团队成员理解项目的起源、目标和重要性，以便产品经理更好地推进项目。这部分内容主要包括以下几方面：

• 描述现状及当前存在的问题，可以通过数据或用户反馈来支持；
• 本次需求可以解决哪些问题；
• 需求完成后可达成的具体的量化的产品业务目标，非基建类的需求需要有具体数值；
• 需注明业务方的预期上线时间，评审后各方评估时间紧张的话，可能需要调整业务预期或倒排时间。

3.2 需求范围

业务流程图：一般需求比较大或者比较复杂时需要补充该模块，让文档的受众更好地了解业务的情况和本次需求的功能范围，可以通过泳道图的形式进行输出；

变动范围：如果是优化产品需求，简述本次需求在原有的框架中的变化（新增功能模块/页面，修改某功能模块/页面，以及删除某个功能模块/页面等）；

功能优先级：功能较多时可通过表格的方式来简要描述涉及到的功能模块和优先级，以便于在人力不足或时间紧张时保证主要功能，放弃一些低优的部分；

名词解释：若需求中涉及一些生僻专业的词语，项目相关人员可能不懂，可以在此部分补充名词解释。

3.3 需求详细说明

需求详细说明中需要对每个模块的功能分别进行需求描述。需要注意的是，需求一般是新功能，产品经理需要明确定义每个页面和每个模块的名字，方便各方人员之间沟通时采用相同的口径，效率更高。

需求详细说明这部分需要注意的是规范、全面。需求文档也是产品的一部分，需要从用户角度去考虑，规范是为了易读性，全面是为了不遗漏。

我一般是按照模块/页面名称、原型图、详细说明（分点）的结构来写。描述每个功能时，考虑最常用的12个状态：等待/加载（loading）、初始态、输入、空状态、有数据、数据过多、关注、正确反馈、错误提示、待确认、结束态、中断恢复。

大部分状态很好理解，不再过多解释，关注态可能比较小众一些。关注态适用于特定场景，指用户在看但没有操作的状态，比如视频播放时用户观看视频。

在撰写这部分的过程中，为了使描述更清晰，可以使用各种图例来辅助表达，比如状态图、流程图等等。

3.4 埋点需求

做需求时需要考虑到需求上线后的效果监控，如果涉及到埋点，需要在文档中注明。工程师一般在提测前最后一步才会进行埋点开发，如果需求比较紧急的话，可以先评审其他部分进行功能开发，然后再补充埋点文档，做到敏捷开发。

3.5 需求版本及相关人员

在需求评审并确定排期后，如果公司没有使用项目管理软件，最好将需求版本和该需求的相关人员和排期均标注在文档中，后续需求有变动时可以直接找到对应人员。（但是，这部分主要是利好项目不相关的人或后面交接的人，所以大部分人往往不会补充这个模块）

示例如下：

04 小结

以上就是撰写需求文档的经验和方法。当然，需求文档的撰写没有硬性规定，清晰、没有遗漏即可，每个团队之间可能有不同的规范，核心还是让项目相关人员能够高效的读懂，方便工作更好地开展。