原作者：KEVIN.Zhang 来源：PMCAFF 注：有删改
需求概述
在需求概述前关于一些基本设置，我采用以WORD WEB版式，并且字体我一直系统是微软雅黑。
在需求概述中，我首先将一个开文数据框图，表示目前该需求的大体情况，让开发或测试相应人员指导该文档是做什么、文档当前的状态、该需求负责人是谁、修订版本（当前文档的修订版本，并不是产品迭代版本
1.背景概述
目前UGC模块需要优化，提升用户体验。
当前UGC模块功能为：发帖功能、点赞功能、评论功能、转发功能
用户执行发帖流程：发帖入口——输入内容——发帖完成
目前UGC模块功能进行了优化，比如增加了过滤功能，用户可以屏蔽相应的不感兴趣内容，增加了话题功能，用户可以对感兴趣内容进行选取。
将用户发帖流程进行优化，在不阻碍发帖体验的情况下，增加了话题路径，丰富了用户选择性，增加了平台内容多样化
2.需求来源
本次需求来源负责人：KEVIN，部门：产品部
3.关联负责人
部门、负责人、部门领导、备注
4.需求执行成员
部门、人员
5.需求执行周期
执行项目、完成时间
6.更新记录
文档版本、撰写时间、变更人、属性、描述
属性：新增、删除、修改、新建
7.需求结构图
这里主要是设计和技术开发人员了解产品需求的结构，描述顺序为主功能—子功能—子功能详情页。并且这里建议将每个页面超链接后面的页面详情，方便及时相应人员查看。可以链接的地方为功能模块—子功能模块——详情页面，都做可链接。
8.数据间关系
将功能块中设计的用户对象和功能模块流程，将相应的流程涉及的数据关联以流程图的方式展现，当然也可以用脑图，可以方便测试和开发人员指导哪一个数据是哪一个对象的，在哪一些流程中会增加或判别什么数据。
9.全局说明
对于PM来说，一直被认为说所有都要知道，但又不需要所有都精通，但在全局说明中，尤其是在创业团队，并没有UED等专属的部门，产品经理可以把最基础的功能全局和交互全局进行说明。
既然是全局，因此在所有的功能PRD文档中，都需要体现，这里我们以比较常见的交互全局、功能全局
弹层对话、加载、弹层菜单、搜索、导航、表格、按钮、列表、进步器
以上是比较常见的全局控件或功能或交互，在这个功能中会涉及哪些全局的控件或交互，PM需要将相应的全局控件或交互置于文档中，这里在这次UGC模块中，有弹层对话与加载涉及全局，下面是全局的描述。
加载的模块首先分为以下3种：页面加载中、内容加载中、加载结果
页面间交互与页面内交互
页面间交互
首先是对于NATIVE的交互，另外需要注意H5网页的交互默认是不作处理的，因为就是淡入淡出的效果。页面间之间的交互，可以进行自定义，但最终进入那个页面，每个页面哪些地方可以进入，可以退出等，PM或交互设计师需要进行说明。
页面内交互
10.功清单能
在对于UGC模块中，我将相应的子功能进行罗列，那么这里我们需要以用表格的方式进行统计，方便设计、开发人员以及测试人员对工作量的评估。
产品、模块、子模块、描述
11.业务流程
这里的业务流程，我们默认是以用户开始，依照用户的操作，将其流程分为前端和服务端，告知相应端开发人员应该做什么、不应该做什么。
当然这里移动端流程指向的用户相对单一，当然也有按照用户角色来进行区分的流程，常见的就是在ERP或者一些后台产品设计中，PM需要根据不同的角色将相应流程进行绘制。
用户、前端、服务端
12.需求/功能描述
到这里就是PRD主要的篇幅部分，在这里我建议将功能的每个页面进行列举。每个功能的描述，我们既然按照功能点进行分类，将不同的子功能分别列举。接下来在文档中我们需要展现的是三部分内容：
（1）页面需求描述
说明该页面是干什么的？并且该页面出现的地方，在什么时间出现，需要有什么条件要求
（2）交互手势
上面所说的交互手势在这里就可以列举出来了，当前页面能做什么交互手势？哪些手势不能做？
（3）用例描述
描述点击相应控件或位置，页面后进入到哪一个页面，以什么方式（滑动？弹出？）
这里以开红包方式来描述
用例1： 点击开，页面左滑进入红包首页 用例结束
（4）异常情况
这里的异常情况或许很多PM朋友都没有写进去，说实话，今天以前我也没有写。但和产品朋友交流后我发现，其实异常情况的知晓能够反映出作为PM你目前的经验丰富情况，到底该页面下那些异常会出现，你是否能预知？
13.数据统计需求
以上我们的PRD差不多完成了70%，接下来就是为了后期验证跟进做的一些辅助性跟进，那就是对于数据的统计需求。数据统计的需求我们也需要在文档中进行撰写，当然如果有专门的数据部门，我建议PM可以交给数据部门完成，PM将其需求过渡给数据部门。
数据提交模块：模块、页面名称、页面分级、需记录数据
页面点击数据模块：所在页面、事件名称、事件ID、版本、自定义事件标签、自定义时间参数、分类
这一点必须说明的是关于自定义事件LABEL和自定义事件参数，（图中时间改为事件），由开发人员来定就行了。当然如果你是开发转型的PM，你可以来决定，但为了后期的数据参数统计和分类，建议还是直接交给开发人员
14.其他需求描述
综上，基本一个PRD文档就算完成了，但在工作中一个功能模块或一个版本的迭代往往还需要涉及其他需求，涉及人力、财务资源的需求，以及对于每次评审或小团队沟通的记录。这里我也一并同步出来自己在工作中做的一些需求描述，也可以集中放置于项目文档或该PRD文档中。
性能需求，服务需求，营销需求，安全需求，法务需求，帮助需求，异常场景，沟通记录，风险描述
（1）性能需求
模块、发生场景、成功率、响应时间、并发数、其他
性能需求可以以表格的形式对相应的功能模块进行要求，如红包点击弹出的时间在3S内，成功率是99%，并发数是20000。
（2）服务需求
预计服务事件、预计服务频率、场景描述、服务解决方案、预计需要协助人、成本
这个涉及到产品客服，产品人员需要知道要占用客服时间、相应问题解决的方案是什么？每个问题的优先级是什么？产品需要从客服人员中得到什么信息？这个需要PM对当前产品数据分析，才能更好的对接资源，总不能要求其他部门把全部资源用在你手上吧。
（3）营销需求
营销需求和上方的服务需求同样，也是需要产品经理进行数据分析，为达到目标计划一个预计营销需求，当然其营销的平台与方式可以和营销部进行策划沟通
（4）法务需求
预计服务事件、预计服务频率、场景描述、服务解决方案、预计需要协助人、成本
（5）财务需求
同法务需求一样
（6）帮助需求
帮助需求可以解释为FAQ培训，将产品上线后对于该项目涉及人员和部门进行培训，建立相应的FAQ，并且对于活动类模块也需要运营提供活动FAQ。
（7）项目风险
预计风险事件、风险来源、关联责任部门、解决方案
如果是功能模块迭代可以说明为版本风险，但是对于产品的迭代中，其需要明确新增、取缔的风险，将其可能存在的风险隐患进行描述
