XXX产品需求文档
编号：SS-CP-JJGZHBQQ-20160304-01
XXX产品需求文档
修订记录
日期版本修改描述作者审核
目录
修订记录 (1)
1前言 (4)
1.1名词解释 (4)
1.2参考文档 (4)
1.3整体流程/逻辑关系 (4)
2特性 (4)
2.1特性F01手机微信摇一摇周边获得便签墙入口 (4)
2.1.1特性所包含的功能 (4)
2.1.2功能性需求(Functional Requirements，FR) (5)
2.2特性F02便签墙展示 (5)
2.2.1特性所包含的功能 (5)
2.2.2功能性需求(Functional Requirements，FR) (6)
2.3特性F03便签详情、发布及编辑 (7)
2.3.1特性所包含的功能 (7)
2.3.2功能性需求(Functional Requirements，FR) (9)
2.4特性F04便签管理 (11)
2.4.1特性所包含的功能 (11)
2.4.2功能性需求(Functional Requirements，FR) (12)
3性能需求 (13)
4其他需求 (14)
5附录 (15)
1前言
1.1名词解释
Beacon：是一种苹果定义的手机蓝牙物联网协议，目前广泛用于微信摇一摇周边中。
便签墙：本文档所描述的便签墙是基于手机beacon方式关联的电子便签墙，目标是解决实体便签墙遇到的占用面积，维护，更新，收费，共享等问题，实现物理便签墙的数字化。
1.2参考文档
无
1.3整体流程/逻辑关系
说明：说明项目本份需求文档描述的产品或组件的总体流程图或逻辑关系图。
2特性
2.1特性F01 手机微信摇一摇周边获得便签墙入口
当该beacon所有者设定了便签墙功能时，所有用户通过微信摇一摇可以摇出该功能入口链接并访问。
2.1.1特性所包含的功能
简要描述1、摇一摇入口
2.1.2.1F01.FR01 登陆
用户场景获取用户微信ID
功能描述获取用户微信ID
处理流程
补充说明
2.2特性F02 便签墙展示
2.2.1特性所包含的功能
简要描述1、便签展示
当用户点击便签墙入口，所有便签立体展示整体形态。
LOGO 公
2.2.2.1F02.FR01 手势缩放
用户场景手势缩放移动
功能描述手势双指pinch缩小放大放大状态下可以移动以查看其他部分
处理流程1、手势放大后可滑动
2、移动状态下任意点击便签可进入详情
3、点击返回或关闭回到预览便签墙状态
4、总便签数根据技术评估结果设定
补充说明
2.2.2.2F02.FR02预览内容加载用户场景预览状态预览
功能描述可以查看便签状态
处理流程1、预览时便签文字显示，热门状态便签标记，最新更新便签标记，赞成数标记
2、3分钟自动刷新
2、可查看空置状态
3、最新编辑的便签被标记
补充说明
2.3特性F03便签详情、发布及编辑
2.3.1特性所包含的功能
1、便签详情查看
简要描述
2、便签编辑发布和修改
当用户点击便签墙中某一个便签，页面呈现便签详情，详情页面框图如下：写于2016-03-03 23:00 XX浏览举报
支持XX反对XX评论XX 私信/编辑
热门评论：查看更多评论
用户ID：XXX支持
用户ID：XXX支持
点击过期标签或者空白标签可以添加内容，页面框图如下：
赞成XX反对XX评论XX保存/取消
当该便签墙被商户设定为收费状态时，便签保存后提示发布预览购买选项，页面框图如下：
发布X ▽天共计X元付款发布/取消
设定为免费时直接发布，设定为收费时转到微信支付。
点击查看更多评论进入评论页
2.3.2 功能性需求(Functional Requirements ，FR)
2.3.2.1 F03.FR01 便签详情浏览
用户场景 查看便签
功能描述
查看非本人的便签
处理流程
1、预览时点击某一便签浏览详情内容，增加一次浏览计数
2、可点赞成 反对 还可评论 举报 私信留言
3、当点击评论时可进行评论，还可将自己的评论或回复删除
4、点击私信发表私信，仅作者本人可查看到私信列表
补充说明
2.3.2.2 F03.FR02便签编辑
用户场景 发布和编辑便签
功能描述 点击空便签或本人便签编辑时可修改内容 处理流程
1、 预览时点击编辑修改内容
热门评论： 用户ID ：XXX 30楼XX 支持 用户ID ：XXX 25楼XX 支持
全部评论： 用户ID ：XXX 31楼 举报XX 支持XX 反对 用户ID ：XXX 23楼 举报XX 支持XX 反对 用户ID ：XXX 1楼 举报XX 支持XX 反对 添加评论 刷新返回
2、标题栏自动加粗，正文栏默认样式，标题栏或正文必填一项，标题字数限定20，正文
字数限制140，网址自动转链接标记按4个字长度算，正文字数未来版本可能调整
3、可设置禁止评论
4、修改完成保存
5、设置显示天数，付费发布跳转微信支付，免费发布模式限定每人每天发布次数
补充说明
2.3.2.3F03.FR03便签评论
用户场景查看和添加评论
功能描述查看所有评论并可添加评论
处理流程1、查看热门和所有评论
2、可点支持反对举报
3、限定评论字数70字
4、可添加评论每个新便签每个ID仅限一条，可删除或修改自己的评论
5、修改完成保存
补充说明
2.4特性F04便签管理
2.4.1特性所包含的功能
1、便签人工管理
简要描述
2、便签自动管理
商家点击便签墙管理，进入管理面板，页面框图如下：
○便签◎评论○公示信息
最新发布最多评论最多举报关键字搜索
选择（多选删除高亮禁止评论，延长显示天数）
当点击公示信息进入信息编辑，可编辑公告信息：○便签○评论◎公示信息
字体颜色：□保存/取消
2.4.2功能性需求(Functional Requirements，FR) 2.4.2.1F04.FR01 便签人工管理
用户场景商家管理所有便签
功能描述可对便签或评论列表排序和操作
处理流程1、点击排序第一次为正序，再次点击为倒序
2、输入关键字搜索，按发布时间先后排序结果，每项标签显示评论数，举报数，浏览数。
3、点击多选可以选择便签进行删除，高亮，禁止评论操作，延长显示天数
补充说明
2.4.2.2F04.FR02便签自动管理
用户场景系统自动管理便签
功能描述系统设定便签自删规则，便签系统自动删除不符合条件项
处理流程1、按时间排序删除
2、按热度排序删除
3、按便签或评论内容举报数门限值删除3、按综合指标排序删除
补充说明
2.4.2.3F04.FR033公示信息管理用户场景商家修改公示信息
功能描述修改公式信息标题及正文
处理流程1、标题必填，限定字数
2、正文选填，限定字数
3、可选择显示字体颜色
补充说明
3性能需求
分类细项提示相关特性
数据读写是否需要从server获取或向server
发送大量数据
关注过程的耗时、资源
占用
要求流量尽量低
是否需要保存或读取大量数据（本
地）
是否有大数据量的移动（导入、复
制、剪切、删除，等）
是否有数据搜索
4 其他需求
描述
1、
2、
补充说明
界面效果
是否会出现大量同类的界面元素 关注创建、展示、刷新、销毁过程的耗时
界面变化符合微信渲染要求，CPU 占用低
是否有动画效果
关注
其他 是否有批量操作
关注操作过程的耗时和响应速度
是否有内嵌网页
页面测速
是否有网页跳转
是否有定时处理逻辑 关注定时处理的内容量 是否有延时处理逻辑
关注延时点会跟其他逻辑重合、是否会造成视觉误解
是否是关键操作或常用操作 关注操作过程的耗时和响应速度
是否关联到关键操作：登录面板、登录/退出QQ 、打开/关闭会话窗口、用户资料窗口、主面板好友列表
5附录无
[PRD]产品需求文档规范模板
[PRD]产品需求文档 文件状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改文件标识：Company-Project-RD-UR 当前版本：Beta 1.0 作者： 完成日期：2013-03-05
修订历史 序号版本编写/修订说明修订人修订日期备注1 2
目录 一、项目概述 (4) 1、产品背景介绍 (4) 2、产品概述及目标 (4) 3、阅读对象 (4) 4、参考文档 (4) 5、术语与缩写解释 (4) 二、产品角色 (4) 三、产品设计约束及策略 (5) 四、产品模型 (5) 五、产品功能性需求 (5) 1.、业务流程图 (5) 2、功能模块划分 (5) 3、功能模块设计 (5) 六、产品非功能性需求 (6) 1、软硬件环境需求 (6) 2、产品质量需求 (6) 3、安全性需求 (6) 4、产品升级维护需求 (6) 5、接口需求 (6) 6、其他需求 (6)
一、项目概述 1、产品背景介绍 提示：主要介绍在在什么环境下做这个产品，为什么要做这个产品2、产品概述及目标 提示：产品的概要介绍，期望实现的目标 3、阅读对象 提示：指明文档阅读对象，如需求评审人员，开发人员，测试人员等4、参考文档 提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：[标识符] 作者，文献名称，出版单位（或归属单位），日期 例如： [SPP-PROC-PP] SEPG，需求开发规范，机构名称，日期 5、术语与缩写解释 缩写、术语解释 二、产品角色 提示：产品的使用者
三、产品设计约束及策略 提示:应当遵循的标准或规范，包含程序与UI部分的要求 四、产品模型 提示：用概念体现主要业务实体及其关系，并加以说明，大型实体关系图可以分块展示，内容包括：模型图，概念说明，关系说明 五、产品功能性需求 1.、业务流程图 提示：产品整体业务流程图，如过大，可分块展示 2、功能模块划分 提示：针对业务流程图，将所划分出来的模块及简要说明罗列出来 3、功能模块设计 提示：包括各模块的业务流程，用例描述，用户界面，字段及其他说明
产品需求文档范例
基本信息 编写人员编写时间 审核审核时间 版本V1.01 文档修订历史 序号版本号修订章节修订原因修订日期修订人修订说明 xxxx年xx月xx日
目录 前言--------------------------------------------------- 错误！未定义书签。第一章前言------------------------------------------------------------- 3 1.1编写目的---------------------------------------------------------------------- 3 1.2参考文献---------------------------------------------------------------------- 3第二章产品概述--------------------------------------------------------- 4 2.1产品简述---------------------------------------------------------------------- 4 2.2专有名词解释------------------------------------------------------------------ 4 2.3产品用户角色描述-------------------------------------------------------------- 5 2.4产品总体架构------------------------------------------------------------------ 5 2.5产品业务流程图---------------------------------------------------------------- 5 第三章产品功能需求----------------------------------------------------- 7 3.1 功能点1 ------------------------------------------------------------ 7 3.1.1需求编号及名称------------------------------------------------------------------------------- 7 3.1.2 需求说明 --------------------------------------------------------------------------------------- 8 3.1.3 功能业务流程图------------------------------------------------------------------------------ 8 3.1.4 功能流程 --------------------------------------------------------------------------------------- 9 3.1.5 产品界面原型-------------------------------------------------------------------------------- 11 3.1.6 相关字段 -------------------------------------------------------------错误！未定义书签。 第四章非功能性需求---------------------------------------------------- 12
如何写好产品需求文档解读
1.PM如何写好产品需求文档 1.1十步做好产品需求文档 做好产品需求文档的这十步，是经过长期的实践经验和反复验证而得到的。可能这里描述的不是很全面，但他已经足够让你做一个成功的产品需求文档。做好这几步花费的时间要以项目的大小、复杂程度、个体学识、基本技能熟练度而定。 1.2第一步：做好准备工作 你要做的是一个让人无可争议的产品，为了做好他，你必须做好前期的准备工作。你需要去了解你的顾客、竞争对手、产品团队的实力和需要的技术。你需要从顾客、用户、竞争对手、分析师、产品团队、销售队伍、市场、公司职员等收集他们能发现的问题和可能的解决办法。这里有很多的工作需要你去完成,在“成功的产品背后”这篇文章中有详细的描述。 建立良好的交流也非常重要，它会影响着产品团队。如果你的准备工作做的够好，你也会变得越来越有信心和说服力。 1.3第二步：确定产品的目的 任何一个好的产品都开始于一个需求。你必须清楚的了解这个需求，你的产品如何达到这个需求。 产品经理需要提出一个清晰、简明的价值主张，让它很容易被接受，要让产品团队、管理人员、用户、市场人员清楚的明白这个产品到底是什么意图。虽然这听起 来很简单，但是也只有少数产品才有这样的价值主张。考虑“velevator pitch ”(电梯间演讲、电梯行销)测试。假设你在做电梯的时候遇到公司CEO，他问你产品的意图是什么，你能在电梯到达之前回答这个问题吗？如果不能，你就还有 工作需要做。也许是你的说明没有针对性，他可能表现出来和其他产品做的没有什么明显区别；也许你提出的观点不能和你的用户产生共鸣；也许你解决的是一个非常规的问题，可能你想应用一种技术。这个价值主张可能需要满足公司
最新产品功能需求文档模板资料
会员中心功能需求文档 文件状态：[√] 草稿[ ] 正式发布[ ] 正在修改文件标识： 当前版本：V1.1.1.1 作者：闫会明 完成日期：2014-1-20
目录 1.商品管理 ...................................................................................................... 错误！未定义书签。 1.1.商品发布............................................................................................. 错误！未定义书签。 1.1.1.功能总表 (3) 1.1.2.总流程图 (4) 1.1.3.原型图 (5) 1.1.4.功能详情 (8) 1.1.5.补充说明 (11) 1.2.上架/下架 (12)
1.会员中心 会员中心为普通用户或高级用户处理和查看个人信息和店铺的功能模块。 1.1. 会员首页 目标客户需求描述场景描述优先级 普通会员高 高级会员 1.1.1.功能总表 功能总表 名称描述优先级备注 发布供应分类发布的供应进行分类。分类内容为（产品。招商。加盟） 您曾使用过的分类记忆高级会员曾经成功发布过产品的分类。 选择产品分类高级用户通过页面显示的分类选择来定义此次发布产品的分类。 店铺自定义分类选择将发布的产品加入店铺自定义分类 品牌选择根据用户的需要，自行选择要上传产品的品牌。 本网站产品发布属性可取样品。尾货。加工定制。可开发票。批发。多选项。具体功能体现在产品详细页 产品专属属性根据高级用户选择的本网站分类及品牌，从数据库内调取本产品的专属属性（例如：颜色型号、） 专属属性多选根据分类品牌系统调取本产品专属属性，多选。选填。 自定义属性用户自行添加产品专属属性。选填系统默认为一组自定义属性输入框。不可删除选填 规则解释（帮助功能）帮助填写者了解所填写的内容的定义。给予使用者以说明、解释、提示等功能。 产品包装信息用户编辑产品包装后的重量、长、宽、高、直径。 产品名称、产品关键字、产品图片、产品简短描编辑产品名称、产品关键字、产品图片、产品简短描述、产品详细描述。
产品需求文档(PRD)参考模板
Xxx系统需求说明
目录 1产品概述2 1.1目标&意义2 1.2领域知识3 1.3思维导图3 1.4业务流程图3 2功能围5 2.1功能名称5 2.1.1功能说明5 2.1.2用例说明5 2.1.3操作流程7 2.1.4界面原型9 2.1.5对应字段9 2.1.6相关规则10 3词汇表10 4非功能需求10 4.1规则变更需求10 4.2产品服务需求10 4.3帮助需求10 4.4安全性需求10 4.5上线实现需求3 5上线时间安排表10 1产品概述 说明：<简单描述项目的背景、意义、目的、目标等，描述领域知识> 1.1目标&意义 项目目标： 完整保存教师信息； 简化教师管理流程； 提高相关部门工作效率； 建立合理系统功能。 项目意义： 保证每学期开班的正常进行
建立有效的教师管理机制 按照统一规则计算工资，保证教师待遇、奖金的公平公正性 有效提高师资管理相关部门的工作效率，优化工作流程 1.2领域知识 说明：<包括：项目涉及到的业务背景、业务知识、业务词汇解释。> 项目类似于人力资源管理系统，主要信息管理、考勤、工资、合同、排名、访谈几个角度管理和利用教师信息为实际工作服务。 涉及工资核算、考勤制度。 1.3思维导图 <整个产品功能思维导图> 1.4业务流程图 <整个产品涉及业务的整个流程图>
2功能围 <主要功能描述> 2.1教师入职 2.1.1功能说明 <描述功能的作用> 新录入老师的信息管理 入职老师审批 专职老师转正审批 审批记录查询 2.1.2用例说明 <编写业务用例，即按照真实的用户业务划分用例，记录人机交互过程，完成用例描述>
如何写PRD(产品需求文档)
如何写PRD PRD是每个产品人员最经常看到的文档，还是有很多产品的朋友问我PRD怎么写，如何才能表达清楚意思。其实PRD并没有规定的格式，每个公司都可以根据自己公司的实际需要来写适合自己产品团队的PRD。 PRD（Product-Requirement-Document，产品需求文档），这对于任何一个产品经理来说都不会陌生的一个文档，一个PRD是衡量一个产品经理整体思维的标准，一个PRD可以看出一个产品经理在某个领域的专业性，同时也可以反应出一个产品经理的整体产品思维。 产品经理的整体思维体现在： 1、提炼核心需求 2、思考满足核心需求的方式 3、评估方式优劣选定方案 4、思考功能概要 5、思考支撑功能和关联功能 6、细化设计功能 7、子功能（功能间迭代） PRD其实就是将以上的思维整体走向写出来，同时将产品的思想提炼出来，用文字表示给开发者，给UI、给视觉、给老板……PRD给的是一种思想，将产品的整体思想和核心需求灌输给产品的相关人员，都说PRD是个承上启下的功能，因为上接MRD，下对MRD进行技术性的描述。 网上已经有太多互联网公司的PRD文档，淘宝、百度、腾讯等这类大型互联网公司都有自己的PRD规范，适合企业的需要的PRD才是真正PRD。以淘宝的PRD为例，讲解一下PRD的主要内容。 1、文件命名（编号） 文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代，如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”，如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”，当出现产品第二版时，可以命名为“公司名-产品名-PRD-D2.0”。 2、修订控制页 一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序，文档版本显示的当前修改的内容是在哪个版本中出现，修订章节是具体到哪个章节哪个功能模块的修改，修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期，修改人显示修改内容模块的人，可能是当前用户也可能是其它产品人员。
产品需求文档(PRD)的写作方法
产品需求文档(PRD)的写作方法 无论我们做什么事都讲究方式方法，写产品需求文档(以下称PRD文档)也是如此，之前我通过五篇文章分享了自己写PRD文档的一些方法，而这一篇文章主要是对之前五篇文章进行整体的摘要介绍，帮助大家快速了解写作流程。 产品需求文档(PRD)的写作五篇章： 1、写前准备(信息结构图) 2、梳理需求(产品结构图和用户流程图) 3、原型设计(手绘原型,灰模原型,交互原型) 4、撰写文档(PRD文档) 5、用例文档(UML用例图、流程图)
1、写前准备(信息结构图)： 在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。 例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。 罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。 2、梳理需求(产品结构图和用户流程图)： 当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步是梳理产品的需求。我们首先要罗列出产品的频道及页面(产品结构图)，其次再基于产品结构图梳理出频道及页面中的功能，并延伸构建出用户的操作流程(用户流程图)。 以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。
腾讯QQ产品需求文档模板
说明：本文中蓝色斜体字体为说明性文字，写文档时请删除或替换。 XXX 修订记录 日期版本修改描述作者审核2009-6-8 V1.0 简化。第一稿Tracy、ericmin、 edisonchen 2009-6-22 V1.1 删除数据上报。增加名词解释、 Jessicadou、tracy 整体流程、参考文档部分 目录 修订记录 (1) 目录 (1) 1前言 (2) 1.1名词解释 (2) 1.2参考文档 (2) 1.3整体流程/逻辑关系 (2) 2特性 (2) 2.1特性F01XXXX (2) 2.1.1特性所包含的功能 (2) 2.1.2功能性需求(Functional Requirements，FR) (2) 2.1.2.1F01.FR01 XXXXX (2) 2.1.2.2F01.FR02 XXXXX (3) 2.2特性F02XXXX (3) 3性能需求 (3) 4国际化需求 (4) 5附录 (4)
1前言 1.1 名词解释 说明：列出本文档中所用到的专门术语的定义和缩略语的全称和解释。 1.2 参考文档 说明：列出本文档的所有参考文档。 1.3 整体流程/逻辑关系 说明：说明项目本份需求文档描述的产品或组件的总体流程图或逻辑关系图。 2特性 2.1 特性F01 XXXX 说明：陈述该特性的简要说明。F指特性，m为1~n的自然数，Fmm为该特性的编号。如：1.1特性F03 截图功能优化。 2.1.1特性所包含的功能 简要描述简要描述此特性包含的功能点及优先级：1、屏幕截图灰屏机制优化（高） 2、 3、 2.1.2功能性需求(Functional Requirements，FR) 2.1.2.1F01.FR01 XXXXX 说明：将复杂特性细分为系统需求，陈述该功能的详细说明。如：1.1.2.1 F01.FR01屏幕截图灰屏机制优化。 用户场景描述此需求的使用场景 功能描述简要描述此需求要实现的功能 处理流程详细描述此需求的处理步骤，以及相关的交互说明
产品策划需求文档模板
XX产品策划 需求文档规范_版本号(V1.2) 版权所有侵权必究
1. 文档历史 文档阅读提示：勾选视图中的导航窗格，可以让您快速阅读本文档。
2. 文档目录 1. 文档历史 (3) 2. 文档目录 (4) 3. 项目说明 (6) 3.1项目背景和目标 (6) 3.1.1 项目背景 (6) 3.1.2 项目目标 (6) 3.2项目大概 (6) 3.2.1 首页 (7) 3.2.2 页面A (7) 3.2.3 页面B (7) 3.3页面汇总 (7) 3.3项目排期 (7) 4. 项目策划 (8) 4.1主要逻辑图 (8) 4.2功能/特性列表（FEATURE LIST）测试重点关注 (8) 4.3交互/视觉设计 (9) 4.3需求详细描述 (9) 4.3.1免费首页 (9)
5. 统计需求 (14) 5.1数据建设：考核评价指标 (14) 5.2数据统计 (14) 5.2.1 点击流统计 (14) 5.2.2 开通红钻统计 (15) 6. 客服文档 (15) 7. 运营方案 (15)
3. 项目说明 3.1 项目背景和目标 3.1.1 项目背景 [背景的描述，主要是当前出现了什么问题？市场上有了什么新的导向？用户有什么样的期待需要我们满足？等] ●一级[文档结构可以多级，但是不要搞混逻辑层次] ?二级 ◆三级 四级 3.1.2 项目目标 [由背景推导出的目标，简明扼要，目标通常是贯穿整个需求的线索，整个需求都应该是围绕目标在进行的，包括优先级的排列，也是看需求点能实现目标的程度、效率、紧迫性、成本控制等各方面的综合优势] 3.2 项目大概 [可以分页面、功能模块、流程等进行描述，下面示例，XX产品涉及到3个T ab对应的页面，所以采用分“页面”的描述思路] 举例： XX产品的三个页面
[PRD]产品需求文档
[PRD]产品需求文档
修订历史
一、项目概述 (4) 1、产品背景介绍 (4) 2、产品概述及目标 (4) 3、阅读对象 (4) 4、参考文档 (4) 5、术语与缩写解释 (4) 二、产品角色 (4) 三、......................................................... 产品设计约束及策略5 四、产品模型 (5) 五、产品功能性需求 (5) 1、............................................................................................................................. 、业务流程图 5 2、功能模块划分 (5) 3、功能模块设计 (5) 六、产品非功能性需求 (6) 1、软硬件环境需求 (6) 2、产品质量需求 (6) 3、安全性需求 (6) 4、产品升级维护需求 (6) 5、接口需求 (6) 6、其他需求 (6)
、项目概述 1、产品背景介绍 提示：主要介绍在在什么环境下做这个产品，为什么要做这个产品 2、产品概述及目标 提示：产品的概要介绍，期望实现的目标 3、阅读对象 提示：指明文档阅读对象，如需求评审人员，开发人员，测试人员等 4、参考文档 提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下: [标识符]作者，文献名称，出版单位（或归属单位），日期 例如： [SPP-PROC-PP] SEPG ,需求开发规范，机构名称，日期 5、术语与缩写解释 、产品角色 提示：产品的使用者
PRD产品需求文档经典模板
产品需求文档模板 XXX产品需求文档 [注：产品需求文档的定义：此文档的目的是收集、分析和定义<
目录 一、简介 (3) 1、目的 (3) 2、范围 (3) 二、产品概述 (3) 三、流程图 (3) 1、业务流程图（推荐泳道图） (3) 2、状态图（理清状态流转） (4) 四、用户角色描述 (4) 五、权限描述 (5) 1、管理员 (5) 2、操作员 (5) 六、功能摘要 (5) 七、产品特性 (6) 1、XXXX页面 (6) 1.1 优先级 (6) 1.2 特性描述 (6) 1.3 XXX页面 (6) 八、全局需求 (7) 1、性能需求 (7) 2、监控需求 (7) 3、兼容性需求 (7) 九、风险分析 (7) 十、相关文档 (7)
一、简介 对整个《产品需求文档》的简介，旨在让读者快速知道本文档的大体内容，对本文档有一个心里预期（包括介绍本文档所涉及的产品功能等，具体字数不宜太多） 1、目的 介绍本文档的目的 2、范围 主要描述前端页面涉及到的功能点、相对应的后台管理功能支持、以及部分交互细节。本文档主要读者为技术部门的前端工程师，以及视觉部门的视觉设计。 二、产品概述 用简便的话语来描述产品 三、流程图 1、业务流程图（推荐泳道图） 举例：
产品需求文档模板
[本文给出产品需求文档的一个模板，实际使用时可根据具体情况选择其中的章节进行撰写，也可进行调整。例如： 1)需求较简单时，第1至5章可压缩成一章“需求概述”。 2)如果整个需求就是对一两个页面进行描述，可以仅仅撰写7.2这样的内容。] [需求名称]产品需求文档 目录 1 背景描述 (2) 1.1 问题现状 (2) 1.2 问题分析 (2) 1.3 解决提议 (2) 2 愿景 (2) 3 项目目标 (2) 4 涉众 (2) 5 业务建模 (3) 5.1 用例图 (3) 5.2 对象关系图 (4) 5.3 页面关系图 (4) 5.4 流程图 (5) 5.5 菜单和权限 (5) 6 功能描述 (6) 6.1 功能列表 (6) 6.2 通用功能或规则描述 (6) 7 详细功能描述 (6) 7.1 功能模块：[功能模块名称] (7) 7.1.1 [具体功能（用例）名称] (7) 7.2 [页面名称] (8) 8 风险分析 (9) 9 非功能性需求 (9) 9.1 语言支持 (9) 9.2 浏览器 (9) 9.3 可靠性 (9) 9.4 可用性 (9) 9.5 可支持性 (9)
9.6 性能 (9) 10 附录 (9) 10.1 系统界面交互原型 (9) 10.2 系统相应文案信息 (9) 10.3 词汇表 (9) 11 参考资料 (9) 1背景描述 1.1问题现状 [描述当前产品存在什么问题，或者市场存在什么机会，用户存在什么麻烦需要解决] 1.2问题分析 [就前面提到的产品问题、市场机会或用户麻烦进行分析，透过现象挖掘出问题的本质原因。] 1.3解决提议 [承接前面对问题的分析，给出问题的解决方案。] 2愿景 [该产品长远的发展规划和展望] 3项目目标 [该产品在本需求文档所涉及的项目范围内所期望达到的目标，最好是含有可检查的量化目标，例如产品发布1个月后，独立用户量达到日均100万] 4涉众 [在下表中列出该产品所涉及的所有利益方，每个利益方占一行。例如一个网站广告系统的涉众主要为“广告主”、“网站用户”和“网站后台管理人员”]
产品需求文档(PRD)模板
《项目名》PRD文档 更新记录 目录 一、概述 (2) 1. 需求说明 (2) 2. 产品结构 (2) 3. 主业务流程 (3) 二、名词释义 (3) 三、功能性需求 (4) 1. 全局性交互或数据规则 (4) 2. 模块A (4) 3. 模块B (6) 四、非功能性需求 (7)
五、数据统计需求 (7) 六、交付与上线 (8) 1. 交付说明 (8) 2. 上线方案 (8) 一、概述 1.需求说明 本项目/产品需求为XXXXXXXXX。 主要说明项目的背景和原始需求，帮助团队成员理解需求的出发点。 2.产品结构
简述该产品或需求的完整主体结构（推荐使用MindManager/Xmind等工具绘制脑图表达），但该结构应和后文的功能性需求或非功能性需求说明目录保持统一。 3.主业务流程 对核心业务流程进行图示，常用流程图、泳道图（常用工具为visio）来表达。但注意，此处非详细的逻辑/交互流程，而是主业务流程示意。 二、名词释义 1.名词A：释义说明 2.名词B：释义说明 若该产品或需求文档内，存在部分全新定义的专有名词，或部分较少使用到的第三方用语，则提前单独附上释义。
三、功能性需求 1.全局性交互或数据规则 1)交互 全局性的交互更多见于一些加载、网络、提醒情况下，某些特定的交互和场景下也可能存在特殊的全局性需求（如微信的悬浮窗功能）； 2)数据规则 全局性数据规则常见于最高优先级（相对）的数据，用于限制下级数据的下发，如黑名单管理、用户状态等。 2.模块A 1)子模块a（内容/信息展示型） a)原型 b)信息 c)交互 d)数据规则 e)异常状态 2)子模块b（功能/交互流程型） a)完整流程逻辑说明 b)原型
产品需求文档模板新版
<产品名称>产品需求说明书 [注：产品需求说明书的定义：此文档的目的是收集、分析和定义<
修订记录：
目录 一、简介 (12) 1、目的 (12) 2、范围 (12) 二、用户角色描述 (12) 三、产品概述 (12) 1、总体流程 (13) 2、功能摘要 (15) 四、产品特性 (16) 1、读书人社区首页 (16) 1.1 优先级 (16) 1.2 特性描述 (16) 1.3 社区首页 (16) 1.3.1 读书会列表 (16) 1.3.2 热评书潮 (17) 1.3.3 视频节目 (17) 1.3.4 社区名人 (18) 1.3.5 读书会推荐 (18) 1.3.6 热门原创 (19) 1.3.7 读书快报（新闻） (20) 1.3.8 合作伙伴列表（页底） (20) 2、板块一——藏书阁 (21) 2.1 藏书阁首页 (21) 2.1.1 页面描述 (21) 2.1.2 搜索 (21) 2.1.3 书籍推荐 (21) 2.1.4 书评推荐 (22) 2.1.5 名家读书会专题 (23) 2.1.6 分类推荐 (24) 2.1.7 一周好书 (25) 2.1.8 排行榜 (25) 2.1.9 读书会推荐 (27) 2.1.10 合作伙伴 (27) 2.2 分类浏览 (27) 2.2.1 页面描述 (27) 2.2.2 模块定义 (27) 2.2.3 藏书分类 (27) 2.2.4 藏书 (29) 2.2.5 书籍推荐 (31) 2.2.6 读书会（用户自建社团）推荐 ......................................................错误！未定义书签。
PRD产品需求文档
PRD是每个产品人员最经常看到的文档，还是有很多产品的朋友问我PRD怎么写，如何才能表达清楚意思。其实PRD并没有规定的格式，每个公司都可以根据自己公司的实际需要来写适合自己产品团队的PRD。 PRD（Product Requirement Document，产品需求文档），这对于任何一个产品经理来说都不会陌生的一个文档，一个PRD是衡量一个产品经理整体思维的标准，一个PRD 可以看出一个产品经理在某个领域的专业性，同时也可以反应出一个产品经理的整体产品思维。 产品经理的整体思维体现在： 1、提炼核心需求 2、思考满足核心需求的方式 3、评估方式优劣选定方案 4、思考功能概要 5、思考支撑功能和关联功能 6、细化设计功能 7、子功能（功能间迭代） PRD其实就是将以上的思维整体走向写出来，同时将产品的思想提炼出来，用文字表示给开发者，给UI、给视觉、给老板……PRD给的是一种思想，将产品的整体思想和核心需求灌输给产品的相关人员，都说PRD是个承上启下的功能，因为上接MRD，下对MRD进行技术性的描述。
网上已经有太多互联网公司的PRD文档，淘宝、百度、腾讯等这类大型互联网公司都有自己的PRD规范，适合企业的需要的PRD才是真正PRD。以淘宝的PRD为例，讲解一下PRD的主要内容。 1、文件命名（编号） 文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代，如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”，如果涉及到功能需求增加可以命名为“公司名-产品名-PRD- D1.1”，当出现产品第二版时，可以命名为“公司名-产品名-PRD-D2.0”。 2、修订控制页 一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序，文档版本显示的当前修改的内容是在哪个版本中出现，修订章节是具体到哪个章节哪个功能模块的修改，修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期，修改人显示修改内容模块的人，可能是当前用户也可能是其它产品人员。 3、目录 不建议自己去添加一个新的目录，你可以去其它的文档中拷一个过来，不考虑目录的内容，等写完PRD可以再去更新。但建议用Mind manager来整理一下思路。 4、请与以下部门讨论PRD PRD做为一个承接作用的“载体”，会与技术、运营、财务等人员的沟通，而与这些人员
产品需求文档PRD模板
***产品需求文档 xxxx年xx月xx日 目录 前言---------------------------------------------------- 错误!未定义书签。
第一章前言------------------------------------------------------------- 3 1.1编写目的---------------------------------------------------------------------- 3 1.2参考文献---------------------------------------------------------------------- 3第二章产品概述--------------------------------------------------------- 3 2.1产品简述---------------------------------------------------------------------- 3 2.2专有名词解释------------------------------------------------------------------ 3 2.3产品用户角色描述-------------------------------------------------------------- 4 2.4产品总体架构------------------------------------------------------------------ 4 2.5产品业务流程图---------------------------------------------------------------- 4 第三章产品功能需求----------------------------------------------------- 6 3.1 功能点1 ------------------------------------------------------------ 6 3.1.1需求编号及名称------------------------------------------------------------------------------- 6 3.1.2 需求说明 --------------------------------------------------------------------------------------- 7 3.1.3 功能业务流程图------------------------------------------------------------------------------ 7 3.1.4 功能流程 --------------------------------------------------------------------------------------- 8 3.1.5 产品界面原型-------------------------------------------------------------------------------- 10 3.1.6 相关字段 --------------------------------------------------------------- 错误!未定义书签。 第四章非功能性需求---------------------------------------------------- 11 4.1产品性能需求----------------------------------------------------------------- 11 4.2测试环境需求----------------------------------------------------------------- 12 4.3产品数据统计需求------------------------------------------------------------- 12
产品需求文档模板(PRD)
产品需求文档（PRD）标题 logo 修改记录 项目成员 定稿会签
PRD拟制人 产品负责人 需求方负责人 设计负责人 制作负责人 开发负责人 测试负责人 技术部负责人 最高决策人 意见汇总PRD拟制人意见汇总： 产品负责人： 需求方负责人： 设计负责人： 制作负责人： 开发负责人： 测试负责人： 技术部负责人： 最高决策人： 文档目录
1. 总体说明 (4) 1.1项目概述 (4) 1.2功能范围 (4) 1.3用户范围 (4) 1.4假定及约束 (4) 1.5词汇表 (4) 1.6非功能需求 (5) 1.7其他说明 (5) 1.8参考资料 (5) 2. 功能结构 (5) 3. 功能流程 (6) 4. 用例场景 (6) 4.1用例整体说明 (6) 4.2用例具体说明 (6) 4.2.1 用例名称1 6 4.2.2 用例名称2 7 5. 风险规避 (8)
1. 总体说明 1.1 项目概述 ＃详细填写产品项目意图、目标等 ＃待开发的系统的名称； ＃本项目的任务提出者、目标用户； ＃该系统同其他系统或其他机构的基本的往来关系（如CRM CMS 用户中心…）。 1.2 功能范围 1.3 用户范围 ＃描述本项目所服务的最终用户的特点，用户用例等； ＃如存在管理用户充分说明操作人员、维护人员的教育水平和技术专长，及预期使用频度。 1.4 假定及约束 1.5 词汇表
＃列出本文件中用到的本专业，个性定义，外文首字母组词的原词组等。 1.6 非功能需求 1.7 其他说明 1.8 参考资料 2. 功能结构
3. 业务功能流程 ＃产品整体业务流程图 4. 业务对象模型 # 所有业务对象/实体对象的组成结构及描述5. 业务对象状态模型 ＃有状态的业务对象状态、转换及描述6. 用例场景 6.1 用例整体说明 6.2 用例具体说明 6.2.1 用例名称
XXX需求文档_需求实用模板
实用标准文档 XXXXX科技有限公司 xxxxx需求文档_应用名 作者 [写作日期] [此处写文档的摘要，这是一份什么需求文档，主要包含哪些内容。]
版本修订记录 注：此处的VX.X.X是指修订功能会在VX.X.X版本中发布。
目录 xxxxx需求文档_应用名 (1) 版本修订记录 (2) 目录 (3) 第一章概述 (4) 1.1 概述 (4) 1.1.1定义 (4) 1.1.2目的 (4) 1.1.3范围 (4) 1.1.4参考文档 (4) 1.1.5阅读对象 (5) 1.2 目标 (5) 1.3 总体流程图 (5) 1.4 功能摘要 (5) 1.5 术语略缩语解释 (5) 第二章功能性需求 (6) 2.1 一级功能1 (6) 2.1.1功能点1 (6) 2.1.2功能点2 (8) 2.2 一级功能2 (8) 2.2.1功能点1 (8) 第三章产品其它需求 (9) 3.1性能需求 (9) 3.2监控需求 (9) 3.3兼容性需求 (9)
第一章概述 1.1 概述 [产品需求说明书文档的简介应提供整个文档的概述。它应包括此产品需求说明书文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。] 1.1.1定义 [此功能模块的定义，包含是什么、为什么、要达到怎样的目的] 1.1.2目的 [简要说明此需求的目的；如：“XXX”需求文档供开发人员作为功能开发的依据、测试人员作为测试用例的依据] 1.1.3范围 [简要说明此产品需求说明书文档的范围、它的相关产品，以及受到此文档影响的任何其他事物。] 1.1.4参考文档 [此需求文档借鉴了哪些其他需求文档，以及除此需求外需要参考的其他需求文档需要一一列出]
产品需求文档(PRD)参考模板
点尖商务淘宝需求说明
文档历史记录 注：后期所加内容均绿色背景字体标注
目录 1 产品概述 (4) 1.1 目标&意义 (4) 1.2 领域知识 (4) 1.3 业务流程图 (4) 2 功能范围 (4) 2.1 功能名称 (5) 2.1.1 功能说明 (5) 2.1.2 用例说明 (5) 2.1.3 操作流程 (6) 2.1.4 界面原型 (8) 2.1.5 对应字段 (8) 2.1.6 相关规则 (9) 3 词汇表 (9) 4 非功能需求 (9) 4.1 规则变更需求 (9) 4.2 产品服务需求 (9) 4.3 帮助需求 (9) 4.4 安全性需求 (9) 4.5 上线实现需求 (3) 5 上线时间安排表 (9)
1产品概述 该项目开发是为了点尖商务管理系统—淘宝管理，开发的淘宝订单、客户及销售金额管理。以满足销售人员和财务人员更方便在该ERP系统里面看见销售报表及交易记录查看，更同一公司商品库存的管理 1.1目标&意义 项目目标： 完整的对淘宝订单信息、客户信息、支付宝交易记录，更好的为客户服务 项目意义： 让销售人员看见自己的销售情况，和财务报表的查看 1.2领域知识 项目类似ERP管理系统，主要商品管理、品牌、订单、出库单、库存、电商B2C网站、财务管理等系列 1.3业务流程图 同步订单流程图： 订单查询流程图： 2功能范围 <主要功能描述>
2.1教师入职 2.1.1功能说明 <描述功能的作用> 新录入老师的信息管理 入职老师审批 专职老师转正审批 审批记录查询 2.1.2用例说明 <编写业务用例，即按照真实的用户业务划分用例，记录人机交互过程，完成用例描述> <
产品需求文档(PRD)的写作方法
产品需求文档（PRD）的写作方法 无论我们做什么事都讲究方式方法，写产品需求文档（以下称PRD文档）也是如 此，之前我通过五篇文章分享了自己写PRD文档的一些方法，而这一篇文章主要是对之前五篇文章进行整体的摘要介绍，帮助大家快速了解写作流程。 产品需求文档（PRD）的写作五篇章： 1、写前准备（信息结构图） 2、梳理需求（产品结构图和用户流程图） 3、原型设计（手绘原型,灰模原型,交互原型） 4、撰写文档（PRD文档） 5、用例文档（UML用例图、流程图） 1、写前准备（信息结构图）： 在写PRD文档之前，我们需要先罗列出产品功能的信息内容，这一步是将想法逐渐清晰的第一步，也是帮助我们接下来规划功能的辅助信息，同时也可以辅助服务端技术人员创建数据库。因为这是第一步，所以我们不需要罗列的很详细，在之后的步骤里，我们会逐步改进和完善信息内容。 例如一篇文章的信息内容主要有：文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容，但是在之后的功能规划中逐渐更加细致的考虑时，可能会增加或者删减，因此第一步我们不用刻意的追求信息的全面。 罗列信息内容的方式有很多种，文本形式、思维导图形式等等都可以，最主要的是能够
清晰易懂，我最常用的方法就是思维导图，因此我称这一步为信息结构图。 2、梳理需求（产品结构图和用户流程图）： 当我们对产品的信息结构了解后，我们就需要规整脑海中的产品需求，让想法更加结构化，因此这一步是梳理产品的需求。我们首先要罗列出产品的频道及页面（产品结构图），其次再基于产品结构图梳理出频道及页面中的功能，并延伸 构建出用户的操作流程（用户流程图）。 以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解，类似鸟瞰式的一目了然，也方便调整完善。 3、原型设计（手绘原型,灰模原型,交互原型）： 当我们逐渐清晰了产品的需求后，并梳理了产品的各个频道及页面，那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。 首先我建议通过手绘的形式快速在草纸上绘制出产品的原型，推演和讨论方 案的可行性，当有一定的进展之后，我们再通过软件工具进行更深入的设计。移动产品可以考虑灰模原型，网站产品可以考虑交互原型，对于这两种原型方式，无论是移动产品还是网站产品都可以使用，具体取得于你的个人习惯和团队要求。 对于产品经理来说，原型设计是为了帮助我们细致的考虑方案，并论证方案的可行性，同时也是为了避免产品宣讲时，抽象的语言描述导致听众理解困难和理解偏差。 4、撰写文档（PRD文档）： 当我们通过以上三个大的步骤之后，我们就已经非常清晰产品的需求了，一般情况下，通过原型加描述的方式就已经完成了PRD文档的目的（很多产品经理直接使用Axure制作PRD> 当然也会有一些个人或团队的要求不一样，对PRD文档有特定的规范标准，这类情况可能是需要存档归类。无论什么样的规范标准，PRD文档的目的都是相 近的，因此功能描述的方式也是相似的，所以在这里我分享了三种撰写PRD文档的方式。5、用例文档（UML用例图、流程图）： 《产品需求文档（PRD）的写作方法》的补充文章，主要讲解PRD文档中的重要辅助文档“用例文档”。