产品经理的核心技能之一就是撰写需求文档，问题来了，产品经理怎么写，才能写出一份优秀的需求文档呢？本文作者便分享了自己日常写需求文档的结构，不妨一起来看看。

为什么写这个主题

在我初为产品的时候，也参考过不少需求文档。有的需要将原型转成图片贴在需求文档里，我认为这比较低效，不适合我；有的需要在axure里写所有的逻辑，包括业务流程图、数据流程图等，axure里对于流程图和文字排版并不友好，我参考过一段时间，后来还是觉得太低效，不能专注于文档的输出。最终选择的方式是在依赖语雀去写文档，非常高效。

有的公司里会用钉钉，用钉钉文档其实也可以，但是我感觉体验没那么好，不管是操作还是界面都没有那么舒服。

需求文档作为产品的其中一项核心技能，那么如何能够结构化地写出高水平的需求文档呢？

写了将近5年，我在不断地完善我的需求文档模板，让我不再为怎么写需求文档而烦恼，提升了我的工作效率。

下面分享我日常工作写需求文档的结构，希望能对你有帮助。

核心逻辑是什么

我认为一份需求文档有2个重点，一是核心逻辑，一是原型。

核心逻辑是你要在短暂的需求评审会议上深刻地讲出来的，并且会上的小伙伴听了之后能够清晰知道整个需求的逻辑。

而且我认为需求评审会议一定是先讲核心的逻辑再讲原型。逻辑一定是先行的。直接讲原型，听的小伙伴估计10个9个都会懵逼。我也听过不少同事是直接讲原型的，效果很差，作为一位产品我也听不懂会议。另外，人的精神总是会分散的，我们需要在会议的最前面把最重要的逻辑讲清楚了，原型其实也是围绕核心逻辑展开，能够把握核心，看原型也更好理解了。

原型也是不可或缺的重要一部分。

它是核心逻辑的具象，非常多细节，我们要在原型里尽可能描述清晰需求，不遗漏需求，考虑缜密。这不仅是我们逻辑能力的体现，更能够减少开发过程中的卡点——因考虑不周全而开发不顺畅或者延期等。总的来说，这个意义重大。

如果仅凭大脑在每次写文档时，费尽心思去枚举需要考虑的点，这会很费劲，工作效率低，在文末也总结了写原型文档的技巧希望能够对你有所帮助。

我们先来看看整个需求文档的结构。

从下面开始进入主题。

一、需求背景

在这个位置写我们的需求背景，也就是这个需求产生的业务背景。注意把关键的业务矛盾描述出来。如果需求有很多点，建议把较大的需求点的矛盾点都描述出来。这样的话，技术看起来会很清晰需求为何而做。对技术讲多点业务，这对做需求是作用很大的，技术越是理解，对需求的理解偏差越小。

二、需求分析

1. 现业务流程

描述现在的的业务流程，便于自己梳理需求以及技术后面看也会比较好理解需求。

2. 竞品调研

如果是做一个新产品，往往需要做竞品调研。将你的调研结果放上来，整个方案的说服力增加不少。

3. 总结

通过对现业务流程的分析以及竞品调研，你可以得到一个直指本质的结论——业务到底要什么。这个本质你其实也可以找业务确认一下，这样做之后基本你不会遇到做错需求的情况。

注意：

1. 现业务流程和竞品调研都不是必须的，但至少得有一个比较好。
2. 我还看到过不少人需求分析会写需要考虑什么内容，例如：需要考虑中台是否支持这个操作、需要考虑某业务方是否能接受操作多了一个步骤。其实这些都是方案里面需要考虑的点，我认为并不能算在需求分析里面。需求分析更多是求得需求本质。

三、方案概要

在这里写上你的方案概要，这个概要是基于你的可行方案写出来的。在这个时候其实你已经跟业务沟通过了，得到了沟通共识得到的结论。别人看到这个位置的时候已经能够很清晰地看到你想要怎么做，接下来在听你讲的时候脑子里就会带着方案概要听下去。而你也可以很自然地展开下面的方案内容。

四、方案内容

1. 核心逻辑

总的来说，在核心逻辑这个模块，更多是图文结合地将你的核心逻辑表达出来。我常用的图有以下类型的图。

1）业务流程图

有新的业务流程图时可以放在此模块。这个部分不是必须的，按需写。

2）数据流程图

相关数据流程图可以放在这里。当你做多了需求，你不从数据角度去分析一下流程，其实你会觉得有点太表面了，可能会有疏漏。当你把数据流程也梳理清晰了，那么会很踏实。这个部分不是必须的，按需写。

3）功能流程图

主要针对比较细致复杂的功能，通过梳理功能流程图，减少疏漏，也有助于技术理解流程。与业务流程图的区别是，业务流程图主要针对业务方的工作的流转，功能流程图主要是针对功能的逻辑，例如：登录的功能流程图。

4）架构图

在做比较大的系统时需要将产品架构写清楚，有助于你和技术理解系统。这个部分不是必须的，按需写。可能还有其他的图，大家按需添加。

2. 原型

在此附上原型链接。

3. 非功能需求

• 查询性能要求；
• 并发要求；
• 风控要求；
• 接口开放要求；
• 稳定要求；
• 时效要求；
• 等等。

4. 规划

如果有清晰的规划可以写在这里。可能有助于技术在设计数据库表的时候提前考虑未来的规划。

5. 需求变更记录

将需求的变更记录写在这里。

6. 其他

其他的什么都可以写在这里。例如，评审会议的目标可以写在这里，需求的最后期限可以写在这里，等等。

到这里需求文档就已经结束了。还有不少同学不知道怎么写原型的文档，下面开始讲解此部分。

五、原型撰写方法

1. 核心逻辑

我们通过分析与总结，其实页面主要就是这几部分组成：查询条件、字段、操作、权限。这是我们整个团队的逻辑思考成果，有很大的价值。在看toB老人家（王戴明老师）的书籍《saas产品经理从菜鸟到专家》时，我也看到他讲述原型是怎么写的，基本和我上一个团队想的是一样的。

所以大家真的要相信自己，大家想出来的东西其实是差不多的，那么差别在哪里？我认为是执行，也有执行速度，迭代速度。其实大家脑袋是差不多的，就是你想了之后有没有执行，有没有快速迭代下去。

2. 原型文档逻辑

3. 原型文档案例