本文总结了一个最基本的话题：PRD。内容如下：1. PRD的形式 2. PRD的规范 3. PRD的自检方法

1. PRD 的形式

1. 原型附带文本

对于移动端产品来说，首要当然是展示产品DEMO。

附带的文字主要是对原型的交互、值获取逻辑等的描述。

例如：

如果文本很多，您可以简单地布局原型的正确部分。

例如：

2. 文本自带原型

对于过于逻辑化的后端要求，只需使用Word//TXT格式的PRD。

好处是可以重新理清思路，在写作过程中暴露问题。

此类要求文件一般包括：

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

（1）需求背景

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

（2）需求目标

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

例如：

a.用户点击后3秒内页面必须加载完成。 b.用户可以看到自己已经购买的商品。 c.用户可以删除自己的购买记录。

（3）需求范围

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

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

功能框架图可用于确定需求范围。

需求用例

需求用例是需求的主体。

首先，将需求分解为任务点并进行描述。

描述语句必须严格遵循文档语法原则（将在下面讨论）。

如下图所示：

（5）参考文献

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

2. PRD 规格

这里我们主要关注Word风格的PRD。

1. 需求文档的语法

（1）解经文字中的每一个字都价值千金

需求文档就像说明书，只是少了形容词、隐喻、副词等等。

如果能用一句话解释清楚，就不要说第二句话。

（3）避免使用不恰当的词语

在文档或口头交流中，经常使用“维度”、“粒度”、“参数”、“字段”、“项”、“列”、“表”等词语。

在产品需求文档中，措辞必须严谨，避免出现歧义或不准确性。

常见用法示例：

使用“订单号+商品码”这个【维度】做唯一判断；按照“订单”这个【粒度】进行聚合；使用“时间”作为请求【参数】；数据库的【字段】为“”；分页搜索栏中“姓名”这个【项目】；分页列表中“年龄”这个【列】。

（4）按顺序描述

开发人员和测试人员通常希望先完成一个模块的工作，然后再转到下一个模块，而不是来回跳转。

因此书写顺序应遵循先、后、左、右、大等常规顺序，写完一个模块再写下一个。

不要重复之前写过的内容，以避免产生歧义。

比如你想在现有的界面上增加一个字段并显示在页面上，可以分两步描述：

a.在xx界面增加xx字段，存入数据库xx表，界面逻辑调整为xx，原数据初始化方案为xx。b.在xx页面列表增加新列“xx”，对应值为数据库xx表中的字段xx。

（5）关注“在哪里和什么”

文件以任务线为核心句型，即：“去哪儿，做什么”。

尝试使用正向词序，避免反向词序，并且不要使用括号或破折号。

例如，避免在描述后面加上“也就是说”。

（6）不要在文档中包含不需要的功能

产品经理是信息的传播者和信息中心。

开发人员和测试人员希望以所见即所得的方式阅读，因此不应添加不必要的任务。

比如，不要使用“也许我们这次会做”或“请注意，这次不会这样做，只是提前通知”这样的内容。

正文必须传达“做什么”。如果你想添加一些内容，就把它放在参考部分。

（7）使用适当的写作结构

1）如果需要对旧函数进行优化，可以使用比较结构来描述，例如：

2）对于有很多并行条件的条件，可以使用并行枚举结构来描述，例如：

每日一次，定期监控【退款单】（表格），若同时满足以下条件：

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

①数据于两天前更新过；②退款成功（2、5、8、12、24中的任意一天）；③不为空；④已存在于[发票清单]中。

注意：如果对数据库不熟悉，建议不要写数据库移动端下拉框关键词移动端下拉框关键词，而是把页面值位置写清楚，并提供截图，以免让事情变得更糟。

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

（8）详尽原则

“穷尽”是严谨计划的基础。

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

比如：在制作一个新页面的时候，需要从导航栏、界面交互、搜索功能、网站介绍文字、默认列表显示内容、列表数据统计等进行全方位的讲解。

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

（9）最后，不要忘记性能要求、是否处理历史数据以及权限要求。

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

例如：预计半年内每天数据量100万，要求接口在3秒内响应。

历史数据是否需要初始化，以及发布的时间顺序。

权限是授予页面数据和功能的权限。

2. 统一常用物品

（1）统一命名

页面上的一些常用插件可能会有多个版本，产品经理需要在一开始写需求文档的时候就确定使用哪一个。

例如，下面几组插件名称具有类似的含义：

a.表示删除或禁用：删除、禁用、关闭、存档；b.表示启用：打开、启用、生效；c.表示设置：配置、设置；d.表示编辑：编辑时间、修改时间、更新时间、操作时间。

（2）统一数据库表公共字段的命名（开发人员负责）

例如：

每个开发人员都有不同的习惯，因此你需要坚持一个习惯，以避免必须使用不同的习惯。

a. 是否已写：应以“ ”、“ ”还是“ ”表示？b. 是否已写/未写：应以“1/0”还是“1/2”表示？

笔者曾经遇到过一个开发人员抄袭别人，把“ ”(产品代码)写成“ ”，遭到了笑话。

（3）统一页面展示

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

（4）统一文档命名

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

（5）统一术语定义

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

3. 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）多读书小红书搜索下拉词★人人都能霸屏下拉64xl.com，下拉词软件平台，多站在别人的角度思考，试着去理解别人是否能够理解，把问题停留在自我反省阶段。

3）让同事（包括产品经理，程序员，测试员等）互相帮助审阅各自的文档，并接受彼此的建议。

4）文档是需要修改的，所以写完之后，先放一边，等一会儿再去查看、修改。

-超过-

作者的公众号有很多产品信息，推荐大家关注：