4千字，总结产品需求文档的形式、规范、自查

逻辑过重的后端需求，干脆就使用Word/Excel/TXT格式的PRD。

好处是在行文的过程中，可以二次梳理思路，暴露问题。

一般这样的需求文档都包括：

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

（1）需求背景

• 现状

  当前业务流程怎么了，当前功能是怎么样的，问题是什么，需要怎么办，以达到什么目标。

• 用户故事

  也可以更简单的以“作为谁，希望通过什么，实现什么”这样的用户故事形式也可以。

• 场景

  是需求的外在，拆解和穷尽需求场景，为穷尽功能和逻辑规则打基础。拆解需求场景的方法：

 按业务顺序，想象或模拟用户操作顺序；

 按目标生命周期，比如草稿、待审核、审核中；

 按正常、异常、正向、逆向，形成交叉矩阵。

（2）需求目标

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

例如：

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

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

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

（3）需求范围

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

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

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

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

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

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

如下图：

二、PRD的规范

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

1、需求文档的语法

（1）说明文一字千金

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

（3）避免用词不当

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

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

常见用法例如：

 以“订单号+产品编码”的[维度]进行唯一性判断；

 按照“订单”[颗粒度]进行汇总；

 以“时间”作为请求[参数]；

 数据库的[字段]为“number”；

 页面搜索栏的“姓名”搜索[项]；

 页面列表的“年龄”[列]。

（4）按顺序描述

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

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

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

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

a、在xx接口，增加xx字段，存入数据库xx表。接口逻辑调整为xx。旧数据初始化方案是xx。 

b、在xx页面列表中，新增一列“xx”，对应取值是数据库xx表中的字段xx。

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

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

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

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

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

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

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

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

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

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

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

• 修改前：xxxx；

• 修改后：xxxx；

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

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

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

①数据更新时间为前两天；

 ②退款成功的（refund_status为：2、5、8、12、24任一个）；

 

 ③rma_sn不为空；

 ④order_sn已存在于【发票列表】中。

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

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

（8）穷尽原则

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

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

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

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

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

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

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

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

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

2、通用项进行统一

（1）命名统一

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

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

a、表示删除或禁用的：删除、禁用、关闭、封存；

b、表示启用的：开启、启用、生效；

c、表示设置的：配置、设置；

d、表示编辑的：编辑时间、修改时间、更新时间、操作时间。

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

比如：

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

a、是否已写入：用“is_use”、“is_used”还是“is_write”表示？

 

b、已写入/未写入：用“1/0”，还是用“1/2”表示？

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

（3）页面展示统一

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