最近比较忙，水逆没有动力更新，接上一篇《PRD修炼真经•卷一》。
特别声明：此文目的是解构标准化PRD中各章节的逻辑，并不是PRD的模版。
不用自宫，也能成功。
功能需求
功能需求是PRD核心内容，前面说引言是帮助理解文档本身，概述帮助理解项目和产品本身，那么功能需求部分就是帮助理解业务和功能。下面对功能需求的各部分内容进行详细说明。
概要功能需求
概要功能需求是用于描述提供给用户的产品特性和功能。通常使用框图、表、文字结合的方式说明，便于快速理解。
业务需求
帮助理解产品的业务需求和内容
产品描述：总整体上解释和描述产品定位，产品目标。如，该产品是一款专注于xxx的平台，A业务解决用户xxx的问题，B业务解决运营xxx的问题。
个人认为，PRD中业务需求粒度不宜过细，毕竟PRD是偏向于可量化指标，以指导设计为主。但有的时候，产品MRD、PRD会合并成同一个文档。这种情况下，可以在产品描述中，展开MRD相关内容，如市场分析，用户分析，竞品分析，可行性结论等。
概要功能列表：列出文档涉及的功能列表清单
- 需求编号常见于大型后台系统，便于查找。
- 需求分析可以描述该需求内因，外因，kano等级，紧急程度等，便于快速了解。
- 优先级指导先后顺序，可用与火车头发布模式。
我见过很多需求文档中，优先级设定没有规则。我个人优先级顺序原则是:
- 产品可用性的需求
- 产品用户体验性需求
- 产品扩展性需求
- 产品生态需求
产品结构图
帮助了解产品功能和总体形态的概貌。
全局功能结构：表达这个产品整体的功能层次和逻辑关系，通常用脑图来表达。
页面结构图：以页面为基准，描述产品各页面的层次结构，常用于移动端产品，可用结构图表达。
利用墨刀等原型工具，可以通过创建页面工作流快速完成。
业务流程
帮助理解产品的业务关系和流程。
产品用例图：以不同的用户或角色为基点，通过用例，表达用户会使用的功能边界，常见于后台系统。
示例来源于网络
整体流程图：用于描述某个整体任务时，各模块之间的配合关系，常见于后台系统。
示例来源于网络
全局数据流：用于描述纪录或表单等信息的流转关系或层次结构，常用于后台系统。
示例来源于网络
根据产品类型，选择需要的表达模型去构建PRD。
详细功能需求
这部分大家应该都不陌生，是PRD核心中的核心，用于描述功能的量化指标，是研发部门关注的重点。
对于详细功能，我把它分为两种类型，一种是业务功能，一种是报表功能。根据不同的类型，结构有所不同。
业务功能
功能名称
一般直接使用功能名称作为标题项，便于生成目录和在文档结构图中快速定位。一个story一个小节
概述：
包含功能的一般性描述，包含以下几点内容
需求描述：推荐一个一句话描述需求的模版给大家“xxx（角色）在xxx的情况下，通过xxx的方式，达到xxx的目的”。
业务场景：描述用户的使用场景，可以用拟人化的语言去表达，如：“小王到达A写字楼后，停车场管理员告知车位已满，小王扫扫描车位二维码，寻找附近的空闲停车场。”
参与者：表述此功能具体使用人有哪些，如某功能是管理员使用还是员工使用。
业务流程
详细描述次业务涉及的主要事件流程，可通过流程图辅助说明
- 前置条件：在开始前，系统可检测的有意义的条件。如：意见反馈查询功能中，用户已提交意见反馈
- 触发事件：触发次系统功能的事件。如：用户点击、收到通知
- 基本事件流：常规，正常情况下的预期事件流。如：1、点击xxx进入页面，2、输入xxx，3、选择xxx，4、点击确定保存xxx。可以通过流程图辅助说明。
- 扩展事件流：备选，可选事件流。如：1、可通过点击｛导出｝，进入导出流程。
- 异常事件流：异常情况下事件流。如：空状态下，服务异常时的事件流。
- 后置条件：在结束后，系统可检测的有意义的条件。如：1、保存后，界面数据更新。
相关功能
与本功能相关，但较复杂，难以一起表达时，拆分到细分场景后所关联的功能。可以描述出它们直接的输入输出关系。
界面原型
原型截图或者链接至原型文档。
另外，有必要时，需要说明界面中数据项的详细描述
业务规则
针对此功能或某个数据相的业务规则描述，如果在业务流程中描述过，不需要重复描述。
例如：钱包余额不足时，可转为刷银行卡支付。
设计约束
描述需要设计、开发特别注意的事项。如：没有说明的抽象框架设计；可兼容某些特性；不可用状态时的显示要求。
如果是公共性的约束，可以通过全局说明，来阐述通用约束。如：对话框样式，加载样式等
验收标准
描述产品验收时要满足的内容，是测试人员重点关注事项。
原则上优先保证正常流下的业务结果正确，异常边界不报错，提示明确即可。
如：能够注册成功，失败原因提示正确。
报表功能
功能名称
一般直接使用报表名称作为标题项，便于生成目录和在文档结构图中快速定位。如：某某报表，编写时一个报表一个小节。
概述
因报表一般情况下的用户是管理者，因此报表类功能概述主要便于理解业务场景和管理者意图和目的
- 目的：管理者因为什么需要查看此报表
- 使用部门／职位：用于理解使用者的职责，包括地理级别，如：xx财务经理岗位，省级/市级。
- 相关场景与评率：大概多久查一次，纬度有多大。
报表内容
详细描述报表各项数据的来源和计算规则。
- 数据来源：该数据项的基于哪些数据生成。如：消费金额统计，来源于xx订单纪录
- 计算规则：该数据的统计公式。如：消费金额统计，xx订单中“实收”的累加总额。
界面原型
报表展示原型。个人建议报表原型最好模拟一些真实数据和用户确认最终效果。
报表框架
描述报表模块的通用框架需求，如：打印，打印预览，导出，总计，排序，默认纬度，筛选条件，分页，是否支持动态报表模版等
设计约束、验收标准
与业务功能相同，这里不再重复说明。
数据字典
列出有关功能的数据元素，或信息结构。若原型部分已经描述过，可以省略。
【未完待续】
相关阅读
PRD修炼真经•卷一：一份标准化产品需求文档的逻辑思路
作者：小星星，8年互联网工作经验，4年技术，4年产品。
本文由 @小星星 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
想了解更多移动互联网干货知识，请关注微信公众号运营小咖秀（ID: yunyingshow）
