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

　　最近比较忙，水逆没有动力更新，接上一篇《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修炼真经•卷一：一份标准化产品需求文档的逻辑思路
　　PRD修炼真经•卷二：一份标准化产品需求文档的逻辑思路
　　PRD修炼真经•卷三：一份标准化产品需求文档的逻辑思路