编辑导语：产品需求文档撰写可能是产品经理必备技能之一。而在撰写需求文档时，我们应当先了解需求、从而可以更准确地下笔。那么，文档撰写是否有什么注意事项？本文作者就结合其案例经验向我们阐述了需求文档的一些要点事项，让我们一起看一下吧。

各位大大好，我是一枚工作一年的产品小白。撰写产品需求文档是自己工作职责的一部分，下面分享一些自己对需求文档的理解，如有不当，还望各位大大多多指教～

本文分为如下4个模块，全文约3500字，阅读完毕大约需要5分钟。

1. 为什么要写产品需求文档；
2. 需求文档需要注意的一些点；
3. 实际案例；
4. 个人小结。

一、为什么要写需求文档

在我看来，写需求文档的目的主要有如下几个。

1. 明确产品需求，避免遗漏

一个项目的需求有很多，把需求都记录在文档里并把具体的逻辑缕清，这样能避免需求遗漏，同时方便管理。

2. 方便其他人员查阅，降低团队成员的沟通成本

当团队其他成员需要了解项目需求时直接阅读文档就好了，也方便了产品经理离职时的工作交接。

3. 信息存档，作为功能开发的依据

如果开发出的功能不合预期，那么文档可以作为依据，避免出现相关人员之间相互推诿责任的情况。

二、需求文档需要注意的一些点

文档是写给别人看的！文档是写给别人看的！！文档是写给别人看的！！！

既然文档时给别人看的，那就应该让读者以最小的代价去看懂文档。所以文档的结构、可读性、对产品描述的完整性和对文档的维护更新非常重要。

1. 文档结构

个人理解的文档结构是整个文档是由哪些内容组成的，它们的层级关系是怎样的。比如在一级标题下分别有哪些二级标题，每个标题的具体内容分别讲什么。

合理的结构可以让文档内容有条有理。可以先规划好整体的文档结构，然后再开始写具体的内容，建议打开word或WPS中的导航窗格，方便预览文档的整体结构，也方便快速查看某个模块的内容（单击视图中的导航窗格即可打开）。文档结构规划图示例：

如果是B端产品的文档，可能还会涉及一些非功能性的描述，比如安全性、与其他系统的数据交互规则、数据的存储备份规则等等。其实没有标准的文档结构，具体看项目情况来定，能把需求明确清晰的表达出来就行了。

在WPS中打开导航窗格：

2. 文档可读性

文档的可读性还是蛮重要的，先不说内容写得怎么样，起码排面要有，特别是一些要交给客户和领导的文档，没有排面可不行。如果想要文档具有比较强的可读性，需要注意以下几个点。

1）大段文字描述时，可以分点描述的内容就分点描述（以有序列表或无序列表的形式分点），同时也要注意内容的分段。示例：

2）尽量以表格的形式去展现内容，比如描述同一个事件的多种状态时，用表格就比用大段文字合适。示例：

3）如果有某些需要重点强调的内容，可以给字体标上一些显眼的颜色，以便让读者一眼就能注意到，特别是大段文字描述时，更应该突出重点内容，以便读者能捕捉重点信息。示例：

4）文档里的配图/表格加上题注，让读者知道这个图/表主要想表达什么内容，减少读者的认知成本。通过通配符可以批量为图片设置自动题注，有需要的小伙伴可以去百度一下。示例：=

5）此外还有一些细节。

文字的行间距、段落的段间距在很大程度上也会影响文档的视觉效果，行间距、段间距太小，文档看起来会显得很拥挤，太大文档看起来会显得很松散。

至于行间距和段间距要设多少，就要看正文字体是多大了，比如5号字体比较适用单倍行距，具体的大家可以去百度一下，反正看起来顺眼就行。

3. 对产品描述的完整性

对产品描述的完整性是指尽可能的把一个产品的功能规则全部描述出来。

比如短信验证码的相关规则包括：多久能获取一次验证码、某段时间内最多可以获取多少次验证码、验证码有多少位数、有效期是多久等等。

如果对产品规则描述得不齐全，可能会导致程序在开发时遗漏掉某些功能（有些程序真的是按照需求文档进行开发，完全不多想其他），别人读起来也可能会感到疑惑：为什么这个功能没有对xxx进行限制啊？

个人觉得要想做到尽可能全的把规则罗列出来，可以从以下3个方面着手：

1）写文档前一定要先把产品吃透，自己要先知道开发这个产品是为了解决什么问题，有哪些功能和相关规则，各个功能模块间的关系是怎样的，有哪些需要特别注意的点，同时要能熟练地使用产品。

如果自己都没有把产品吃透，那很难写出文档的。

2）培养自己全方位思考问题的意识。一件事情发生前、发生时、发生后的规则分别是什么，是否有什么前置条件或特殊条件，如果某个条件不满足会怎么样等等，自己要主动有这样的意识去思考，而不是单纯的靠经验，想到什么就写什么。

平时可以有意识的去训练自己，让自己养成这样思考问题的习惯。

3）多体验各种产品，研究它们的功能都有些什么约束规则，为什么要这么设计（比如淘宝的搜索框是怎样设计的，具体有什么规则，为什么要这么设计）。

可以对各种情况进行尝试，比如在填写某个信息时故意输入很多位数，探究其对输入信息的校验。也可以多看一下别人写的需求文档，里面也会对规则进行约束性的描述。

总而言之就是要多看文档或多体验其他产品，让自己知道，这一类功能要进行这样的约束，是怎样进行约束的，而且也可以在这个过程中让自己形成全方位思考问题的意识。

4. 文档维护及更新

对于这个方面，个人的做法是这样的，每一个功能模块就起一个文档来写，如果把所有的功能都写在一个文档里，文档会非常的冗长，而且不利于分工进行开发。

实际案例：一个项目由多个产品经理同时负责，每个人都负责相应的功能模块，如果把需求都写在一个文档里的话，会很难同步各方的信息（用云文档可以解决信息同步困难这个问题，但我们公司没有这样做）。

每次对功能进行改动后，就复制一份文档，然后在上面更新改动的内容，并给一个新的版本号，大版本直接由1.0升到2.0，小版本就由1.0升到1.1，如果是很小很小的改动，不给新的版本号也可以，直接在当前最新版本的文档里写就好了。

同时还要写明版本信息，说明是谁改动了文档，什么时候改的，相比于上一个版本改了什么东西。一个功能模块的文档经过多次迭代后是这样的：

三、实际案例

版本信息

1. 需求概述

1）需求来源

对多款竞品进行分析并结合产品自身战略方向得出需求。

2）需求目的

提供多种登录方式供用户进行登录，减少用户登录的操作成本，降低用户流失率。

3）功能说明

2. 登录功能需求

1）UI原型图

2）功能流程图

3）前端规则

手机号登录

• 手机号要输入11位数，否则提示：手机号格式错误。暂不考虑海外手机号码登录。
• 60秒后才能再次获取验证码，在此期间，获取验证码按钮置灰不可点击且显示倒计时动画。
• 手机验证码最多能输入5位数，否则提示：验证码格式错误。
• 手机验证码错误则提示：验证码错误。
• 输入了过期的验证码，则点击登录后提示提示：验证码无效或已过期，请重新获取。
• 在第5次获取验证码时弹出提示：验证码已发送，请在[下次可获取验证码时间点]再次尝试获取。在验证码冷却期内再次点击获取验证码按钮，则提示：请在[下次可获取验证码时间点]再次尝试获取。
• 根据后端返回的标志判断是否为第一次登录，如果是，则登录成功后进入创建账号流程，否则直接进入APP。

账号密码登录

如果登录失败则弹出提示：账号或密码错误，请重新输入。

社交账号快捷登录

单击社交账号登录按钮后，根据相应社交APP的状态作出响应：

其他

• 单击“账号密码登录”可以跳转到账号密码登录的界面，单击“手机号快捷登录”可以跳到手机号快捷登录的界面。
• 单击登录遇到问题可以跳到“常见问题解答”界面。在两种登录模式下都是跳到同一个界面。

4）后端规则

手机号登录

• 以第1次单击获取验证码按钮的时间点为准，同一手机号一个小时内最多可以获取5次短信验证码，以单击第5次获取验证码的按钮时间点为准进行计时，60分钟后可再次获取验证码。比如在7:24:00第1次获取验证码，则在7:24:00—8:24:00期间只能获取5次验证码。
• 获取验证码后需要等待60秒才能获取下一次验证码。
• 验证码有效期为5分钟，发送多个验证码时以最后一个为准。
• 如果该手机号为首次登录，则返回标志至前端。

账号密码登录

如果账号或密码错误，或账号不存在，则返回登录失败标志。

社交账号快捷登录

每个社交账号都可以创建一个独立的账号，例如使用qq/微信登录的账号，它们之间的数据不共享。

5）测试要点

各个功能是否遵循如上规则。

四、个人小结

这篇文章主要是讲文档的结构和关于可读性的一些注意事项，都是一些偏展示形式的东西，但要真正写好一份文档，对产品的熟悉和理解才是最关键的，个人觉得，一份好的文档=好的想法+好的展现形式。

文章中的登录功能是是参考了简书，上面关于社交账号登录的描述不是特别详细，有兴趣了解的小伙伴们可以去下载APP自己体验一下。

小弟目前经验尚且不足，欢迎各位大大对文章做出评论～

本文由 @活蹦乱跳的大咸鱼 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。