整理产品结构

分析核心业务流程

每个产品，都会有几个核心的业务，分析并梳理出几个核心业务流程，可以帮助产品经理了解产品逻辑。笔者做的是B端产品，核心业务流程一般都会涉及到多个角色，而C端产品，核心流程的用户则比较单一。涉及到多个角色的业务流程，可以使用泳道图，单个角色可以使用普通的活动图。另外，在分析业务流程的时候，还可以配合使用状态图和顺序图，具体使用什么工具，视情况而定，重点是梳理清楚逻辑

分析及整理用例

在描述需求时，有2种方式，一种是用例描述，另外一种是功能点描述。用例描述和功能点描述最大的区别在于，描述的角度不一样，用例是从人和系统的旁观者来描述，而功能点是从产品的角度来描述。通过用例描述需求，最好用文档，并且有统一的用例模板，而功能描述只需要在Axure里，以注释的方式描述即可。

其实，关于需求怎么描述，没有完全正确的方式，只有最合适的方式，具体因人而异。《启示录》一书作者就建议描述产品需求只需要高保真原型+注释就可以，完全不需要文档。
数据规则。主要指页面从数据库调取数据并展现的规则，比如查看文章列表这个用例，需要描述文章列表页面展示哪些字段、每个字段的类型及长度、列表的排序规则刷新频率等。
状态逻辑。文章不同状态之间切换的触发点是什么，比如状态为已发布的文章，要变为下架，可能的触发条件有：发布时间已过期、手动操作下架等。
交互规则。界面上存在交互的元素，一一列举并说明，比如链接、按钮、滑动、下拉的具体交互规则及异常处理。另外，整个场景由于网络问题、系统问题导致的异常也需要说明。

分析及整理非功能性需求

非功能需求涉及比较广，比如产品的性能需求，访问速度达到多少、最大能支持多少人同时访问；比如设计需求，产品要设计成小清新风格还是成熟稳重的风格等；还比如统计需求，产品要统计哪些字段，形成哪些报表等。这个可以根据具体的需求来描述。

整理需求文档并评审

文档的组成部分

1. 修订记录

记录每次文档更新的时间、作者、修订内容，便于追溯历史变动；

2. 全局说明

包括名词解释、统一异常处理、列表默认数据规则等。

名词解释：每个行业都有专业术语，可以提前将晦涩难懂的术语提前做好解释，便于达成共识，更好沟通；
统一异常处理：网络异常、后台服务异常的交互逻辑；
列表默认数据规则：默认列表的排序方式，默认显示条数，超过多少条翻页，缺省值展现方式；
所有涉及全局的描述，都可以罗列在这里。

3. 项目背景

每个产品，都有一套价值模型。以信贷产品为例，针对用户的价值指标有放款额、审批时长、是否上征信等；针对后台业务人员，有审批时效、通过率、放款率、坏账率等指标；针对老板，有投资回报比、员工成本、净利润等价值指标，每一个需求，应该都是围绕某个价值指标展开。

背景从现状、方案、目标3方面描述。

现状：描述当前需求方遇到的问题，最好能跟价值模型关联；
方案：针对这个问题，所提供的解决方案概述；
目标：期望获得多少价值指标提升；
通过项目背景的描述，可以让项目参与者感受到自己的工作价值。

4. 项目范围

项目范围对应搭框架部分，将功能结构图在此处罗列；

5. 业务流程

业务流程对应定流程部分，将核心业务流程、子系统业务流程在此处罗列；

6. 功能需求

这个部分在PRD中占比最大，搭框架部分，已经将产品功能点全部梳理出来了，这部分就是对功能点进行逐一描述。

功能是从系统的角度来看，我们还要考虑用户角度，所有我们采用用户+功能的方式来描述需求，这就是用例。完整用例名称一定是动宾结构，如添加文章、删除文章、修改文章、查看文章列表。

一个完整的用例包含：

描述（非必须）
前置条件
后置条件
界面交互
业务流程
异常和分支流程
数据字典（非必须）

1）描述

功能的简要描述。

2）前置条件

要操作此功能，需要具备什么角色、权限或状态。

3）后置条件

执行完这个用例后，关联的数据会有什么变化，页面怎么跳转。

4）界面

每个界面都可以拆分成多个元素，如表单、文本、链接、图片等；

表单的每个元素要描述是否可为空、是否有初始内容、是否默认选中、是否有字数限制等，还有对应的错误提示；

文本要考虑最大显示长度，超过怎么处理；

链接一定要指定点击后跳转到哪个页面；

图片要考虑显示的比例，如果未加载出来该显示什么；

还要考虑界面的内容是写死还是通过后台配置；
界面元素：

5）业务流程

当用户完成输入并提交时，后端应该做什么校验，不同输入该怎么处理，不同结果该返回什么值，最好通过业务流程图+文字来描述，确保逻辑完整。

6）异常和分支流程

异常流程如网络错误、接口返回异常、服务器内部错误等；

以登录为例，分支流程包括找回密码、密码登录等，分支流程非必须，简单的分支流程可以直接通过主流程体现，具体可以视情况按照一定颗粒度进行拆分。

7）数据字典

这个用例涉及哪些数据，可以通过数据字典描述，这一步非必须，最终表结构也不一定就是这样，只是给开发一个参考。有技术背景的产品，也可以做得更细
产品经理一定要懂基本的数据库知识，程序=数据结构+算法。用户使用产品时，本质上是在和数据进行交互，只是在用户和数据之间，加了一些列算法。

7. 非功能需求

数据需求。常见的就是数据埋点，产品经理需要梳理出埋点事件表，告知开发，让开发在编码过程中进行埋点。

监控需求。需要监控某个接口或某些服务，当出现异常时，可以发送报警信息至相关人员。

PRD常用模板