产品需求文档的写作(一) – 写前准备(信息结构图)

产品需求文档的写作(一) – 写前准备(信息结构图)
产品需求文档的写作(一) – 写前准备(信息结构图)

当我们初次接触产品需求文档时,首先会从网络上寻找产品需求文档模板,希望从中了解和学习具体的写作要求,但实际上,现在网络上绝大部分的PRD文档都是与实际工作不相符的,或者说是复杂的。

前几天一位从事产品类工作的朋友,发来一份他写的产品需求文档目录截图给我(下图),当时我就郁闷了,这些类目更像是MRD文档,而不是PRD文档了,因此我决定写几篇讲述写作PRD文档的文章,分享一些我关于PRD文档的见解和写作方法。

PRD是英文Product Requirement Document的缩写,中文的意思是产品需求文档,具体的名词介绍大家可以询问Google。PRD文档是基于BRD、MRD 的延续文档,主要用于产品设计和开发使用,因此阅读这份文档的人群绝大多数是设计与技术人员。在这类人群中,设计师更多依赖于原型进行交互或视觉的设计,因此看这份文档的人就会偏向于技术人员。相对于技术人员,他们不太关注产品的商业需求和市场愿景,因为在进行产品讨论立项时,产品的定义就已经向参与设计和研发的人员宣讲过,因此技术人员更多的是关注界面、功能、交互、元素等等内容,因此PRD文档是一份详细的产品功能需求说明文档,是产品文档中最底层和最细致的文档。

PRD文档是一份没有闲话,直入主题的功能说明文档,因此我们在写作时,脑海里构思的是成品产品的界面功能的逻辑线框图。在写作这份文档前,我们需要先做一些准备,把BRD、MRD的相关需求消化并融合规划出产品的结构图。因为这些准备工作是属于思维类的,所以我推荐使用思维导图软件(MindManager)进行规划工作。

规划产品的第一步就是梳理出产品的信息结构,有了信息结构我们才能继续往下规划产品结构,并且信息结构是服务端技术人员创建数据库的依据,是数据结构的辅助文件。对于新产品或者新功能,没有人能够比产品经理更加清楚所需要的信息内容了,因此第一步我们就需要先将这些信息罗列出来,形成结构化。(如下图)

这张图是以我的博客作为示例,在罗列信息结构时,我们更多的是考虑信息数据,因此在这一步,我们还不需要深入的考虑产品的界面与功能。信息结构的考虑有面向前端的,也有面向后端的,具体视产品类型而定。

例如CMS之类的程序,这类程序采用框架式开发,将功能与模板独立,因此前端具有多变性,并且这类产品属于平台型产品。针对这类产品,我们在规划信息结构时,只需要简单的考虑一些前端的功能需求,更多的是面向后端管理员操作进行考虑,从后端入手规划和罗列出所需要的信息内容结构。

无论是什么样的产品类型,无论从哪里入手,我们第一步都是先要罗列信息结构,因为信息结构图不仅是辅助技术人员创建数据库的图表,也是辅助产品人员进行产品功能规划的参考,只有对信息或数据的结构了解,我们才能玩转数据,玩转产品。

在信息结构转数据结构时,如果是针对已经存在的产品而增加的新功能,那么技术人员就需要根据这个信息结构进行数据库对比,已经存在的数据便直接调用,如果不存在,则就需要具体的讨论,确定新信息的使用途径和以后的扩展方向,以便确认是创建数据表还是创建数据字段。(虽然产品经理不需要技术开发,但是如果能够懂技术原理和数据库原理,非常有助于产品规划和技术沟通。)

信息结构图是产品层面的理解,如果要入库这些信息,还需要进行数据结构的讨论。一条信息的存储有很多附加属性,具体是存成字段还是数据表,还是说存在中间表或者关联表,这些都需要在完成PRD文档后和数据库技术人员共同讨论。讨论时除了展示信息结构图,还要讲解产品原型和功能需求,以便数据库技术人员了解产品意图,方便他们做数据库规划时考虑到以后的扩展。

信息结构图是我们将概念想法形成结构化的第一步,也是我们接下来几步工作的辅助文件,同时在接下来的几步工作中,我们还会不断的完善信息的结构。

最新整理腾讯产品需求文档.doc

说明:本文中蓝色斜体字体为说明性文字,写文档时请删除或替换。 XXX 修订记录 目录 修订记录 (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特性所包含的功能 2.1.2功能性需求(Functional Requirements,FR) 2.1.2.1F01.FR01 XXXXX 说明:将复杂特性细分为系统需求,陈述该功能的详细说明。 如:1.1.2.1 F01.FR01屏幕截图灰屏机制优化。

2.1.2.2F01.FR02 XXXXX 2.2 特性 F02 XXXX 内容构架同1.1,同样描述特性2的功能性需求 3性能需求 对照此表进行检查,在“相关特性”中简单标注符合条件的特性

腾讯PRD需求文档模板

腾讯QQ空间产品需求文档

修订记录:

目录 一、简介 (4) 1.1 目的 (4) 1.2 范围 (4) 二、用户角色描述 (4) 三、产品概述 (4) 3.1 目标 (4) 3.2 总体流程 (4) 3.3 功能摘要 (4) 四、产品特性 (5) 4.1 第一部分功能模块1 (5) 4.1.1 产品概述 (5) 4.1.2 产品结构(功能摘要) (5) 4.1.3 状态说明 (5) 4.1.4 特性说明 (5) 特性1:功能点1 (5) 特性2:功能点2 (6) 4.2 第二部分功能模块2 (6) 4.2.1 产品概述 (6) 4.2.2 产品结构(功能摘要) (6) 4.2.3 状态说明 (7) 4.2.4 特性说明 (7) 特性1:功能点1 (7) 特性2:功能点2 (7) 五、其它产品需求 (8) 5.1 性能需求 (8) 5.2 监控需求 (8) 5.3 兼容性需求 (8) 六、风险分析 (8) 七、相关文档 (8) 八、附件 (8)

一、简介 [产品需求说明书文档的简介应提供整个文档的概述。它应包括此产品需求说明书文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。] 1.1 目的 [阐明此产品需求说明书文档的目的,如: 本文档为“陌生视界v1.0.0”的产品需求文档,主要作为确认需求以及系统分析设计的依据。] 1.2 范围 [简要说明此产品需求说明书文档的范围、它的相关产品,以及受到此文档影响的任何其他事物。] 二、用户角色描述 三、产品概述 [此节高度概括产品的功能与介绍] 3.1 目标 [描述产品的目标] 3.2 总体流程 [描述产品的总体流程图] 3.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

从零开始-产品需求文档(PRD)撰写

1、写前准备(信息结构图) 在写PRD文档之前,我们需要先罗列出产品功能的信息内容,这一步是将想法逐渐清晰的第一步,也是帮助我们接下来规划功能的辅助信息,同时也可以辅助服务端技术人员创建数据库。因为这是第一步,所以我们不需要罗列的很详细,在之后的步骤里,我们会逐步改进和完善信息内容。 例如一篇文章的信息内容主要有:文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容,但是在之后的功能规划中逐渐更加细致的考虑时,可能会增加或者删减,因此第一步我们不用刻意的追求信息的全面。 罗列信息内容的方式有很多种,文本形式、思维导图形式等等都可以,最主要的是能够清晰易懂,我最常用的方法就是思维导图,因此我称这一步为信息结构图。 当我们初次接触产品需求文档时,首先会从网络上寻找产品需求文档模板,希望从中了解和学习具体的写作要求,但实际上,现在网络上绝大部分的PRD文档都是与实际工作不相符的,或者说是复杂的。 前几天一位从事产品类工作的朋友,发来一份他写的产品需求文档目录截图给我(下图),当时我就郁闷了,这些类目更像是MRD文档,而不是PRD文档了,因此我决定写几篇讲述写作PRD文档的文章,分享一些我关于PRD文档的见解和写作方法。

PRD是英文Product Requirement Document的缩写,中文的意思是产品需求文档,具体的名词介绍大家可以询问Google。PRD文档是基于BRD、MRD的延续文档,主要用于产品设计和开发使用,因此阅读这份文档的人群绝大多数是设计与技术人员。在这类人群中,设计师更多依赖于原型进行交互或视觉的设计,因此看这份文档的人就会偏向于技术人员。相对于技术人员,他们不太关注产品的商业需求和市场愿景,因为在进行产品讨论立项时,产品的定义就已经向参与设计和研发的人员宣讲过,因此技术人员更多的是关注界面、功能、交互、元素等等内容,因此PRD文档是一份详细的产品功能需求说明文档,是产品文档中最底层和最细致的文档。 PRD文档是一份没有闲话,直入主题的功能说明文档,因此我们在写作时,脑海里构思的是成品产品的界面功能的逻辑线框图。在写作这份文档前,我们需要先做一些准备,把BRD、MRD的相关需求消化并融合规划出产品的结构图。因为这些准备工作是属于思维类的,所以我推荐使用思维导图软件(MindManager)进行规划工作。 规划产品的第一步就是梳理出产品的信息结构,有了信息结构我们才能继续往下规划产品结构,并且信息结构是服务端技术人员创建数据库的依据,是数据结构的辅助文件。对于新产

腾讯QQ浏览器需求文档模版

需求文档名称 修订记录 目录 修订记录 (1) 目录 (1) 1前言 (2) 1.1需求来源 (2) 1.2名词解释 (2) 1.3参考文档 (2) 1.4整体流程/逻辑关系 (2) 2运营目标........................................................................................................ 错误!未定义书签。3特性.. (2) 3.1特性F01XXXX (2) 3.1.1特性所包含的功能 (2) 3.1.2功能性需求(Functional Requirements,FR) (2) 3.1.2.1F01.FR01 XXXXX (2) 3.1.2.2F01.FR02 XXXXX (3) 3.2特性F02XXXX (3) 4性能需求........................................................................................................ 错误!未定义书签。5国际化需求.................................................................................................... 错误!未定义书签。6附录................................................................................................................ 错误!未定义书签。

产品需求文档的写作(一) – 写前准备(信息结构图)

当我们初次接触产品需求文档时,首先会从网络上寻找产品需求文档模板,希望从中了解和学习具体的写作要求,但实际上,现在网络上绝大部分的PRD文档都是与实际工作不相符的,或者说是复杂的。 前几天一位从事产品类工作的朋友,发来一份他写的产品需求文档目录截图给我(下图),当时我就郁闷了,这些类目更像是MRD文档,而不是PRD文档了,因此我决定写几篇讲述写作PRD文档的文章,分享一些我关于PRD文档的见解和写作方法。 PRD是英文Product Requirement Document的缩写,中文的意思是产品需求文档,具体的名词介绍大家可以询问Google。PRD文档是基于BRD、MRD 的延续文档,主要用于产品设计和开发使用,因此阅读这份文档的人群绝大多数是设计与技术人员。在这类人群中,设计师更多依赖于原型进行交互或视觉的设计,因此看这份文档的人就会偏向于技术人员。相对于技术人员,他们不太关注产品的商业需求和市场愿景,因为在进行产品讨论立项时,产品的定义就已经向参与设计和研发的人员宣讲过,因此技术人员更多的是关注界面、功能、交互、元素等等内容,因此PRD文档是一份详细的产品功能需求说明文档,是产品文档中最底层和最细致的文档。 PRD文档是一份没有闲话,直入主题的功能说明文档,因此我们在写作时,脑海里构思的是成品产品的界面功能的逻辑线框图。在写作这份文档前,我们需要先做一些准备,把BRD、MRD的相关需求消化并融合规划出产品的结构图。因为这些准备工作是属于思维类的,所以我推荐使用思维导图软件(MindManager)进行规划工作。

规划产品的第一步就是梳理出产品的信息结构,有了信息结构我们才能继续往下规划产品结构,并且信息结构是服务端技术人员创建数据库的依据,是数据结构的辅助文件。对于新产品或者新功能,没有人能够比产品经理更加清楚所需要的信息内容了,因此第一步我们就需要先将这些信息罗列出来,形成结构化。(如下图) 这张图是以我的博客作为示例,在罗列信息结构时,我们更多的是考虑信息数据,因此在这一步,我们还不需要深入的考虑产品的界面与功能。信息结构的考虑有面向前端的,也有面向后端的,具体视产品类型而定。

产品需求文档(PRD)的写作方法

产品需求文档(PRD)的写作方法 无论我们做什么事都讲究方式方法,写产品需求文档(以下称PRD文档)也是如此,之前我通过五篇文章分享了自己写PRD文档的一些方法,而这一篇文章主要是对之前五篇文章进行整体的摘要介绍,帮助大家快速了解写作流程。 产品需求文档(PRD)的写作五篇章: 1、写前准备(信息结构图) 2、梳理需求(产品结构图和用户流程图) 3、原型设计(手绘原型,灰模原型,交互原型) 4、撰写文档(PRD文档) 5、用例文档(UML用例图、流程图)

1、写前准备(信息结构图): 在写PRD文档之前,我们需要先罗列出产品功能的信息内容,这一步是将想法逐渐清晰的第一步,也是帮助我们接下来规划功能的辅助信息,同时也可以辅助服务端技术人员创建数据库。因为这是第一步,所以我们不需要罗列的很详细,在之后的步骤里,我们会逐步改进和完善信息内容。 例如一篇文章的信息内容主要有:文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容,但是在之后的功能规划中逐渐更加细致的考虑时,可能会增加或者删减,因此第一步我们不用刻意的追求信息的全面。 罗列信息内容的方式有很多种,文本形式、思维导图形式等等都可以,最主要的是能够清晰易懂,我最常用的方法就是思维导图,因此我称这一步为信息结构图。 2、梳理需求(产品结构图和用户流程图): 当我们对产品的信息结构了解后,我们就需要规整脑海中的产品需求,让想法更加结构化,因此这一步是梳理产品的需求。我们首先要罗列出产品的频道及页面(产品结构图),其次再基于产品结构图梳理出频道及页面中的功能,并延伸构建出用户的操作流程(用户流程图)。 以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解,类似鸟瞰式的一目了然,也方便调整完善。

腾讯需求文档(模板)

XXX 修订记录 目录 修订记录 (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特性所包含的功能 2.1.2功能性需求(Functional Requirements,FR) 2.1.2.1F01.FR01 XXXXX 说明:将复杂特性细分为系统需求,陈述该功能的详细说明。 如:1.1.2.1 F01.FR01屏幕截图灰屏机制优化。

2.1.2.2F01.FR02 XXXXX 2.2 特性F02 XXXX 内容构架同1.1,同样描述特性2的功能性需求 3性能需求 对照此表进行检查,在“相关特性”中简单标注符合条件的特性

产品需求文档模板

[本文给出产品需求文档的一个模板,实际使用时可根据具体情况选择其中的章节进行撰写,也可进行调整。例如: 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涉众 [在下表中列出该产品所涉及的所有利益方,每个利益方占一行。例如一个网站广告系统的涉众主要为“广告主”、“网站用户”和“网站后台管理人员”]

QQ需求分析

企 业 M Y Q Q 项 目 需 求 文 档 文档建立日期:2010.7.15 创建人:周丽莎 目录

一、...................................................................... 项目概述 错误!未指定书签。 二、...................................................................... 开发架构 错误!未指定书签。 三、.................................................................... 功能框架图 错误!未指定书签。 四、...................................................... 各功能模块的示意图和描述 错误!未指定书签。 五、.................................................................... 数据库设计 错误!未指定书签。 六、........................................................ 开发进度表(9天时间) 错误!未指定书签。 一、项目概述 通过使用c#,设计一类似QQ的聊天工具——MYQQ,它主要包括以下几个功能:登录,注册,查找、添加,聊天、个人信息,还有找回密码、查找聊天记录等功能。 二、开发架构 1、系统架构 三层架构 2、安装需求 Framework2.0 3、开发环境 Microsoftvisualstudio2008 MicrosoftSQLserver2005 三、功能框架图 1.系统功能的结构图

产品需求说明书模板(腾讯)

产品需求说明书模板

修订记录:

目录 一、简介 (4) 1、目的 (4) 2、范围 (4) 二、用户角色描述 (4) 三、产品概述 (4) 1、目标 (4) 2、总体流程 (4) 3、功能摘要 (4) 四、产品特性 (5) 1、第一部分功能模块1 (5) 1.1 产品概述 (5) 1.2 产品结构(功能摘要) (5) 1.3 状态说明 (5) 1.4 特性说明 (6) 1.4.1 特性1:功能点1 (6) 1.4.2 特性2:功能点2 (9) 2、第二部分功能模块2 (9) 2.1 产品概述 (9) 2.2 产品结构(功能摘要) (9) 2.3 状态说明 (9) 2.4 特性说明 (9) 2.4.1 特性1:功能点1 (9) 2.4.2 特性2:功能点2 (10) 五、其它产品需求 (10) 1、性能需求 (10) 2、监控需求 (11) 3、兼容性需求 (11) 六、风险分析 (11) 七、相关文档 (11) 八、附件 (11)

一、简介 [产品需求说明书文档的简介应提供整个文档的概述。它应包括此产品需求说明书文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。] 1、目的 [阐明此产品需求说明书文档的目的,如: 本文档为“*******”的产品需求文档,主要作为确认需求以及系统分析设计的依据。] 2、范围 [简要说明此产品需求说明书文档的范围、它的相关产品,以及受到此文档影响的任何其他事物。] 二、用户角色描述 三、产品概述 [此节高度概括产品的功能与介绍] 1、目标 [描述产品的目标] 2、总体流程 [描述产品的总体流程图] 3、功能摘要 [简要描述产品的功能点和每个功能点的优先级,参考格式如下]

产品需求文档PRD的写作方法

. (PRD)的写作方法产品需求文档 也是如文档)以下称无论我们做什么事都讲究方式方法,写产品需求文档(PRD文档的一些方法,而这一篇文章主此,之前我通过五篇文章分享了自己写PRD 要是对之前五篇文章进行整体的摘要介绍,帮助大家快速了解写作流程。产品需求文档(PRD)的写作五篇章:) 1、写前准备(信息结构图) 2、梳理需求(产品结构图和用户流程图) 灰模原型,交互原型, 3、原型设计(手绘原型) 、撰写文档(PRD文档4) (UML用例图、流程图5、用例文档 1、写前准备(信息结构图): . . 文档之前,我们需要先罗列出产品功能的信息内容,这一步是将PRD在写同时也可以想法逐渐清晰的第一步,也是帮助我们接下来规划功能的辅助信息,所以我们不需要罗列的很详辅助服务端技术人员创建数据库。因为这是第一步,细,在之后的步骤里,我们会逐步改进和完善信息内容。例如一篇文章的信息内容主要有:文章标题、文章正文、文章作者、发布时但是在之后的功能规划中逐所属分类。初始的功能需求只有这些信息内容,间、因此第一步我们不用刻意的追求信渐更加细致的考虑时,可能会增加或者删减,息的全面。罗列信息内容的方式有很多种,文本形式、思维导图形式等等都可以,最主因此我称这一步为信息结我最常用的方法就是思维导图,要的是能够清晰易懂,构图。:产品结构图

和用户流程图)2、梳理需求(当我们对产品的信息结构了解后,我们就需要规整脑海中的产品需求,让想我们首先要罗列出产品的频道及法更加结构化,因此这一步是梳理产品的需求。,其次再基于产品结构图梳理出频道及页面中的功能,并延伸产品结构图)页面( 。(用户流程图)构建出用户的操作流程以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解,类似鸟瞰式的一目了然,也方便调整完善。 ),,(3、原型设计手绘原型灰模原型交互原型:. . 当我们逐渐清晰了产品的需求后,并梳理了产品的各个频道及页面,那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。推演和讨论方首先我建议通过手绘的形式快速在草纸上绘制出产品的原型,移当有一定的进展之后,我们再通过软件工具进行更深入的设计。案的可行性,动产品可以考虑灰模原型,网站产品可以考虑交互原型,对于这两种原型方式,无论是移动产品还是网站产品都可以使用,具体取得于你的个人习惯和团队要求。对于产品经理来说,原型设计是为了帮助我们细致的考虑方案,并论证方案抽象的语言描述导致听众理解困难和同时也是为了避免产品宣讲时,的可行性,理解偏差。:文档)(PRD4、撰写文档当我们通过以上三个大的步骤之后,我们就已经非常清晰产品的需求了,一很多产品经理文档的目的(PRD般情况下,通过原型加描述的方式就已经完成了PRD)。直接使用Axure制作文档有特定的规范标准,PRD当然也会有一些个人或团队的要求不一样,对文档的目的都是PRD这类情况可能是需要存档归类。无论什么样的规范标准,PRD相近的,因此功能描述的方式也是相似的,

产品需求文档(腾讯格式)

产品需求文档(腾讯格式) 目录 修订记录 (1) 目录 (2) 1 前言 (3) 1.1,名词解释 (3) 1.2,参考文档 (3) 1.3,整体流程/逻辑关系 (3) 2,产品特性 (4) 2.1,特性F01**** (5) 2.1.1特性包含的功能 (3) 2.1.2功能行需求 (3) 2.1.2.1 F01.FR01**** (3) 2.1.2.2 F01.FR02**** (3) 2.2 特性F02**** (5) 3 性能需求 (1) 4 国际化需求 (4) 5 附录 (4)

1前言 1.1名词解释 说明:列出本文档中所用到的专门属于的定义和缩略语的全称和解释 1.2参考文档 说明:列出本文档的所有参考文档 1.3整体流程/逻辑关系 说明:说明项目本份需求文档描述的产品或组件的总体流程图或逻辑关系图 2特性 2.1特性F01*** 说明:陈述该特性的简要说明,F指特性,m为1—n的自然数,Fmm为该特性编号例如:1.1特性F03 截图功能优化 2.1.1特性所包含的功能 简要描述:简要描述此特性包含的功能点及优先级 1,屏幕截图灰屏机制优化(高) 2.1.2功能性需求 2.1.2.1 F01.FR01**** 说明:将复杂特性细分为系统需求,陈述该功能的详细说明 如:1.1.2.1F01.FR01屏幕截图灰屏机制优化 用户场景:描述此需求的使用场景 功能描述:简要描述此需求要实现的功能 处理流程:详细描述此需求的处理步骤,以及相关的交互说明 1, 2, 补充说明:特别或需求补充说明的地方 2.1.2.2F01.FR02**** 用户场景 功能描述 处理流程 补充说明 2.2特性F02**** 内容构架同1.1,同样描述特性2的功能性需求 3性能需求 对照此表进行检查,在“相关特性”中简单标注符合条件的特性

腾讯旗下产品分析

腾讯公司旗下产品分析 腾讯公司从当初的一个即时聊天工具开始发展到现在的以QQ为平台的腾讯商业帝国,这其中必定有他独特的运营理念所支持,现在我们可以了解一下关于腾讯旗下的产品组合。 很多人都说腾讯公司就是靠抄袭模仿发展起来的,但是从实际看来不是这么回事,腾讯,起身比较早!旗下有4亿多QQ用户群仔细看看,耐心看游戏到底是谁的?例如穿越火线,那只是腾讯代理罢了,还有音速和劲舞有什么关系?说模仿超级跑跑还差不多,可超级跑跑不是在音速之后么?再说QQ自身的庞大用户数量已经超越了普通网游的人数,还有点亮图标这一功能,腾讯只是在引进的基础上加以改进,这得益于腾讯公司的独特的运营理念,他们能够看到市场的机遇,能够抓住机遇,加以改进投入市场。 从产品结构来看,腾讯公司有五大工作室,这五大工作室分别负责腾讯旗下不同产品的研发和服务,腾讯公司在清晰的分析当前大陆市场后,通过调研可以确定其目标市场是广大青年爱好者,随着科技的不断进步,网络的不断发展,腾讯公司意识到网络游戏需要有众多的网络玩家才能为持续下去,而在当今的网络世界中网络游戏众多,当一个玩家要玩多种网游时是需要不同的账号密码的,而腾讯公司在产品中就发现一个机会,在腾讯旗下的网游产品中全部实施一号通,即有一个QQ号即可畅游腾讯旗下所有游戏,这样腾讯不仅用一个号码绑住一个客户也为其所有产品绑住了用户。 腾讯公司的市场定位是游戏娱乐方面,所以他旗下有五大工作室和三大产品部,不断紧跟市场发展,或许很多人都认为腾讯的商业运作行为很“卑鄙”,但是从商业角度来看,这是可以理解的,说的俗套一点腾讯在抄袭模仿上面是专家,但是在如今的商业社会只要合法就是可行的,何况抄袭是需要技术的,腾讯在引进技术的同时也在加强技术的改进,腾讯在市场定位方面已经做得很好。能够跟上游戏娱乐市场的最近动态发展,而且腾讯公司在利用即时通讯这一强项目牢牢的抓住其顾客群体,是非常值得人佩服的。 综上所述,腾讯公司的产品架构是基于其公司最核心最有实力的QQ基础上,利用其广大的客户群,走娱乐游戏行业的互联网道路,其运营理念非常值得学习,相对于MSN 可以说是“青出于蓝而胜于蓝”,在游戏方面通过借鉴行业优秀经验,结合自身游戏产品特色,对组织架构进行调整的产物,从而也开始了腾讯游戏发展的新纪元。同时腾讯方面也更加注重团队的效应,互动娱乐业务系统则是以网络游戏产品为主,是腾讯的主要经济支柱之一。这里,聚集着上千位热爱着游戏的达人,这里,是实现游戏梦想的天国。公司注重自主研发与产品代理相结合的战略,坚持走精品网络游戏的道路,对于游戏人才更是惜护有加,对于员工的创新理念与创作,均会给予极大的鼓励和肯定。腾讯公司抓住了客户的心理,如果说游戏世界是满足你虚拟梦想的支撑,那么互娱游戏团队的精诚合作与携手共进,更是你踏实的稳定靠山,它会让你充分体验到生活的乐趣,充分挖掘自身的潜能,精彩人生将从这里跳跃式前进了! 10营销与策划 黄顺超

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)的写作方法

产品需求文档(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文档中的重要辅助文档“用例文档”。

腾讯大王卡市场需求文档

产品背景 传统卡遇到的问题:资费比较高,流量不够用,信号不是很好,正是由于传统卡的独家垄断,导致整个通讯行业难以被标准化,属于垄断的竞争状态, 随着通讯运营商的发展,卡的资费越来越贴近人们所接受的能力围,随着国家规章制度的完善,以“标准化,产业化”的理念,将通讯行业不规的现状,通过一系列的规章制度给完善好,联通和腾讯合作开发了一款卡“腾讯大王卡”,解决用户流量问题,让玩游戏乐在其中。 产品战略战术 产品战略和定位 战略:免费流量卡领导者 定位:新一代年轻人的最爱 用户描述 中低端收入的新一代年轻人(15-30)群体,由于他们已经对互联网非常熟悉,接受度相对比较高,对接受新鲜事物的能力也很强,随之对流

量的需求也很大,再加上目标用户群体都有一个最大的特征:喜欢玩王者荣耀,喜欢看腾讯视频,所以可以很好的带动大王卡的市场,通过巨大的一个市场,能够为用户打造一个低资费,高体验的游戏卡。 当代人最基本的卡需求就是能够打,有足够的流量,在用得到的场景下能够随意使用流量。 1.卡套餐资费高 2.不清楚通讯商的套餐类型, 3.玩游戏时所消耗的流量很多, 4.看电影时所消耗的流量很多 5.使用腾讯的软件很频繁 面对以上的需求痛点,大部分用户是无奈的,那么我们可以提供一种解决方案:腾讯大王卡,由联通和腾讯合作开发的一款卡,玩腾讯的游戏是不需要消耗流量,额外消耗的流量是1元500兆,拨打全国:0.1元一分钟,接听全免费,并且售价50元一的腾讯大王卡里面所含的金额有120元,相当于你没花钱买卡,并且我们还送你70元的话费,超值服务尽在腾讯大王卡。 场景一:之前:玩游戏时要消耗掉100兆流量,在打下去这个月的流量都不够用了, 之后:随时随地,想玩就玩,不会担心流量的问题 场景二:之前:普通卡资费:50元一卡需要花费50元 之后:腾讯大王卡资费:只需要花费50元,就可以买到一面值120元话费的卡 场景三:之前:普通卡的套餐类型记不住

产品需求文档的写作方法

无论我们做什么事都讲究方式方法,写产品需求文档(以下称PRD文档)也是如此,之前我通过五篇文章分享了自己写PRD文档的一些方法,而这一篇文章主要是对之前五篇文章进行整体的摘要介绍,帮助大家快速了解写作流程。 产品需求文档(PRD)的写作五篇章: 1、写前准备(信息结构图) 2、梳理需求(产品结构图和用户流程图) 3、原型设计(手绘原型,灰模原型,交互原型) 4、撰写文档(PRD文档) 5、用例文档(UML用例图、流程图) 1、写前准备(信息结构图): 在写PRD文档之前,我们需要先罗列出产品功能的信息内容,这一步是将想法逐渐清晰的第一步,也是帮助我们接下来规划功能的辅助信息,同时也可以辅助服务端技术人员创建数据库。因为这是第一步,所以我们不需要罗列的很详细,在之后的步骤里,我们会逐步改进和完善信息内容。 例如一篇文章的信息内容主要有:文章标题、文章正文、文章作者、发布时间、所属分类。初始的功能需求只有这些信息内容,但是在之后的功能规划中逐渐更加细致的考虑时,可能会增加或者删减,因此第一步我们不用刻意的追求信息的全面。 罗列信息内容的方式有很多种,文本形式、思维导图形式等等都可以,最主要的是能够清晰易懂,我最常用的方法就是思维导图,因此我称这一步为信息结构图。 2、梳理需求(产品结构图和用户流程图): 当我们对产品的信息结构了解后,我们就需要规整脑海中的产品需求,让想法更加结构化,因此这一步是梳理产品的需求。我们首先要罗列出产品的频道及页面(产品结构图),其次再基于产品结构图梳理出频道及页面中的功能,并延伸构建出用户的操作流程(用户流程图)。 以上两步是为了让我们在撰写产品需求文档之前能够对产品有一个全面的了解,类似鸟瞰式的一目了然,也方便调整完善。

QQ产品设计需求文档

手机QQ2008(Java)Beta2 版本产品需求说明书V1.4 腾讯科技(深圳)有限公司

修订记录 日期修订版本修改描述作者审核 Kennyfang 2008-05-07 V1.0 制定beta2功能点计划Fansonfan、 herkinghe、 wingli 2008-06-05 V1.1 修改QQ等级、帐户设置流程等Fansonfan、 herkinghe 2008-7-31 V1.2 增加4.6.3.9 wingli 2008-8-7 V1.3 增加4.6.3.10到4.6.3.13 wingli Fansonfan 2008-10-6 V1.4 各个迭代需求梳理整合成正式 文档:《手机QQ2008Beta2(Java) 版本产品需求说明书》

目录 1引言 (4) 1.1文档目的和范围 (4) 1.2参考文献 (4) 1.3术语表 (4) 2总体描述 (4) 2.1产品描述及背景 (4) 2.2用户类和特征 (4) 2.3业务目标 (4) 2.4设计和实现上的约束 (5) 3功能结构 (5) 4特性 (5) 4.1特性F001超级QQ功能及展现 (5) 4.1.1优先级高 (5) 4.1.2特性描述 (5) 4.1.3功能性需求 (5) 4.2特性F002聊天相关 (16) 4.2.1优先级高 (16) 4.2.2特性描述 (16) 4.2.3功能性需求 (16) 4.3特性F003手机Q ZONE (32) 4.3.1优先级高 (32) 4.3.2特性描述 (32) 4.3.3功能性需求 (32) 4.4特性F004帐户设置 (34) 4.4.1优先级高 (34) 4.4.2特性描述 (34) 4.4.3功能性需求 (34) 4.5特性F005广告系统 (43) 4.5.1优先级高 (43) 4.5.2特性描述 (43) 4.5.3功能性需求 (43) 4.6特性F006浏览器 (47) 4.6.1优先级高 (47) 4.6.2特性描述 (47) 4.6.3功能性需求 (47) 4.6.4性能需求 (52)

产品需求文档

产品需求文档(PRD)介绍 产品设计是一个由抽象的概念到具体形象化的处理过程,通过文字或图像等方式将我们规划的产品需求展现出来。它将产品的某种目的或需求转换为一个具体的物理或工具的过程,把一种计划、规划设想、问题解决的方法,通过具体的操作,以理想的形式表达出来。 由于产品设计阶段要全面确定整个产品策略、外观、结构、功能,从而确定整个产品系统的布局,因而,产品设计的意义重大,具有“牵一发而动全局”的重要意义。如果一个产品的设计缺乏具体形象的表述,那么研发时就将耗费大量资源和劳动力来调整需求。相反,好的产品设计,不仅表现在功能上的优越性,而且便于执行时理解,从而使产品的研发效率得以增强。 1、产品需求文档介绍 产品设计的最终表述的形式被称为产品需求文档,业界常常称呼为PRD文档, 这是英文Product Requirement Document的缩写。产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式,主要用于产品界面设计和研发使用。 PRD文档是基于BRD、MRD的延续文档,主要是一份给执行层面的工作人员阅读的文档,这部分人群绝大多数是设计与技术人员(包括测试工程师)。在这类人群中,设计师更多依赖于产品原型进行交互或视觉的设计,因此看这份文档的人主要是技术人员。相对于技术人员,他们不太关注产品的商业需求和市场愿景,因为在进行产品讨论立项时,产品的定义就已经向参与设计和研发的人员宣讲过,因此技术人员更多的是关注界面、功能、交互、元素等等内容,因此产品需求文档是一份详细的产品功能需求说明文档,是产品文档中最底层和最细致的文档。

因为阅读人类的因素,所以产品需求文档是一份没有闲话,直入主题的功能说明文档。并且产品需求文档是没有标准规范的,也没有统一的模板,每个公司都不一样和每个人也不一样,这个取决于个人习惯和团队要求。虽然产品需求文档没有明确的规范,但是目的都是一样的,必须能够明确产品的功能需求,便执行人员理解任务要求。 2、产品需求文档写作 产品需求文档是产品经过规划和设计之后的最终执行文档,因此这份文档的质量好坏直接影响到执行部门是否能够明确产品的功能和性能。 2.1、罗列信息(信息结构图) 在写产品需求文档之前,我们需要先罗列出产品功能的信息内容,这一步是将想法逐渐清晰的第一步,也是帮助我们接下来设计功能的辅助信息,同时也可以辅助服务端技术人员创建数据库。因为这是第一步,所以我们不需要罗列的很详细,在之后的步骤里,我们会逐步改进和完善信息内容。 罗列信息内容的方式有很多种,文本形式、思维导图形式等等都可以,最主要的是能够清晰易懂,我最常用的方法就是使用思维导图软件(MindManager)罗列成结构图,因此我称这一步为“信息结构图”。 上图是一张以Blog系统为示例的信息结构图。信息结构图是一种接近数据库结构的图表,在罗列信息结构时,更多的是考虑信息数据,但是他并不是真正意义的数据库结构。信息结构图是提供给产品经理自己梳理信息内容的结构图,也是方便产品经理和服务端技术人员沟通数据结构的参考图,技术人员会根据这张图表的内容再结合产品原型或需求文档,然后规划和设计出真正意义上的数据库结构。

相关文档
最新文档