当然值得注意的是可能一个模块下有子功能，子功能下面还有子功能，这个时候建议方便文档查看，就以2个层级进行区分，在后方描述的时候进行说明。

七、业务流程

这里的业务流程，我们默认是以用户开始，依照用户的操作，将其流程分为前端和服务端，告知相应端开发人员应该做什么、不应该做什么。

当然这里移动端流程指向的用户相对单一，当然也有按照用户角色来进行区分的流程，常见的就是在ERP或者一些后台产品设计中，PM需要根据不同的角色将相应流程进行绘制。

另一个流程图比较常见就是上面说的根据默认以用户流程，将前端与服务端的流程涉及

PRD需求文档，在创业团队中可能处于一个空置的情况下，为什么这么说？因为你写出来没人看，只能作为一个留底

但在一些成熟性公司中，那么PRD文档不仅仅起着留底的作用，将产品逻辑和用户使用逻辑描述得清楚，将方便开发人员以及测试人员知道如何去进行开发和验收，涉及到数据交互的都应该在服务端与

但值得注意的是流程图千万要清晰、明了，不要弯弯曲曲，混成一团。

八、需求/功能描述

到这里就是PRD主要的篇幅部分，在这里我建议将功能的每个页面进行列举，比如某一个功能

每个功能的描述，我们既然按照功能点进行分类，将不同的子功能分别列举。接下来在文档中我们需要展现的是三部分内容：

1.页面需求描述

说明该页面是干什么的？并且该页面出现的地方，在什么时间出现，需要有什么条件要求

2.交互手势

上面所说的交互手势在这里就可以列举出来了，当前页面能做什么交互手势？哪些手势不能做？

该页面如果只有点击手势，那么即在手势下面写有，并且描述在IOS与安卓那个版本下有，如果没有是否需要开发

3.用例描述

描述点击相应控件或位置，页面后进入到哪一个页面，以什么方式（滑动？弹出？）

这里以开红包方式来描述

用例1：点击开，页面左滑进入红包首页 用例结束

4.异常情况

这里的异常情况或许很多PM朋友都没有写进去，说实话，今天以前我也没有写。但和产品朋友交流后我发现，其实异常情况的知晓能够反映出作为PM你目前的经验丰富情况，到底该页面下那些异常会出现，你是否能预知？

大多数PM或许会将该异常情况统一交给测试来处理，因此为了百分百保证这一份分享是最完整的PRD干货，今天就把这个加上了。

用例1：用户未登录，点击红包开，页面左滑进入红包首页 用例结束

九、数据统计需求

以上我们的PRD差不多完成了70%，接下来就是为了后期验证跟进做的一些辅助性跟进，那就是对于数据的统计需求。数据统计的需求我们也需要在文档中进行撰写，当然如果有专门的数据部门，我建议PM可以交给数据部门完成，PM将其需求过渡给数据部门。

当然不懂数据的PM肯定不是好PM，为此能够了解产品哪些地方有数据统计，我还是把相应的数据要求提交在文档中。

这一点必须说明的是关于自定义事件LABEL和自定义事件参数，（图中时间改为事件），由开发人员来定就行了。当然如果你是开发转型的PM，你可以来决定，但为了后期的数据参数统计和分类，建议还是直接交给开发人员

这里可以简单举例比如以UGC模块，以发帖事件来进行说明，atv，该页面所能进行的操作都需要将其规则化，以事件名称来确定每个操作的名称，可以满足将其规则化的目的。

十、其他需求描述