最近比较忙，水逆没有动力更新，接上一篇《PRD修炼真经•卷一》。

特别声明：此文目的是解构标准化PRD中各章节的逻辑，并不是PRD的模版。

不用自宫，也能成功。

功能需求

功能需求是PRD核心内容，前面说引言是帮助理解文档本身，概述帮助理解项目和产品本身，那么功能需求部分就是帮助理解业务和功能。下面对功能需求的各部分内容进行详细说明。

概要功能需求

概要功能需求是用于描述提供给用户的产品特性和功能。通常使用框图、表、文字结合的方式说明，便于快速理解。

业务需求

帮助理解产品的业务需求和内容

产品描述：总整体上解释和描述产品定位，产品目标。如，该产品是一款专注于xxx的平台，A业务解决用户xxx的问题，B业务解决运营xxx的问题。

个人认为，PRD中业务需求粒度不宜过细，毕竟PRD是偏向于可量化指标，以指导设计为主。但有的时候，产品MRD、PRD会合并成同一个文档。这种情况下，可以在产品描述中，展开MRD相关内容，如市场分析，用户分析，竞品分析，可行性结论等。

概要功能列表：列出文档涉及的功能列表清单

• 需求编号常见于大型后台系统，便于查找。
• 需求分析可以描述该需求内因，外因，kano等级，紧急程度等，便于快速了解。
• 优先级指导先后顺序，可用与火车头发布模式。

我见过很多需求文档中，优先级设定没有规则。我个人优先级顺序原则是:

1. 产品可用性的需求
2. 产品用户体验性需求
3. 产品扩展性需求
4. 产品生态需求

产品结构图

帮助了解产品功能和总体形态的概貌。

全局功能结构：表达这个产品整体的功能层次和逻辑关系，通常用脑图来表达。

页面结构图：以页面为基准，描述产品各页面的层次结构，常用于移动端产品，可用结构图表达。

利用墨刀等原型工具，可以通过创建页面工作流快速完成。

业务流程

帮助理解产品的业务关系和流程。

产品用例图：以不同的用户或角色为基点，通过用例，表达用户会使用的功能边界，常见于后台系统。

示例来源于网络

整体流程图：用于描述某个整体任务时，各模块之间的配合关系，常见于后台系统。

示例来源于网络

全局数据流：用于描述纪录或表单等信息的流转关系或层次结构，常用于后台系统。

示例来源于网络

根据产品类型，选择需要的表达模型去构建PRD。

详细功能需求

这部分大家应该都不陌生，是PRD核心中的核心，用于描述功能的量化指标，是研发部门关注的重点。

对于详细功能，我把它分为两种类型，一种是业务功能，一种是报表功能。根据不同的类型，结构有所不同。

业务功能

功能名称

一般直接使用功能名称作为标题项，便于生成目录和在文档结构图中快速定位。一个story一个小节

概述：

包含功能的一般性描述，包含以下几点内容

需求描述：推荐一个一句话描述需求的模版给大家“xxx（角色）在xxx的情况下，通过xxx的方式，达到xxx的目的”。

业务场景：描述用户的使用场景，可以用拟人化的语言去表达，如：“小王到达A写字楼后，停车场管理员告知车位已满，小王扫扫描车位二维码，寻找附近的空闲停车场。”

参与者：表述此功能具体使用人有哪些，如某功能是管理员使用还是员工使用。

业务流程

详细描述次业务涉及的主要事件流程，可通过流程图辅助说明

• 前置条件：在开始前，系统可检测的有意义的条件。如：意见反馈查询功能中，用户已提交意见反馈
• 触发事件：触发次系统功能的事件。如：用户点击、收到通知
• 基本事件流：常规，正常情况下的预期事件流。如：1、点击xxx进入页面，2、输入xxx，3、选择xxx，4、点击确定保存xxx。可以通过流程图辅助说明。

• 扩展事件流：备选，可选事件流。如：1、可通过点击｛导出｝，进入导出流程。
• 异常事件流：异常情况下事件流。如：空状态下，服务异常时的事件流。
• 后置条件：在结束后，系统可检测的有意义的条件。如：1、保存后，界面数据更新。

相关功能

与本功能相关，但较复杂，难以一起表达时，拆分到细分场景后所关联的功能。可以描述出它们直接的输入输出关系。

界面原型

原型截图或者链接至原型文档。

另外，有必要时，需要说明界面中数据项的详细描述

业务规则

针对此功能或某个数据相的业务规则描述，如果在业务流程中描述过，不需要重复描述。

例如：钱包余额不足时，可转为刷银行卡支付。

设计约束

描述需要设计、开发特别注意的事项。如：没有说明的抽象框架设计；可兼容某些特性；不可用状态时的显示要求。

如果是公共性的约束，可以通过全局说明，来阐述通用约束。如：对话框样式，加载样式等

验收标准

描述产品验收时要满足的内容，是测试人员重点关注事项。

原则上优先保证正常流下的业务结果正确，异常边界不报错，提示明确即可。

如：能够注册成功，失败原因提示正确。

报表功能

功能名称

一般直接使用报表名称作为标题项，便于生成目录和在文档结构图中快速定位。如：某某报表，编写时一个报表一个小节。

概述

因报表一般情况下的用户是管理者，因此报表类功能概述主要便于理解业务场景和管理者意图和目的

• 目的：管理者因为什么需要查看此报表
• 使用部门／职位：用于理解使用者的职责，包括地理级别，如：xx财务经理岗位，省级/市级。
• 相关场景与评率：大概多久查一次，纬度有多大。

报表内容

详细描述报表各项数据的来源和计算规则。

• 数据来源：该数据项的基于哪些数据生成。如：消费金额统计，来源于xx订单纪录
• 计算规则：该数据的统计公式。如：消费金额统计，xx订单中“实收”的累加总额。

界面原型

报表展示原型。个人建议报表原型最好模拟一些真实数据和用户确认最终效果。

报表框架

描述报表模块的通用框架需求，如：打印，打印预览，导出，总计，排序，默认纬度，筛选条件，分页，是否支持动态报表模版等

设计约束、验收标准

与业务功能相同，这里不再重复说明。

数据字典

列出有关功能的数据元素，或信息结构。若原型部分已经描述过，可以省略。

【未完待续】

相关阅读

PRD修炼真经•卷一：一份标准化产品需求文档的逻辑思路

PRD修炼真经•卷二：一份标准化产品需求文档的逻辑思路

PRD修炼真经•卷三：一份标准化产品需求文档的逻辑思路

作者：小星星，8年互联网工作经验，5年技术，3年产品。

本文由 @小星星 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议