很可惜 T 。T 您现在还不是作者身份，不能自主发稿哦～
如有投稿需求，请把文章发送到邮箱tougao@appcpx.com，一经录用会有专人和您联系
咨询如何成为春羽作者请联系：鸟哥笔记小羽毛（ngbjxym）
输出的文档内容包含了需求文档、MRD等等，而需求文档的撰写标准，各家公司都有自己的规范。
所以一个产品经理随着工作时间久了，在不同的公司工作，也会积累不同的标准。对于没有标准或规范的团队或个人来说，找到一个好用的需求文档模版，也可以提升效率。
下面这份模板时间过去了6年，但仍然是一个非常好用的模板。毕竟需求文档不能做的很细，会导致下游产品设计、开发阅读效率降低，反而不能够理解需求。
我做产品经理工作累计8年了，也积累了”标准“的PRD文档。
需求前我会将文档设置为web版式，字体使用微软雅黑，标题分级用默认等级，方便进行浏览和阅读。
而如果你选择使用在线文档，那么就不用设置。
需求文档的第一部分：需求概述
在需求概述中，我首先会使用一个表格来罗列当前需求是什么、需求的版本、以及需求的完成日期和需求的状态。
用于简单陈述当前的需求状况，让阅读者知道该文档是做什么、文档当前的状态、该需求负责人是谁、修订版本（当前文档的修订版本，并不是产品迭代版本
背景概述是说明需求出现的背景是什么，是基于什么原因想完成什么。比如下面是社区论坛UGC功能模块需求。
本次需求来源负责人：Kevin，部门：产品部
需求执行成员给出了具体的项目各个联系人。这一点要说明的是，如果团队没有以上职位，可以将做这个项目的人员拉进来。可能PM会做UI、UE，类似这样的情况，也需要填表。
当然敏捷开发的创业团队，可能会当面沟通，文档中存在执行成员与否反而不重要，本来人就少，大家都心知肚明啦。
每个公司的研发流程有一些区别，比如上面是适用于在产品研发人员在20人以内的团队，有2次评审。
需求评审周期和UI评审的周期是反复、漫长的，并不是将每一次的评审开会时间填上去，而是将相应周期。
如：目前评审处于需求评审，UI还没做，那么就属于开发需求评审。
这一块是我认为需求文档中，最为重要的一块。
文档更新可能是很简单的一句话，但却是开发与测试人员每次最关注的就是你的更新记录，他可不想每次都去查找那一小部分更新内容。
这个更新记录可以在需求评审后，也可以是开发中更新，毕竟有一些需求是开会中不会遇见的，只有在正在开发中才会发现不合理。
这里值得注意的是首先分为4个属性
·新增
·删除
·修改
·新建
新建默认为相应模块的首次使用，后期对于文档的修改用新增、删除、修改即可，并且这里需要将修改、新增的地方加入超链接，方便开发进行查阅。
这里介绍了产品需求的全体结构，描述顺序为主功能—子功能—子功能详情页
并且这里建议将每个页面超链接指向需求文档后面的功能详情，方便相应人员查看。
链接的方式为功能模块—子功能模块——详情页面，都做可链接。
当然这样式比较费时间的，通吃我是只有梳理结构图，没有做链接形式。
通过以用户的方式来模拟功能模块流程，将流程涉及的数据关联以流程图展现，当然也可以用脑图，可以方便测试和开发人员指导哪一个数据是哪一个对象的，在哪一些流程中会增加或判别什么数据。
TIPS：
这一点对于大功能模块来说比较常用，但一些小的功能模块，这一块可以不梳理，比如很常见的一个广告BANNER等小功能模块，想用的数据关系可以不用展示，与开发直接沟通好就行。
全局说明指的是在多个功能、页面会存在的相同交互或逻辑，这里分类分为3个类，如下图
全局说明中，产品经理可以把最基础的功能全局和交互全局进行说明。在所有的功能PRD文档中，都需要体现，这里我们列举了比较常见的交互全局、功能全局
·弹层对话
·加载
·弹层菜单
·搜索
·导航
·表格
·按钮
·列表
·进步器
在这个功能中会涉及哪些全局的控件或交互，PM需要将相应的全局控件或交互置于文档中，这里在这次UGC模块中，有弹层对话与加载涉及全局，下面是全局的描述。
加载的模块首先分为以下3种：页面加载中、内容加载中、加载结果
1.页面加载中
2.内容加载（下拉、松开）
3.页面加载网络正常却没数据
4.页面加载网络异常
5.页面加载搜索没有结果
全局交互的2种表达形式
1.页面间交互
产品经理通过全局交互定义页面间之间的交互，每个页面哪些地方可以进入，可以退出等。以下我分为单张和多张图示进行展示，页面间交互应该如何说明
2.页面内交互
、
以上为移动端内的页面内交互，当然还有长安、双击等交互，目前以上列举的是比较常见的一些手势
在对于UGC模块中，我将相应的子功能进行罗列，方便设计、开发人员以及测试人员对工作量的评估。
当然值得注意的是可能一个模块下有子功能，子功能下面还有子功能，这个时候建议方便文档查看，就以2个层级进行区分，在后方描述的时候进行说明。
是以用户开始，依照用户的操作，将其流程分为前端和服务端2类流程，告知相应端开发人员应该做什么、不应该做什么。
前端是指具体在系统里，PM需要根据不同的角色将相应流程进行绘制。
另一个流程图就是后端服务流程，根据默认的用户流程，将系统APP、后台之间的信息交互进行记录，有时候我们会用时序图进行记录。
PRD文档中的流程图，将产品逻辑和用户使用逻辑描述得清楚，将方便开发人员以及测试人员知道如何去进行开发和验收，涉及到数据交互的都应该在服务端与
值得注意的是流程图千万要清晰、明了，不要弯弯曲曲，混成一团。在与产品朋友们交流中
到这里就是PRD主要的内容部分，我建议将功能的每个页面进行列举，比如某一个功能
【每个页面进行列举】
每个功能的描述，按照功能点进行拆解，以此罗列子功能。接下来在文档中我们需要展现的是三部分内容：
1.页面需求描述
说明该页面是干什么的？并且该页面出现的地方，在什么时间出现，需要有什么条件要求
2.交互手势
上面所说的交互手势在这里就可以列举出来了，当前页面能做什么交互手势？哪些手势不能做？
该页面如果只有点击手势，那么即在手势下面写有，并且描述在IOS与安卓那个版本下有，如果没有是否需要开发
3.用例描述
描述点击相应控件或位置，页面后进入到哪一个页面，以什么方式（滑动？弹出？）
这里以APP里开红包方式来描述
用例1： 点击开，页面左滑进入红包首页 用例结束
4.异常情况
异常情况的知晓能够反映出作为PM的经验丰富情况，到底该页面下那些异常会出现，你是否能预知？
PM或许会将该异常情况统一交给测试来处理。
异常情况：用户未登录，点击红包开，页面左滑进入红包首页 用例结束
以上的部分，可以将PRD差不多完成了70%，接下来就是为了后期验证做一些辅助性需求，让需求更加完整。
数据统计的需求我们也需要在文档中进行填写，当然如果有专门的数据部门，我建议PM可以交给数据部门完成，PM将其需求过渡给数据部门。
当然不懂数据的PM肯定不是好PM，为此能够了解产品哪些地方有数据统计，我还是把相应的数据要求提交在文档中。
关于自定义事件LABEL和自定义事件参数，（图中时间改为事件），由开发人员来定就行了。当然如果你是开发转型的PM，你可以来决定，为了后期的数据参数统计和分类，建议还是直接交给开发人员
比如以UGC模块，以发帖事件来进行说明，该页面所能进行的操作都需要将其规则化，以事件名称来确定每个操作的名称，可以满足将其规则化的目的。
综上，基本一个PRD文档就算完成了，但在工作中一个功能模块或一个版本的迭代往往还需要涉及其他需求，涉及人力、财务资源的需求，以及对于每次评审或小团队沟通的记录。这里我也一并同步出来自己在工作中做的一些需求描述，也可以集中放置于项目文档或该PRD文档中。
·性能需求
·服务需求
·营销需求
·安全需求
·法务需求
·帮助需求
·异常场景
·沟通记录
·风险描述
1.性能需求
性能需求可以以表格的形式对相应的功能模块进行要求，如红包点击弹出的时间在3S内，成功率是99%，并发数是20000。
【性能需求】
2.服务需求
这个涉及到产品客服，产品人员需要知道要占用客服时间、相应问题解决的方案是什么？每个问题的优先级是什么？产品需要从客服人员中得到什么信息？这个需要PM对当前产品数据分析，才能更好的对接资源，总不能要求其他部门把全部资源用在你手上吧。
【服务需求】
这里首先要说明的是关于成本建议做一个标准，如果是按照价钱就统一为钱；如果为时间就统一为时间；预知服务频率需要PM进行数据分析，给予一个恰当的范围。
3.营销需求
营销需求和上方的服务需求同样，也是需要产品经理进行数据分析，为达到目标计划一个预计营销需求，当然其营销的平台与方式可以和营销部进行策划沟通。
4.法务需求
【人力需求】
法务需求与以上2点需求类似，建议可以合成为一张表格，将分别的需求资源供应方分类，这样可以更快的在一张表中了解该项目的资源消耗情况。
5.财务需求
同法务需求一样
6.帮助需求
帮助需求可以解释为FAQ培训，将产品上线后对于该项目涉及人员和部门进行培训，建立相应的FAQ，并且对于活动类模块也需要运营提供活动FAQ。
7.项目风险
如果是功能模块迭代可以说明为版本风险，但是对于产品的迭代中，其需要明确新增、取缔的风险，将其可能存在的风险隐患进行描述
8.评审中的沟通会议记录
可以参考下面的会议模板作为需求评审记录
这样有了会议沟通记录之后，相信产品人能够减少一些坑或者识别一些坑，避免一些人冤枉PM说：领这是你之前说的！XX这是你说的！
本文为作者独立观点，不代表鸟哥笔记立场，未经允许不得转载。
《鸟哥笔记版权及免责申明》 如对文章、图片、字体等版权有疑问，请点击 反馈举报
Powered by QINGMOB PTE. LTD. © 2010-2022 上海青墨信息科技有限公司 沪ICP备2021034055号-6
我们致力于提供一个高质量内容的交流平台。为落实国家互联网信息办公室“依法管网、依法办网、依法上网”的要求，为完善跟帖评论自律管理，为了保护用户创造的内容、维护开放、真实、专业的平台氛围，我们团队将依据本公约中的条款对注册用户和发布在本平台的内容进行管理。平台鼓励用户创作、发布优质内容，同时也将采取必要措施管理违法、侵权或有其他不良影响的网络信息。
一、根据《网络信息内容生态治理规定》《中华人民共和国未成年人保护法》等法律法规，对以下违法、不良信息或存在危害的行为进行处理。
1. 违反法律法规的信息，主要表现为：
1)反对宪法所确定的基本原则；
2)危害国家安全，泄露国家秘密，颠覆国家政权，破坏国家统一，损害国家荣誉和利益；
3)侮辱、滥用英烈形象，歪曲、丑化、亵渎、否定英雄烈士事迹和精神，以侮辱、诽谤或者其他方式侵害英雄烈士的姓名、肖像、名誉、荣誉；
4)宣扬恐怖主义、极端主义或者煽动实施恐怖活动、极端主义活动；
5)煽动民族仇恨、民族歧视，破坏民族团结；
6)破坏国家宗教政策，宣扬邪教和封建迷信；
7)散布谣言，扰乱社会秩序，破坏社会稳定；
8)宣扬淫秽、色情、赌博、暴力、凶杀、恐怖或者教唆犯罪；
9)煽动非法集会、结社、游行、示威、聚众扰乱社会秩序；
10)侮辱或者诽谤他人，侵害他人名誉、隐私和其他合法权益；
11)通过网络以文字、图片、音视频等形式，对未成年人实施侮辱、诽谤、威胁或者恶意损害未成年人形象进行网络欺凌的；
12)危害未成年人身心健康的；
13)含有法律、行政法规禁止的其他内容；
2. 不友善：不尊重用户及其所贡献内容的信息或行为。主要表现为：
1)轻蔑：贬低、轻视他人及其劳动成果；
2)诽谤：捏造、散布虚假事实，损害他人名誉；
3)嘲讽：以比喻、夸张、侮辱性的手法对他人或其行为进行揭露或描述，以此来激怒他人；
4)挑衅：以不友好的方式激怒他人，意图使对方对自己的言论作出回应，蓄意制造事端；
5)羞辱：贬低他人的能力、行为、生理或身份特征，让对方难堪；
6)谩骂：以不文明的语言对他人进行负面评价；
7)歧视：煽动人群歧视、地域歧视等，针对他人的民族、种族、宗教、性取向、性别、年龄、地域、生理特征等身份或者归类的攻击；
8)威胁：许诺以不良的后果来迫使他人服从自己的意志；
3. 发布垃圾广告信息：以推广曝光为目的，发布影响用户体验、扰乱本网站秩序的内容，或进行相关行为。主要表现为：
1)多次发布包含售卖产品、提供服务、宣传推广内容的垃圾广告。包括但不限于以下几种形式：
2)单个帐号多次发布包含垃圾广告的内容；
3)多个广告帐号互相配合发布、传播包含垃圾广告的内容；
4)多次发布包含欺骗性外链的内容，如未注明的淘宝客链接、跳转网站等，诱骗用户点击链接
5)发布大量包含推广链接、产品、品牌等内容获取搜索引擎中的不正当曝光；
6)购买或出售帐号之间虚假地互动，发布干扰网站秩序的推广内容及相关交易。
7)发布包含欺骗性的恶意营销内容，如通过伪造经历、冒充他人等方式进行恶意营销；
8)使用特殊符号、图片等方式规避垃圾广告内容审核的广告内容。
4. 色情低俗信息，主要表现为：
1)包含自己或他人性经验的细节描述或露骨的感受描述；
2)涉及色情段子、两性笑话的低俗内容；
3)配图、头图中包含庸俗或挑逗性图片的内容；
4)带有性暗示、性挑逗等易使人产生性联想；
5)展现血腥、惊悚、残忍等致人身心不适；
6)炒作绯闻、丑闻、劣迹等；
7)宣扬低俗、庸俗、媚俗内容。
5. 不实信息，主要表现为：
1)可能存在事实性错误或者造谣等内容；
2)存在事实夸大、伪造虚假经历等误导他人的内容；
3)伪造身份、冒充他人，通过头像、用户名等个人信息暗示自己具有特定身份，或与特定机构或个人存在关联。
6. 传播封建迷信，主要表现为：
1)找人算命、测字、占卜、解梦、化解厄运、使用迷信方式治病；
2)求推荐算命看相大师；
3)针对具体风水等问题进行求助或咨询；
4)问自己或他人的八字、六爻、星盘、手相、面相、五行缺失，包括通过占卜方法问婚姻、前程、运势，东西宠物丢了能不能找回、取名改名等；
7. 文章标题党，主要表现为：
1)以各种夸张、猎奇、不合常理的表现手法等行为来诱导用户；
2)内容与标题之间存在严重不实或者原意扭曲；
3)使用夸张标题，内容与标题严重不符的。
8.「饭圈」乱象行为，主要表现为：
1)诱导未成年人应援集资、高额消费、投票打榜
2)粉丝互撕谩骂、拉踩引战、造谣攻击、人肉搜索、侵犯隐私
3)鼓动「饭圈」粉丝攀比炫富、奢靡享乐等行为
4)以号召粉丝、雇用网络水军、「养号」形式刷量控评等行为
5)通过「蹭热点」、制造话题等形式干扰舆论，影响传播秩序
9. 其他危害行为或内容，主要表现为：
1)可能引发未成年人模仿不安全行为和违反社会公德行为、诱导未成年人不良嗜好影响未成年人身心健康的；
2)不当评述自然灾害、重大事故等灾难的；
3)美化、粉饰侵略战争行为的；
4)法律、行政法规禁止，或可能对网络生态造成不良影响的其他内容。
二、违规处罚
本网站通过主动发现和接受用户举报两种方式收集违规行为信息。所有有意的降低内容质量、伤害平台氛围及欺凌未成年人或危害未成年人身心健康的行为都是不能容忍的。
当一个用户发布违规内容时，本网站将依据相关用户违规情节严重程度，对帐号进行禁言 1 天、7 天、15 天直至永久禁言或封停账号的处罚。当涉及欺凌未成年人、危害未成年人身心健康、通过作弊手段注册、使用帐号，或者滥用多个帐号发布违规内容时，本网站将加重处罚。
三、申诉
随着平台管理经验的不断丰富，本网站出于维护本网站氛围和秩序的目的，将不断完善本公约。
如果本网站用户对本网站基于本公约规定做出的处理有异议，可以通过「建议反馈」功能向本网站进行反馈。
(规则的最终解释权归属本网站所有)