用户需求文档怎么写？

       许多刚开始开发产品的人，首先要了解的就是如何绘制产品原型，如何编写需求文档，这是很奇怪的。比如在这个平台上可以搜索到大量关于需求文档的文章，告诉大家需求文档应该怎么写，但很少提到为什么要这样写？每个人都在关注如何实现，如何呈现，但并没有关注为什么会这样写？象许多大咖常说的术道一样，术重要，道更重要，知其然，知其所以然。下面就由小编为您带来用户需求文档怎么写的相关介绍。

畅写Office

3.2

20条点评

咨询产品

免费试用

解决用户选型困难的好软件，有各维度的信息

客户案例

暂无

合作品牌

57

一、需求文档的起源

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

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

   笔者常使用的方式为多年前从社会经济学老师那里学来的，做了补充和优化，分享给大家：在特定的时间、特定的地点、特定的人群因为特定的原因而做了特定的事件。达成该特定事件前，有哪些预期，实际达成的效果是什么样的，中间有怎么的落差，以后处理该类事件时，如何优化方式。

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

二、什么是需求文档？

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

1. 阐述

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

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

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

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

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

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

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

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

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

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

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

（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）设计规范

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

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

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

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

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

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

（4）功能列表

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

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

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

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

（5）角色列表

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

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

（6）框架图

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

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

（7）流程图

流程图分两个部分：

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

（8）功能需求

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

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

（9）非功能需求

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

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

    要求文档并非越详细越好，有许多不必要的说明，无需花费大量的时间来编写，最核心的始终是：让自己公司的相关人员能够快速看懂，全面了解。书不如人读，书不如人写，公司都不同。在充分了解相关协作方的情况下，产品经理应该站在自己公司的角度，输出他们所需的需求文档。以上就是小编为您带来的用户需求文档怎么写的相关介绍，希望对您有所帮助。