PRD文档功能整理小馒头帮.docx
《PRD文档功能整理小馒头帮.docx》由会员分享，可在线阅读，更多相关《PRD文档功能整理小馒头帮.docx（15页珍藏版）》请在冰豆网上搜索。
PRD文档功能整理小馒头帮
PRD文档书写的知识点
序号
主题
讨论点
说明
1
需求规格说明书
定义：
面对人群，解决什么问题
2
几种写PRD的形式
3
版本号
4
修订历史
功能迭代版本说明
5
产品架构图
6
业务流程图
7
功能列表
8
数据模型设计
实体设计：
属性和操作
9
关系设计
10
功能优先级
目的
11
标准
12
注意事项
13
交互设计
页面
14
视觉设计
页面
15
术语表
16
功能性需求
定义
17
用例
定义
18
规则
19
非功能性需求
定义：
为实现功能性需求，而必须做到的基本条件。
或者说只有在非功能性需求满足的情况下，功能性需求才是有效的。
20
1、量化的指标——时实性、稳定性、吞吐量、性能指标等
21
2、兼容性要求
22
3、可维护性要求
23
4、安全性要求
24
5、界面要求
25
6、明确的时间进度约束
26
7、其它明确的要求（例如：
安装包）…更多非功能需求？
？
27
全局规范与说明
交互统一说明
28
统一页面切换
29
统一手势
30
局部刷新/重新加载
31
模态/非模态
32
自适应/响应式
33
页面风格
34
页面布局
35
弹框样式及方式
36
功能规则
各种常见约束条件：
各种范围值
37
提示
网络中断
页面
38
访问异常（404，500）…更多内容？
？
？
页面
39
文案？
非正常情况
40
状态
41
操作说明
常见操作
42
特殊操作
43
误操作
44
适配说明
45
账号登录状态
46
好的PRD文档评估标准
标准
47
文档更新和维护
注意点
1.该文档是产品项目“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。
1.需求规格说明书
需求说明中包含的是针对现有版本需求的收集整理。
2.几种写PRD的形式
开发工具推荐：
RationalRose★★★★－－熟悉项目发生的相关业务行为。
visio2007★★★★－－将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统
mindmanager★★★－－把项目条目化，条理化，目录结构具体规定好。
Axure★★★－－前台结构布局，合理规范的将系统脱去朦胧的华纱。
Word★★★★★--穿针织网，把需求综合起来，整理成最终的产品需求文档。
WIKI★★★★★--可团队协同办公，能够记录文档的每一次变更
3.版本号
文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代，修改了几个版本。
文件命名的方法一般是通过版本号定义，比如简单的方法是，XX产品V1.0PRD_V2,前面的V1.0是产品迭代的编号，后面的V2PRD的版本号。
稍微详细点可以定义成，XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名，这样更便于阅读和记忆。
4修订历史：
记录文档的版本历史
包括，编号、文档版本、章节、修改原因、日期、修改人。
编号只是为了记录修改的顺序，文档版本显示的当前修改的内容属于文档的第几个版本（或第几次修改，一次修改一般为一个版本），章节是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修改原因说明为什么要修改该需求，让阅读者直观的了解原因。
日期是指需求文档修改的时间，修改人是指需求内容的修改者。
16功能定义
对系统实施提出的要求，即参与者希望系统提供何种能力满足其需求。
17用例定义
系统、子系统或能够与外部参与者交互所执行的动作序列，包括各种序列以及出错序列的规格说明。
用例是描述让系统做什么，而不是怎么做。
18用例写作规则说明：
18.1参与者：
参与者定义：
说明当与系统直接交互时，一些外部实体采用的角色。
它可以表示用户角色或由其它系统或者硬件所扮演的角色，是导致用例执行的本系统边界之外的事物。
参与者不一定指人，例：
当温度高于30°以上时，空调自动启动，此时系统的参与者就是温度了。
解释：
1、所有用例必须由参与者发起，也就是说每个用例最终都会对应一个或多个参与者；2、参与者应该位于你的系统范围之外；3、它应该是直接导致动作执行的原因（或称外因）；、参与者可能存在继承关系。
主要参与者：
就是上面讲的参与者
次要参与者：
在用例被触发之后，与用例进行交互的参与者
解释：
每个用例均只由一个参与者触发，相同的用例在不同时刻下可以被不同的参与者所触发（但同一时刻只能由一个参与者触发），所以触发该用例的被称为主要参与者，而可以触发该用例的其它参与者被称为次要参与者。
18.2前置条件：
在开始用例之前约束系统的状态。
它阻止参与者触发该用例直到满足所有条件。
18.3后置条件：
在用例执行之后约束系统的状态。
解释：
前置、后置条件是一个真与假的判断，就象Java里用到的assert（断言语句）就是做方法的前置、后置条件判断的；一个用例可以没有前置、后置条件，用none表示；前置、后置条件可以存在多个，可以交集（and）、可以并集（or）等。
18.4主要事件流：
用例中的主要场景描述。
主要事件流描述一个正常流程，主要事件流中可以带有流内分支（if...else），也可以存在流内循环（for,while），但无论流内分支还是流内循环，都必须可以达到后置条件。
18.5铺助事件流：
用例中次要场景的描述，如：
错误、分支或中断。
一个主要事件流可能对应多个铺助事件流；铺助事件流反映主要事件流的错误处理、重大分支等。
18.6include：
表示用例之间的包含关系。
就是说明一个用例的功能由另一个用例包含。
如果不包含这个用例，基础用例就不完整，或无法运作。
18.7extend：
扩展点和扩展用例，为已存在的用例添加新的行为的一种方法。
在没有扩展点的情况下，基础用例也很完整，类似锦上添加的功能设计。
18.8用例具体写作模板（注：
用例规格没有指定格式，只要能够灵活运用用例规格说明各个元素就可以了）。
用例名称：
ID：
描述：
主要参与者：
次要参与者：
前置条件：
1、
2、
主要事件流：
1、
2、
2.1、
2.2、
后置条件：
1、
2、
铺助事件流：
1、
2、
27.全局规范与说明
27、交互统一说明
1.字符限制
提高空间利用率，有时网页上的动态文字需要从数据库里提取部分然后截断处理。
2.链接具体化
很多网站都有对搜索结果的筛选设计（refinesearch），比如aliexpress搜索结果页左侧。
这块区域的交互事件是非常复杂的。
类目和属性的不同如何处理
属性以及每条属性显示的属性值的条目是否有显示上的限制?
选中后，被选中的属性值是停留在原地，方便用户记忆，还是放到统一的位置，方便用户统一查看?
其他未被选中的属性值是否消失?
3.交互细节说明
尝试用图对小小且复杂的区域进行详细说明后，事情变得简单多了
4表单的校验
这也是一项不怎么有创意的事情，但是你若不事先想清楚，在项目过程中有点麻烦。
6.浏览器的兼容性要求
你们的产品兼容所有浏览器简直是梦想，但是有时出于效率的要求，我们必须战略性放弃某些浏览器，比如IE6、7、8。
你要求兼容的浏览器越多，标准越高，前端的工作量就会越大，测试的工作量甚至也会翻倍。
28、统一页面切换
统一页面切换，我觉得web端写这个的比较少，更多的体现在app端，展示方式如下
29、统一手势
手势操作：
使用移动端产品时的操作方式。
比如滑动、放大、摇晃等
比如在左右侧抽屉，左右划通常可以返回主界面;比如顶部有切换Tab，是采用左右划切换还是点击切换;还比如有些应用双击可放大页面，两个手指按住并同时向中间滑动，表示缩小页面，比如长按可能会弹出复制及粘贴的选择框。
PRD主要功能列表介绍
功能列表，从以下简要说明，场景描述，业务规则，界面原型，使用者说明，前置条件，后置条件，主流程
功能需求
一般是由功能详情和主流程说明两大部分。
功能详情是所有的产品功能的描述和规划。
功能详情包括以下内容
简要说明
介绍此功能的用途，包括其来源或背景，能够解决哪些问题
场景描述
产品在哪种情况下会被用户使用，就是用户场景模拟。
这也是产品经理讲“好”故事的必备条件。
业务规则
每上产品在开发时都有相应的业务规则，将这些规则清晰的描述出来，让开发、测试人员能够直观的明白该规则，且没有产生歧义。
业务规则必需是完整的、准确的、易懂的。
业务规则的描述上如果涉及到页面交互或者页面的修改，建议给出页面的草图或者页面截图在图上说明要修改的内容。
另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关联性做出说明，什么时候可见，不可见，灰掉或点亮的条件在文档中都给出说明。
方便阅读者理解业务规则。
界面原型
如前所述，涉及到页面交互的部分，产品经理需要设计页面原型。
原型设计通常需要产品经理和UI设计师一起来完成。
使用者说明
对产品使用者做出说明，可融入简要说明中。
前置条件
该需求实现依赖的前提条件。
比如，上传照片时，需要存有图像文件。
后置条件
操作后引发的后续处理
主流程
把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明（这是非常重要的）。
看过很多的PRD，文档中对既没有前提条件，也没有后置条件，只对主流程做了说明，但是在描述主流程时却没有描写主流程中每个功能流程的各种走向，只有一个主走向，让人感觉prd成了操作手册。
事实上，对分支的介绍是非常重要的，开发和测试中提出的各类问题均与对分支的定义不明有关。
一个合格的PRD不仅要描述主流程，同时对分支流程所出现的各类问题都要做详细阐述并给出解决办法。
PRD的特征一定是明确的、全面的阐述需求及各类异常情况的处理而不是等到开发和测试阶段发现问题后再给以答案（虽然PRD不可能百分之百的覆盖所有的可能，但是最大化的思考所有的业务问题是编制PRD时必须遵守的原则）。
另外，在描写功能需求时给出的办法中不能出现“可能”、“或者”等词，一定是明确的，唯一的描述。
如果有别的方案，建议写入“可选方案”，在产品构建的早期可选方案可以为功能实现提供更多的选择，当方案确定后可在文档中注明本次使用了哪种方案。
推荐一个方法：
“用例”，在面向对象的软件设计模型中，用例是一个被阐述的内容，用例是对功能使用场景的解释。
用例很条理的介绍了每个功能的前置、后置条件，主流程介绍，帮助开发、测试等角色快速的了解产品功能。
PRD文档的写作标准
网上已经有太多互联网公司的PRD文档，淘宝、XX、腾讯等这类大型互联网公司都有自己的PRD规范，适合企业的需要的PRD才是真正PRD。
本期我们以淘宝的PRD为例，讲解一下PRD的主要内容。
1、文件命名（编号）
文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代，如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”，如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”，当出现产品第二版时，可以命名为“公司名-产品名-PRD-D2.0”。
2、修订控制页
一般有这么几项：
编号、文档版本、修订章节、修订原因、修订日期、修改人。
编号只是为了给个修改的顺序，文档版本显示的当前修改的内容是在哪个版本中出现，修订章节是具体到哪个章节哪个功能模块的修改，修订原因说明此功能修改的问题所在。
修订日期以修改当日的日期为修订日期，修改人显示修改内容模块的人，可能是当前用户也可能是其它产品人员。
3、目录
不建议自己去添加一个新的目录，你可以去其它的文档中拷一个过来，不考虑目录的内容，等写完PRD可以再去更新。
但建议用Mindmanager来整理一下思路。
4、请与以下部门讨论PRD
PRD做为一个承接作用的“载体”，会与技术、运营、财务等人员的沟通，而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上，需要与相关人员确定“沟通内容”，这对于产品整体流程将是很重要的。
同时对于产品核心功能的提取也是一个重要环节。
产品经理很重要的一个职能就是沟通。
例与客服中心：
客服服务部，讨论的内容：
预测客服成本、工作量；讨论客服如何支持；协助评估诈欺/数据窜改风险：
欺诈/数据窜改风险、不正使用风险。
这就是要写在与其它部门讨论PRD中的。
一个产品经理需要考虑如何与其它部门之间的沟通合作，文档很大一部分的功能是提醒你要做的工作，同时不断补充将要面临的工作。
5、概述
概念就是总结，它包括的点有：
名词说明、产品概述及目标、产品roadmap、产品风险。
名词说明：
名称、说明。
名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。
产品概述及目标：
解释说明该产品是干什么的，为什么需要这样的产品。
同时产品想要达到什么样的目标。
产品概述及目标就是对产品核心功能讲解，同时希望可以达到的期望。
产品roadmap：
产品分期目标，阶段描述，以及时间点的确定，产品是个不断演进的过程，很多时间一期产品只完成了产品70%的功能，二期才会继续去完善剩下的30%，同时有可能会推翻了重新推出第二版。
产品roadmap并不及着全部规划好所有的阶段目标，而是更多的通过维护来保持产品的更新和迭代。
产品风险：
描述产品可能存在的风险，比如商务谈判的风险，外部合作的风险，不当使用的风险等等。
风险级别为高中低。
6、使用者需求
使用者需求一般只有个需求描述。
需求描述有以下几项内容：
目标客户、需求描述、场景描述、优先级。
目标客户即为产品的最终用户，确定产品的最终使用者。
需求描述是对目标客户的需求描述，表达用户最需要的是什么，找到用户的最根本需求。
场景描述，产品在哪种情况下会被用户使用，就是用户场景模拟。
优先级是指用户对于当前产品功能需求的优先级，哪些是用户最想要的功能优先级则排前。
7、可选方案
列出所有可以选择的达到该产品目标的方案要点（主要思路），给各方案适当的评价，并推荐最优方案。
你在做这个产品规划时一定有很多的备选方案，别放弃这些方案，永远没有过时的idea，只有最适合时机的idea。
所以可以写出几个可选方案，或许是你下期产品改版一个方向。
8、效益成本分析
产品经理是个全才，在这点上得到了体验。
产品经理得知道财务知识。
很大一部分是产品的环境搭建成本和支持人员的成本。
一般的效益成本分析包括三个方面：
效益预测、产品技术中心成本、非产品技术中心支持成本。
效益预测是指提供在各种产品环境中的效益预测，并标明主要的变量及假设，最好能包含现在和过去的效益数据。
如网站的PV值，软件的使用数都是效益预测数据。
产品技术中心成本是指设计及部署此产品的产品技术中心所需的资源需求，包括人力成本，软硬件支出等。
很大时候这份成本需要由项目经理来协助，需要有什么样的人才加入产品中需与人力协助。
非产品技术中心支持成本，产品不是只有产品组完成的，同样需要其它部门的配合与协助。
比如：
需要客服部投入多少的资源用于该产品的服务，需要运营部投入多少的资源运营该产品。
9、功能需求
功能需求一般是由四部分组成，功能总览、功能详情、整合需求、BETA测试需求。
功能总览一般包括二个部分，一个是流程图，一个是功能表。
流程图是对产品的整体走向的流程的规划，流程图是用来对产品整体功能的梳理。
所以在做产品前建议所有的产品经理先梳理一下产品流程。
功能表是将流程图文字化，同时将列出产品的功能点。
功能详情，这是所有的产品功能的描述和规划。
包括以下内容：
简要说明：
告诉此功能主要干什么的。
业务规则：
每上产品在使用时都有自己的规则，而产品的业务规则则是将产品的流程细化。
个人建议将这个功能的业务规则，包括一些细节，如排版形式、日期显示方式全定好，这样方便其它人员的沟通和理解。
界面原型：
产品经理在这时做的原型界面只是显示的框架，别细化，这样会给交互和UI造成错觉。
只需做一个简单的界面即可，更多的时候只是个框架图。
执行者：
产品使用者。
前置条件：
具体的操作。
后置条件：
操作后的展示。
在UC（usercase）中后置条件又是另一种情况，所以对于建议在PRD中的前置条件和后置条件结果合起来。
主流程：
把主流放在最后是有道理的，结合上面所说的，做出主流程说明。
将此功能的流程走向做个分点说明。
10、整合需求
产品经理很重要的一个能力就是体现在产品整合能力上，利用公司现有的资源或外部资源（合作公司等）实现产品功能需求的整合。
实现功能贯穿的同时，更多的如何在新产品上实现功能的拓展来辅助核心功能。
11、BETA测试需求
很多产品都有BETA版本放出，为了就是收求意见和一些性能测试。
这部份内容不是必须的，但现在很多产品已经开始先推出BETA版本再推出正式版，当然也可以通过升级来解决。
所以BETA测试需求并不是一定需要的。
如果有BETA测试需求，则需写出BETA版测试的要求和期望达到的目标要求。
12、非功能性需求
都说产品经理是全才，在这点上得到彻底的体现。
很多产品经理在这点上忽视了，但很多方面是用到的，只是在产品过程中弱化了。
一般情况下非功能性需求包括以下几个部分：
产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需求等。
与其说是全方位的掌握技能，还不如说是沟通，如何与不同的部门人员之间的沟通，让更多的人协助产品的正常使用与上线。
13、上、下线需求
上线时限需求：
此产品预定上线日期？
上线日期有无任何特殊依据或规定？
下线需求（活动类需求必须明确下线时间）：
此产品预定下线日期？
下线日期有无任何特殊依据或规定？
14、运营计划
说明产品的后续运营计划。
包括与运营部的协作运营。
更多的是给产品经理如何让更多的产品功能展示给用户，产品经理是核心需求的把握者，参与到产品整体运营计划显得特别的重要。
最后，写PRD并不是产品经理的全部工作，但却是不可少的一部分，很大程度上反应了产品经理的思维和产品核心功能把握上，同时对产品经理沟通、协调、规划等都得到了一定的验证，但每个产品经理的第一职能是会写一份让其它人员看得懂的PRD。
PRD功能通用文档
1、交互说明要有的几种类型：
2、文字过多怎么显示。
3、操作瞬间会出现什么提示？
4、点击页面上的某部分内容，会出现什么反馈。
5、限制：
范围值，极限值。
6、状态：
包含默认状态，常见状态，特殊状态。
7、非正常情况下的样式、文案、说明。
8、未登录状态，登录后未签到状态，登录后已签到状态。
9、常见操作：
正常操作时得到的反馈状态。
10、特殊操作：
是指一些极端的情况下的操作。
11、误操作：
是指当用户操作错误时的情况，我们在设计时要尽量避免用户犯错的机会。
12、手势操作：
13、反馈：
主要指操作后，系统反馈给用户的文字说明。
14、跳转：
页面跳转到哪里。
设计师需要在原型上注明跳转时是“原页面刷新”还是“新页面打开”
15、平台用户包含几种角色，各个角色在平台里做的操作（比如邀请的时候要同时考虑接收者和发送者；已注册和未注册用户）。
16、无网络状态的提示
17、异常流程的说明（是否有缺失）
18、更新缓存数据（每次从服务端请求，还是有缓存到本地）
19、软件升级
20、图片的加载规则；图片比例；图片尺寸，根据手机屏幕大小，支持自动缩放；支持的图片格式（jpg、bmp、png、gif）
21、数据的存储规则（是否需要进行埋点，哪些需要做为数据统计之用，哪些不需要）
22、引导页是否要封包在app客户端程序中还是从服务器调取数据
23、引导页的操作方式（拖拽方式是自动还是平行滑动）
24、页面之间跳转的进入进出效果
25、页面显示条数，一次加载多少条
26、评论是否有二次回复
27、名称的限制条件（最长多少字符；是否支持半角中文、英文、数字及符号）
28、分享、关注规则
29、是否支持横屏
30、二维码的生成规则（多长时间刷新，多长时间失效）
31、推荐、附近的规则
32、搜索规则（是否支持纯汉字、纯英文（汉语拼音）、汉字+英文，是否支持联想）
33、排序规则
34、数据安全性说明
35、交叉事件说明（比如有来电、蓝牙）
36、刷新机制
37、消息推送规则
38、404等异常情况说明
39、SD卡问题（SD卡储存已满、储存位置等情况是否考虑并备注）
40、不同分辨率是否要适配？
如何适配？
41、是否支持第三方登录，登录后是否需要与自有的帐户绑定
42、不同账号登录状态
43、数据内容删除or违禁后如何展示
44、验证码的获取规则
45、系统升级提醒
46、页面布局是否考虑不同屏幕尺寸自适应问题
47、时间格式
48、页面返回说明（是返回上一层，还是返回上一级）
49、设备适配说明（iOS：
应适配iPhon4以上机型支持iOS7.0及更高系统版本，Android：
应适配华为、小米、魅族、支持Android4.0及更高版本系统。
）
50、系统风险评估（当前设计的功能存在哪些缺陷、注意事项与后期的功能拓展如何解决这些问题）
升级会员 