编辑导读：产品需求说明文档（PRD）可以将产品设计思路清晰的展现给团队人员，便于他们快速理解产品。那么，产品需求说明文档该如何写呢？本文作者结合多年工作经历，分享了关于产品需求文档形式、规范、自查相关的非常有用的知识，供大家一同参考和学习。

本文总结一个最基础的话题：PRD。

目录：

一、PRD的形式

二、PRD的规范

三、PRD的自查方法

一、PRD的形式

1. 原型附带文字

移动端产品当然是把产品DEMO展示出来为第一位。

附带的文字，多是对原型的交互的说明、取值逻辑说明等。

比如这样：

文字较多的，可以把原型靠右的部分都分简单排版。比如这样：

2. 文字附带原型

逻辑过重的后端需求，干脆就使用Word/Excel/TXT格式的PRD。好处是在行文的过程中，可以二次梳理思路，暴露问题。一般这样的需求文档都包括：

版本说明(含变更日志)、背景、目标、需求范围、需求用例（正文，包含所有核心内容，如功能逻辑说明等）、参考资料等。

（1）需求背景

• 现状当前业务流程怎么了，当前功能是怎么样的，问题是什么，需要怎么办，以达到什么目标。
• 用户故事也可以更简单的以“作为谁，希望通过什么，实现什么”这样的用户故事形式也可以。
• 场景是需求的外在，拆解和穷尽需求场景，为穷尽功能和逻辑规则打基础。

拆解需求场景的方法：

• 按业务顺序，想象或模拟用户操作顺序；
• 按目标生命周期，比如草稿、待审核、审核中；
• 按正常、异常、正向、逆向，形成交叉矩阵。

（2）需求目标

用户角度的验收标准，即从效果的角度表达需求的预期（不表达如何实现）。

例如：

a、用户在点击页面之后3秒内必须加载完成。

b、用户能看到自己买到的商品。

c、用户可以删除自己的商品购买记录。

（3）需求范围

需求范围就是描述需求的目标项、边界、排除项，其作用是理清边界。

目的是防止需求蔓延（参考PMBOK指南）。

需求范围可以使用功能框架图。

（4）需求用例

需求用例是需求的正文部分。

先将需求分成任务点，进行描述。

描述的语句要严格按照文档语法原则进行（下文会继续聊到）。

如下图：

（5）参考资料

参考资料部分，附上调研过程中查到的相关模板、数据表、脚本、接口地址、历史文档、原型链接等。

二、PRD的规范

这里主要以Word样式的PRD为对象。

1. 需求文档的语法

（1）说明文一字千金

需求文档就像是说明书一，去掉形容词、比喻句、副词等。

能用一句话说明的就不要说第二句。

（2）避免用词不当

在文档或口头交流的时候，经常用到诸如“维度”、“颗粒度”、“参数”、“字段”、“项”、“列”、“表”等词汇。

产品需求文档中，要做到用词严谨，避免词语歧义或失准。

常见用法例如：

• 以“订单号+产品编码”的[维度]进行唯一性判断；按照“订单”[颗粒度]进行汇总；
• 以“时间”作为请求[参数]；
• 数据库的[字段]为“number”；
• 页面搜索栏的“姓名”搜索[项]；
• 页面列表的“年龄”[列]。

（3）按顺序描述

开发和测试人员通常希望将一个模块的工作做完，再进行下一个，而不是来回跳。

因此行文顺序上，按照先后、左右、大小等常规的顺序进行，一个模块写完再写下一个。

前面写过的内容，后面不要再写了，避免歧义。

比如：要在已有接口增加获取一个字段，并在页面展示，可以这样两步描述：

1. 在xx接口，增加xx字段，存入数据库xx表。接口逻辑调整为xx。旧数据初始化方案是xx。
2. 在xx页面列表中，新增一列“xx”，对应取值是数据库xx表中的字段xx。

（5）以“在哪里，做什么”为主线

文档以任务线为核心句式结构，即：“在哪里，做什么”。

尽量用正向语序，不要倒叙，也不要用括号或破折号。

比如避免前面描述完，后面又接着一个“即xxxxx”、“也就是说xxxxx”。

（6）非本需求的功能，不要放在文档中

产品经理是信息布道者，信息中枢。

而开发和测试人员，是希望所见即所得的阅读方式。所以不必要的任务不要加入进来。

比如不要使用“可能这次要做”、“注意，这个本次不做，只作为提前知悉”之类的内容。

正文一定传达的是“做什么”。如果想补充，那么放在参考资料部分。

（7）采用合适的行文结构

1）如果需要在旧功能基础上做优化，可以用对比结构进行描述，比如：

• 修改前：xxxx；
• 修改后：xxxx；

2）对于并列条件较多的，可以用平行列举的结构描述，比如：

每天一次，定时监控【退款单】(表f_oms_refund)，若同时满足下列条件：

同时满足上述条件，则进行数据抓取。

1. 数据更新时间为前两天；
2. 退款成功的（refund_status为：2、5、8、12、24任一个）；
3. rma_sn不为空；
4. order_sn已存在于【发票列表】中。

注意：如果不熟悉数据库，建议不要写数据库，而是要写清楚页面取值位点并配以截图，避免弄巧成拙。

3）如果需求点有多个，但属于同一个页面功能模块下的，那么可以放在一个用例中，分点描述，就像书本的目录一样进行编号。

（8）穷尽原则

“穷尽”是方案严谨的基础。

穷尽包括穷尽需求的功能点，穷尽每个功能点的要素，穷尽每一个逻辑判断、性能要求、异常机制、用户权限等。

比如：做一个新页面，就要从导航栏目、界面交互、搜索功能、网站介绍性文字、默认列表展示内容、列表数据统计等全部说清。

同时对于后端产品而言，基本上每个需求都要说明性能要求、异常机制等。

（9）最后，不要遗漏对性能的要求、对历史数据是否处理、以及权限要求

性能的要求，如果不懂技术术语，则写出性能支持的数据或现象范围。

比如：预计半年内数据量为100万/天，要求接口响应3s内。

历史数据是否要初始化，及与发版的时间顺序。

权限就是赋予页面数据、功能权限。

2. 通用项进行统一

（1）命名统一

页面一些常见的插件的命名可能有多个版本，产品经理需一开始就在需求文档中确定用哪一个。

比如下面这几组意思相近的插件名称：

1. 表示删除或禁用的：删除、禁用、关闭、封存；
2. 表示启用的：开启、启用、生效；
3. 表示设置的：配置、设置；
4. 表示编辑的：编辑时间、修改时间、更新时间、操作时间。

（2）数据库表中的通用字段命名统一（开发负责的）

比如：

每个开发习惯不同，所以要固定用哪一种，避免千人千面。

1. 是否已写入：用“is_use”、“is_used”还是“is_write”表示？
2. 已写入/未写入：用“1/0”，还是用“1/2”表示？

笔者曾经遇到一个开发比葫芦画瓢，把“goods_sn”（商品编码），写成“good_sn”，这就闹笑话了。

（3）页面展示统一

比如：数据表为空字符串时，前端展示什么，是显示“/”，还是空白？

（4）文档命名统一

可以使用日期+模块名+需求名称+作者+版本号，例如：20180920_【个人资料】编辑个人资料优化_张三_V1.0。

（5）术语名词定义统一

比如跨境电商行业的“清关”、“保税”、“头程运费”、“尾程运费”、“大包”、“小包”等。

三、PRD的自查

PRD可形成一套自查规则。笔者抛砖引玉。

1. 按功能插件自查

（1）输入框

需限定输入的范围，做输入校验。示例：最多输入10个数值，输入不合规则的内容，则在输入框下方红色字体提示，比如：“请不要输人汉字！”。

（2）下拉框

下拉的同时是否支持输入搜索，是否支持多选。

（3）导入文档

表头校验、自校验、与系统校验、写入逻辑（全部不予导入或部分导入)、下载结果文档；

（4）已有功能的逻辑规则变更

则要考虑旧数据兼容或初始化。

（5）基础数据删除

则要考虑基础数据被调用的地方，删除和编辑怎么处理。

比如：商品分类中维护的“商品类型”被删除，那么再编辑和删除该分类下的历史数据的时候就可能报错，所以基础数据维护时候要校验调用情况。

（6）设置规则

考虑规则去重、规则优先级。

一般情况下，没有优先级的话，规则的去重和命中次序校验起来比较麻烦。（在<后端产品经理宝典>一书中有专门介绍）。

（7）列表的数据的排序

一般按照修改时间的倒叙排列，也可以用数据库id代替序号。

用数据库id的好处是，方便用户和技术协作追溯数据。

（8）异常机制

每时每刻都要有逆向思维，告诉开发人员什么算异常？异常了怎么标示出来。

比如：表1字段A，匹配表2字段B，将匹配成功的数据写入表3。就要考虑表1中字段A为空的情况该怎么办。

（9）页面长期不登录

则给自动退出。主要考虑到后端系统的保密性。

（10）凡是带操作的

一般都要设置页面权限。

最简单的方式是所有系统的权限都分三个等级：不能查看、只能查看、可以编辑。

（11）功能修订

比如规则变更，需要考虑旧数据是否要按照新规则进行初始化。

2. 按需求类型自查

（1)功能需求

需要穷尽功能覆盖的使用场景，穷尽本功能相关联的各个系统模块，穷尽本功能的用户角色、权限。

（2)性能需求

数据量较大时的系统压力、反应速度；

批量上传、下载要考虑数量上限，考虑是否异步处理；

考虑浏览器兼容性；考虑调用接口超时的备用策略等。

（3）安全需求

敏感词屏蔽（同步过滤和异步召回）、防刷单机制、数据补推机制、风险预警等。

3. 关键词提醒自查

笔者不完全罗列了几个关键词，可以作为自查的维度。

（1）完整流程是否存在断头路。

（2）逆向功能流程是否可逆，如果逆向操作，是否考虑对应的机制：比如退款、退货操作。

（3）异常即异常机制。各个步骤都可能出现预期外的情况。

（4）歧义需求文档的语法、功能文案、名词是否易懂，是否存在歧义。

（5）兼容是否存在兼容问题：不同业务人员对功能都能接受吗？各个系统之间兼容吗？新旧功能的兼容吗（比如历史数据要不要初始化）？

（6）备用是否有备用方案，次级选项。

比如当正常流程无法传输的时候，是否可以用导入的机制救急。业务高峰的系统，是否有降级处理逻辑。

（7）穷尽业务场景和可能原因是否穷举完毕。

默认：是否给予了默认值。

比如设置规则功能业务未设置怎么办？

（8）脱敏是否存在敏感信息，是否有脱敏机制。

4. 其他

自查的方式还有很多，比如也可以按照“增、查、改、删、显、传、算”自查等。

总结

需求文档最基础，努力做到心中有典型功能，逻辑自查举一反三，需求要点不缺失，文档内容不歧义。

产品经理要养成好的态度和习惯。比如：

1）保持学习学习其他人的文档书写长处，可以把好的东西借鉴过来，吸取精华。

2）要自己多看多换位思考，揣摩他人是否能读懂，把问题止步于自查。

3）请求同事（包括产品经理、程序员、测试员等）帮助互评自己的文档，接受对方的建议。

4）文档是改出来的，因此自己写好后，放一段时间再看，再改。

#专栏作家#

唧唧歪歪PM，公众号：唧唧歪歪PM（ID：jjyypm），人人都是产品经理专栏作家。书籍《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交APP。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议