需求文档怎么写

很多产品新人入门产品时，最想先了解的都是如何画原型，如何写需求文档，今日小编就来和大家分享需求文档的写法，希望能帮到大家。

需求文档写的方法是：

1、需求背景与目标说明。得让别人知道为什么要做，要做到什么程度，用户检验功能完成情况。

2、特性列表。所谓特性，其实就是功能模块，把需要做的功能模块都罗列出来，主要用于明确需要做的功能有哪些，用图表体现更佳。

3、拆分标准。内部逻辑（不同的功能模块，不同的页面）、重要的特性单独列出。

4、主要逻辑。每个特性之下的操作逻辑，简单特性可以文字说明，复杂特性建议用流程图表现。帮助梳理逻辑，减少细节遗留。

5、特性功能点。补充每个功能点的相关细节描述，是开发，与测试工作的重要依据。

开发需求文档怎么写

如何写一份「不坏」的需求文档？

需求文档是产品经理最重要的产出物，它的撰写占据了许多产品经理50%以上的工作精力。然而在实际工作中，依然会存在着诸多问题，这是什么原因呢？应该如何解决？本文作者对此进行了分析，一起来看一下吧。

需求文档是产品经理最重要的产出物，没有之一。许多产品经理在实际工作中，需求文档的撰写占据了 50% 以上的工作精力，即使投入很多精力，需求文档依旧存在诸多问题。如：

1. 需求理解不清晰，挣扎在开发人员提出各种问题和重新沟通确认。
2. 解决方案没有形成闭环，缺少异常流程，重复返工需求文档；
3. 追求高保真原型，大量时间和精力花费在原型设计和交互，后期修改原型的成本高。
4. ……

出现这些问题的核心原因，是产品经理把需求文档当成一份开发交付文档，而不是当成「信息传递工具」，重点不在交付，而在于信息传递。

01 烦人的信息差

产品研发的信息传递，指需求方，实施方为了解决需求，进行需求和解决方案的信息传递过程。

需求文档，是承接产品信息的工具，最核心作用，是实现需求方，实施方的信息统一，减少因为信息传递问题，带来的「产品无法解决需求」 的情况。

信息传递面临核心问题的是：「信息差」。

信息传递本质是信息编码再解码的过程，需求方将想要传递的信息通过媒介进行编码输出，传递给接受者，接受者再解析理解信息的过程。

原始信息在传递环节会存在不同程度的损耗，导致需求方和接受方在信息上存在的理解差距的情况，我们称之为「信息差」。

导致出现信息差的原因很多，例如：

1. 需求方没有清晰表达能力（编码问题）；
2. 文本沟通，没有选择沟通效率更好面对面沟通（通道/媒介问题）；
3. 接受者对接受的信息理解出错（解码问题）；
4. ……

信息传递必定存在信息差，产品研发又存在「多人沟通」的常态化现象：

1. 需求方，人数不定，通常为老板，用户，产品经理等；
2. 产品经理，一般情况 1 人；
3. 技术方，人数不定，通常为前端，后端，测试等。

「信息差」「多人沟通」形成双喇叭型结构的信息传递模式，在横向传输上，拉长信息传递链。

即需求方编码 → 通道传递 → 产品经理解码 → 产品经理再编码 → 通道传递 → 技术方解码。

传递每个环节按 20% 的信息损失，至少有 70% 的信息在传递过程中被损失。

类似综艺节目的传话游戏，几个人站成一排，每个人都听不到前一个人说的话，只能通过前一个人的口型和肢体语言，猜测对方说的是什么，然后再传话给下个人。

一般到第三个人时，传递的信息和原来要传的信息是天差地别的。

纵向传输上，产品经理即接收多个需求方的信息，也向多个技术方传递信息。

一方面，多个需求方存在着多个需求，需求方往往传递自己认为可行的解决方案，不擅于阐述自己遇到的问题或真实需求。

产品经理需要花费大量精力辨别每个信息传递背后的真实需求，一旦有所疏忽，容易误解用户真实需求，掉入「用户说啥，实现啥」的陷阱，投入开发成本，但没有解决用户实际需求。

另一方面，产品经理要向多名开发人员传递思考后需求和解决方案，开发人员侧重于解决方案的实现可行性和成本，很少主动理解需求方的真实需求，主动与产品经理，需求方同步信息，减少信息差。

每个开发人员对信息的理解程度不同，理解需求和方案容易出现误差，开发过程中，容易出现以下问题：

1. 开发环节，开发人员之间理解差异导致方案差异，例如：前后端人员理解不一致，导致接口缺失，无法联调；
2. 测试环节，开发人员完成功能与测试人员测试用例不相符；
3. 验收环节，开发功能与产品经理预期不一致，产品功能无法满足需求。

出现上述问题，产品经理不得不重复沟通需求，花费大量时间促使所有开发人员达成信息统一。

02 标准化需求文档

需求文档是对产品开发的信息传递问题的解决方案，好的需求文档是能让所有人统一认知，从而提高开发效率的利器。

需求文档的好坏受限于产品经理能力和经验，高水平的产品经理属于小比例人群，所以我们不要求每个产品经理输出高质量的需求文档。

但，随着岗位和行业深入发展，产品经理的工作出现标准化趋势，意味着我们可以输出「标准化需求文档」，保证需求文档的下限，统一上下游对需求认知，减少信息传递过程的损耗。

标准化需求文档包含 3 个部分：文档结构化，绘制标准化，功能描述标准化。

1. 文档结构化

按照产品经理的工作流程，我们将需求文档的作业流程分为 4 项内容：「需求介绍」，「解决方案」，「修订记录」，「其他事项」。

各项内容都有各个细项，会在后续章节进行讲解，不再赘述。

2. 绘制标准化

绘制标准化，核心掌握是流程图的绘制标准化和低保真原型快速输出。

产品经理在流程图上经常犯 2 个问题：

一是多数产品经理为非科班入行，很少掌握流程图的规范，容易绘制错误规范的流程图，被开发人员按正确规范误解。

产品经理不需要掌握流程图所有绘制规范，只需要掌握 10 个常用简单绘制规范即可。

二是不考虑异常流程，异常流程分为 3 大类：

1. 全局型异常流程，指在系统全局都会出现的异常流程；
2. 功能型异常流程，指在功能操作和规则上出现的异常流程；
3. 业务型异常流程，指正常业务过程中，发生不符合预期的业务流程。

不同类型异常流程应用，我们会在后续「流程图篇」进行讲解。

产品经理在原型绘制上避免追求高保真原型和原型交互设计，需求文档的核心是传递需求信息，只要能达到目的，低保真原型和无交互设计都可以。

相仿原型和交互设计精细度越高，意味着我们投入原型设计的时间越多，理解和传递需求时间越少，本末倒置。

如何在极短的时间内输出一份低保真原型，我们会在后续「原型篇」进行讲解。

3. 功能描述标准化

功能描述是产品经理码字最多的地方，也是开发人员理解和落地功能点开发的根据。

开发人员在功能点出现理解误差的主要原因，是功能描述不标准，即遗漏功能点。

我们以信息流「下滑加载」为例，用户通过「下滑加载」功能获取信息，我们怎么写这个功能点？