需求文档你怎么写？为什么这么写？如何写一份好的需求文档？

很多产品新人，入门产品时，最想先了解的都是如何画原型，如何写需求文档，这很奇怪。就像在平台上可以搜到很多关于需求文档的文章（截至当前，通过搜索关键词“需求文档”，有610条搜索结果），告诉大家需求文档要怎么写，却很少有说为什么这样写的？

大家把关注点都在放在如何实现，如何呈现，却没有关注为什么这么写？像很多大咖常说的术与道，术重要，道更重要，知其然更要知其所以然。

一、万物起源

碰到任何问题，最长见的思维方式即为：问题三要素——是什么、为什么、怎么做。这是几乎所有行业、所有人群面对事情时，最常见的思维方式。

笔者认为基于最经典、高效、实用的思维方式的基础上，可以每个人针对不同的知识体系、思考方式、经验总结等维度，总结出自己的思维方式。

笔者常使用的方式为多年前从社会经济学老师那里学来的，做了补充和优化，分享给大家：

在特定的时间、特定的地点、特定的人群因为特定的原因而做了特定的事件。达成该特定事件前，有哪些预期，实际达成的效果是什么样的，中间有怎么的落差，以后处理该类事件时，如何优化方式。

按照上述思维方式，我们将要写的需求文档当做一个特定的事件，通过剖析该特定事件被触发的前置条件、后置补充内容，来实现对需求文档的分析。

二、什么是需求文档？

笔者将需求文档定义为： 用于阐述产品，满足协同人员开发的内容文档。 该定义中有两个重要点：

1. 阐述

即为说明要开发的产品是什么。此处的“是什么”区别于产品说明文档，产品说明文档类似于商品说明书，用于告知使用者我的产品该怎么使用。

而此处的“是什么”是告知该产品的相关人员，该产品有哪些功能，这个功能要怎么呈现，该怎么实现。具体包含以下几个方面：

（1）为什么要做这个产品？

该产品是来自哪里的需求，是内部版本迭代优化、Bug修复、新增功能点，还是来自业务部门的需求，或者来自用户的反馈需求。

必须交代清楚做该产品的项目背景，一方面有利于开发人员更好的了解整体项目，从而更顺利地制定项目计划、项目进度、项目达成；

另一方面，产品开发完成后存档的文档，有助于后续对该产品的复盘、版本迭代，Bug问题溯源，甚至对出现人员异动时，有助于接盘人员快速了解项目，熟悉产品整体的前因后果。

（2）该产品要解决哪些冲突？

需求来自于用户的冲突，用户在使用中遇到了什么困难、疑惑、焦虑等不可调和的问题等待被解决。

在与用户开展调研、访谈等沟通时，充分了解用户的冲突，及急需解决的痛点，有助于产品经理在产品规划阶段，更精准地把握好方向，做出更符合用户诉求的产品。

同时，在了解冲突的沟通中，除了精准获取到用户的核心诉求，还会得到很多非核心诉求，这些来自于用户潜意识中的需求，为以后产品的发展提供了很好的帮助。

将这些需求罗列出来，整理到需求池，有助于以后与用户、业务进行再次沟通时作对比，从而去伪存真，对需求池中的需求做好优先级排序，并根据实际业务发展阶段和公司整体要求，划分好产品阶段，对需求池中的需求进行实现，从而促使产品朝向更好的方向发展。

（3）该产品实现了哪些目的？

任何产品的实现，不仅仅要满足用户的需求，更要在解决冲突时达成更多的目的。而这个目的分为物质层面和精神层面两个维度。

1）物质层面

产品的上线，解决了公司业务层面的流程，满足了业务需要，满足了用户的使用，这是产品首要，且是最核心的目的。

而在满足最核心目的之后，是否有一些延伸的产品需求——减少了操作步骤、优化了交互流程，为实现公司层面的获客、激活、留存、转化、二次推广等各环节起到促进作用。

2）精神层面

产品的上线，解决了用户的困难、疑惑和焦虑，解决了业务部门无法正常使用过程中的烦躁不安，这是产品最核心的目的在用户心里的反馈。

同时，在解决用户优先级最高的负面情绪的前提下，使得用户对产品的感官，对企业品牌的好感度提升，是产品上线所能达成的最好效果了。

2. 满足协同人员

即该需求文档是给哪些协同人员看的。 此处的“协同人员”不仅仅是开发人员，而是产品从交付原型至最终上线，过程中所涉及的所有参与者。

这些协同人员基于各自岗位和职责，对需求文档的要求也是不一样的，这是所有产品经理在编写需求文档时应尤为注意的点。

以笔者当前的公司为例，协同人员包括以下群体：

1. 产品经理：大部分公司都会有不止一个产品经理。每个产品经理在负责自己的产品线时，所输出的需求文档对其他产品经理的工作是有必要性的。
2. 设计师：以做静态页面、gif图、交互设计等视觉体验的专业人员。
3. 前端开发：以输入静态页面、交互动效为主，包含各类判断逻辑，最终以HTML为输出样式的专业人员。
4. APP开发：用户能看到的APP的页面样式、交互样式、逻辑输出的专业人员。
5. 后台开发：后台建表、设定逻辑规则，接口传输数据、字段的专业人员。
6. 测试工程师：检测产品在常规环境、非常规环境，检测所有存在因素及隐患的专业人员，是确保产品上线无Bug的最后一道防线。

3. “阐述”与“满足协同人员”间的关系

凡事的存在，皆存在因果。满足协同人员，此为因，而为了满足协同人员，输出的需求文档，即为果。因果之间互相作用，促成了产品最终的交付及上线。

三、需求文档的意义是什么？

把正确的东西交给正确的人，满足协同人员的诉求，即是需求文档存在的意义。

如何写出满足协同人员诉求的需求文档？首先，需要观察不同的协同人员具体的工作场景，基于他们工作场景中的冲突，发现他们的需求，从而输出的解决方案，就是最好的需求文档。

1. 产品经理的诉求

（1）产品部门的版本需求讨论、需求评审会。

在版本任务的讨论中，在与其他产品经理讲述所规划的功能时， 版本记录、项目背景、项目框架图、流程图，可以快速让其他产品经理了解整体项目，并根据项目背景，给出意见。

（2）与其他产品经理所负责的内容有交叉点。

当一个完整项目，每个产品经理负责部分内容的时候，各自负责部分功能的需求文档有助于其他产品经理从文档中发现交叉点中的衔接是否合适，各功能模块的整体融合性。

（3）Bug处理。

再厉害的程序员也不敢保证产品上线后不出现任何问题，当产品上线后出现问题，需求文档有助于产品经理快速找到规划的初衷，根据之前的情境给出精准的解决方案。

（4）版本迭代。

当产品在不同时期，做不同的版本迭代时，之前的需求文档尤为重要，有助于负责该项目的产品经理快速熟悉往期规划的初衷、目的和当前的效果及不足，并在迭代版本中对往期问题进行修复，在新的规划中避免不必要的坑。

（5）人员异动。

如果出现人员异动（人员项目变更、人员离职等），有助于新接手的产品经理快速熟悉项目，确保项目规划不会因个人经验、个人喜好、习惯等原因，出现太大的偏差。

基于以上场景和目的，其他产品经理对需求文档的诉求需要得到的信息：谁、在什么时间、因为什么原因，做了什么内容，满足了什么人的需求，变动内容及节点、阶段性规划。

2. 设计师的诉求

设计师是项目实施阶段的第一步。确定版的需求在落地执行时，首先是由设计师开始制作设计图。项目的整体功能有哪些、基于什么背景、未来的规划方向，需要在文档中给出建议和说明，有助于设计师按照产品经理的设想，设计出符合或高于期待的产品设计图。

基于上述场景和目的，针对设计师角色，产品经理在编写需求文档时，需要告知的信息：因为什么原因，给什么特点的群体，做什么图，当前竞品什么情况、公司什么情况、市场什么情况，想达到什么效果，后期发展方向（业务、功能、设计方向等）。

3. 开发人员的诉求（前端、APP、后台、测试）

1. 前端开发：开发过程中，侧重了解涉及前端部分的页面功能、交互效果、交互逻辑；
2. APP开发：开发过程中，侧重了解页面元素、页面样式、功能、与后台间的接口参数传递；
3. 后台开发：开发过程中，侧重了解功能、这些功能在后台的数据结构搭建、如何建表、功能逻辑、与前台兼的接口参数传递；
4. 测试工程师：在产品实现过程中，侧重从产品规划中了解整体功能，从而写测试用例，以及产品上线前根据设计图的样式、文档表述的功能规则，做功能测试。

基于删除场景，产品经理在编写需求文档时，需要告知开发人员的信息：因为什么原因，针对什么项目，做什么功能，包含哪些页面元素、页面样式、交互逻辑、实现效果。

4. 注意事项

尽信书不如无书。各公司的组织架构、部门角色划分、业务开展的推动因素、公司发展所处的阶段均不相同，虽大道同源，但总有差异化表现。

需要产品经理针对协同人员做好分层、分类，切实与相关人员深入沟通，了解他们的习惯，了解他们的认知，输出他们需要的需求文档，才能够确保信息的透明化，保证开发人员全面了解规划的内容。

同时，辅助以良好的沟通机制和技巧，则有助于开发效率的提高和产品上线的进度保障。

四、如何写需求文档？

1. 写文档先看人

需求文档与产品经理前期做用户调研时的用户画像很相似。

在做用户画像时，通过与目标群体各种方式的沟通，获取用户的基本信息、兴趣、习惯、家庭情况、对产品相关业务的了解程度、接受程度、烦恼和期待等等，从而建立用户档案，输出用户的判断结果。

在写需求文档前，面对我们的用户——相关协同人员，产品经理需要去了解他们。了解他们的工作方式、工作习惯、工作态度、工作认知、工作能力等与工作相关的内容，同时，对他们与人相处的方式、生活习惯、兴趣爱好等等的了解，有助于产品经理更全面的了解，从而建立更加立体的用户画像。

在输出判断结果时会更准确，写需求文档会更有侧重点——哪些是他们需要知道的，哪些是他们需要特别详细表述的，哪些是需要特殊标注的，哪些是省略表述即可的。

2. 文档规范

（1）版本记录

1. 谁：该文档是谁编写的，便于快速找到对应的负责人员，同时，后期有助于在需求文档库中建档分类。
2. 时间：什么时间编写的该文档，旨在告知该功能是什么时间要开始做，便于后期溯源时，快速定位。
3. 事件：针对什么产品、什么功能做的规划，其实就是文档标题。
4. 版本号：便于记录产品不同版本的节点做了什么内容及调整，同时，针对不同的系统，有助于使用统一的版本号做管理。
5. 上线计划：依据上线计划倒推测试周期、开发周期、设计周期，从而给参与该项目的协同人员约定好时间，便于更好的把控项目进度。
6. 评审及修改：项目完成后的需求评审建议和结果，针对初稿内容做了哪些修改。此处一定要详细，后续调整内容时，评审建议和修改事项是很重要的可参考的细节点。

（2）版本说明

1. 项目背景：清楚地写出为什么要做该项目，谁要求做的。
2. 核心需求：为了解决什么冲突。
3. 预期目的：想达到什么结果，后续有什么进一步的规划。

详细的项目背景有助于所有参与人员快速地了解项目是怎么回事。

（3）设计规范

设计规范来源于产品经理对该产品的整体了解：在做完市场分析、行业分析、竞品机构分析、用户调研之后，针对自己要做的产品，产品经理会形成自己的整体构思和产品走向模型。

而这个构思就是需要表达给设计师的理念——要做一款什么样的产品，要达到什么效果。

关于设计理念的表达，不同的公司有很大的差别，以及整个行业对这块内容都没有统一的观点。

一种观点认为，产品经理只需要输出黑白灰原型图即可，其他的都交给设计师处理，给设计师足够的发挥空间；

另一种观点认为，设计师对要做的产品，不了解缘由，直接去设计会有偏差，最终交付的产品大部分都不符合；

还有种观点认为，要看设计师的水平再来决定，水平高的不需要产品经理说什么，都可以交付足够让人惊艳的设计，水平低的说再多，也做不出效果，而大部分公司都属于第二种情况。

综上所述，岗位不同、职位不同、个人认知的不同，以及最重要的信息接收到处理个人间都是有差异的，最终呈现在产品上的内容就会有很大的差异。

而规避这类问题，最好的方式还是沟通。 充足且有效的沟通，确保产品经理与设计师间的已知信息达到一致，双方的理念、想法、建议等越碰撞越容易做出更好的产品。

主要对接的内容包含两个部分：

1. 信息与意向：传递产品信息，告知设计师关于该产品的设计原因、行业情况、要做的产品对标竞品是哪些，以后对产品的规划是什么、产品经理的意向是什么。
2. 基础设计理念：产品主题、整体色调、各样式的字号、色号、全局页面的建议等。

（4）功能列表

功能列表为产品经理在经过足够多的调研和分析，从汇总的产品需求池中筛选出的当前应处理需求列表。

功能列表的作用为便于相关人员全面了解产品的功能，从而评估项目周期、处理优先级等。

功能列表主要表述都做什么功能，哪些重要且紧急。列表参数包含：

1. 模块
2. 功能点
3. 功能点描述（详细）
4. 优先级（高、中、低）

（5）角色列表

角色列表为表述清楚该产品上线后，参与到该产品中的群体有哪些。列表参数包含：

1. 角色名称
2. 职责：在产品参与中的简要说明
3. 备注：特殊情形

（6）框架图

框架图为该产品包含什么内容：模块、功能。便于开发人员快速、便捷的了解产品全局。

框架图没必要做的很高大上，高大上固然很好，会让使用的人赏心悦目。但是，功能介绍简单易懂和开发人员能看懂、看明白更重要，千万不能舍本逐末。

（7）流程图

流程图分两个部分：

1. 整体流程图：整体流程为将产品各大模块之间的交互流程，一般做正向流程居多，辅助以部分判断流程和异常处理机制
2. 功能流程图：功能流程为涉及到具体的功能点的交互流程，包含：正向流程、规则、判断流程、异常流程。

（8）功能需求

功能需求为具体的各功能点，是需求文档的核心。主要是详细的分解各功能点，包含两个方面：

1. 前端：针对前端部分，页面如何来、页面元素、各功能点的规则、交互、跳转规则、非常规流程的页面元素、交互、跳转规则等等。
2. 后台部分：前端功能的实现，依靠后台的哪些逻辑和数据，是否需要做新功能模块、新功能模块的内容、数据的调用、存储、接口数据传值等等。

（9）非功能需求

非功能需求为用户常规操作产品时的极端情况，涉及很多内容，以下列举几个比较重要且常规规划中需要考虑的点：

1. 产品性能：产品对用户操作的响应、对群体操作的并发预防等。
2. 安全性：公司数据、用户信息的保密性处理，不同角色的权限设置、使用中的限制等。
3. 可靠性：用户操作中出现异常情况，是否可继续操作，遇到异常情况时数据或使用状态是否可被恢复等。
4. 拓展性：拓展性主要针对公司内部而言，产品完成后，无论是设计师、开发人员，还是测试人员，针对产品所做的工作，是否可以被复用到其他地方。用户在产品中的使用情况是否可被系统获取后用作不同维度的分析等。

五、多说一句

需求文档中，对于功能的表述是尤为重要的，针对各功能点考虑的越详细，越有利于开发人员评估实现难度、评估时间、顺利达到所要的效果。

六、最后一句

需求文档不是越详细越好，很多没必要的说明，不用耗费大量时间去编写，最核心的依旧是：让自己公司的相关人员能快速看懂，全面了解。

尽信书不如无书，各公司均不一样。产品经理应更多的站在自己公司的角度，在对相关协同人员充分了解后，输出他们需要的需求文档。

本文由 @kuang 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: