prd模板_prd 模板 下载 - CSDN
  • 通用产品需求文档(PRD)模板(附完整案例),产品需求说明书
  • 产品经理、需求工程师必备的参考文档模板。很多不重视文档的开发过程,必定会踩很多坑。
  • PRD文档标准模板.pdf

    2020-07-21 09:59:05
    需求说明书标准模板,WEB开发参照。这份PRD虽然内容很全面通用,但是希望大家给我提建议,然后可以不断迭代。
  • 模板是笔者所在团队使用的一套模板,通过一段时间沉淀所得,主要阅读对象为:研发,公司PMO,运维,运营团队。侧重研发。 笔者团队简介:一个项目或产品大概15人左右,多个项目和产品线并行。单个项目团队主要...

    写在前面:个人公众号:18岁fantasy。欢迎关注。

    本模板是笔者所在团队使用的一套模板,通过一段时间沉淀所得,主要阅读对象为:研发,公司PMO,运维,运营团队。侧重研发。

    笔者团队简介:一个项目或产品大概15人左右,多个项目和产品线并行。单个项目团队主要成员有产品经理(也就是我),1产品助理,1美工,2测试,其他为研发,运维和运营都为职能部门借调。

    此模板并非行业通用模板,可选择性参考。谢谢。

    文档中使用到工具:word2017,axure8,viso2013,。

    以下为具体内容,内容去掉了所有正文,添加了说明。文章末尾提供下载。

    目录结构

    功能结构图

    文档结构图

    整个结构由以下部分组成:

    1、文档介绍

    主要描述文档的术语定义,参与本需求确认的相关干系人及确认历史。

    干系人

     

    2、产品概述

    描述产品背景,产品业务目标,此部分主要面向领导层和pmo以及运营团队。

    3、需求分析

         1)用户分析。分析系统面向的用户及不同的使用场景(也就是告诉都谁来用这个系统);

         2)角色分析。分析不同角色具备的系统功能);

         3)业务指标。分析系统上线后要达到的业务指标,通常面向运营团队;

         4)主要业务流程。描述系统的主要业务流程,用于干系人讨论决策;

         5)需求池分析。分析目前需求整体情况,按需求来源,优先级进行统计阐述(详细需求引导到需求管理软件,如TAPD,禅道,我所在团队目前用TAPD进行需求和进度管理,采用的原因主要是包含功能比较全面:如:需求,迭代,故事墙,wiki,文档管理等)如下图(与本文档无关):

    需求管理软件

     

    6,功能规划。根据优先级和公司资源规划每个迭代的所需完成的功能及里程碑事件。

    从预期目标上分析系统各迭代需包含的功能和计划。

    (一般将参会人引导到部门需求管理软件)。文档中通过脑图画出结构讲解各个迭代的结构(迭代里面要分析规划分析),如果软件需求不多可在此用表格详细列出需求列表。

    4、需求设计

    也可叫功能设计,这里正是面向研发,进行一下内容详细阐述:

    1、整体功能和优先级

    描述功能设计结构、需求映射关系、优先级。

    迭代优先级

    2、功能结构图

    功能整体结构,一般用viso画出。

    3.菜单结构图

    列出菜单设计结构。一般用axure原型列出。可根据团队结构,提供灰度原型或者高保真原型。

    菜单设计

    3、功能设计

    这个章节具体描述各个功能的设计。包含:原型,原型标注、用户场景及操作流程

    功能设计

     

    其中:

    1)原型标注:这里面我们直接会给出原型的标注,数据说明等。有的大厂这一部分是单独的标注工具管理,如:pxcook软件。

    2)用户场景及使用流程:描述此功能的使用场景,用户操作流程,一般包含和其他功能的交互。实例如下(保密期间去除了实际内容):

    流程图

     

    3、业务规则。这里面要给出业务规则(校验规则),如前置条件、输入规则、超时规则、阈值要求等。

    4、接口设计

    其实这部分按照规范已经不在属于PRD的范畴了。但是我们主要想用它来说明和第三方合作伙伴的接口规则。如:调用频次说明,业务结算规则说明、调用方式说明等,但不包含协议具体内容。

    接口设计

     

    5、非功能需求

    主要包含:

    性能需求

    1、用户规模预测分析

    分析上线后可能的用户数和并发数,

    在线数和并发量要求(这里列出要求的在线数和并发数支撑指标)。

    2、吞吐量(TPS)

    每秒钟要处理的事务数,以及在不同级别的并发下平均响应时间规定。

    稳定性需求

    要求不宕机的时间,如7*24小、早3:00~完11点。

    安全性需求

    要求数据传输的加密机制。是否采用证书,是否统一认证等。

    兼容性需求

    分服务端和客户端,如服务端的操作系统是windows,linux等,客户端需要兼容的浏览器规定。App需要兼容的ios或者android的版本和尺寸。

    维护和升级规定

    规定系统升级时间、规定升级过程的规范性(如是否可让用户感觉到重新登录等)。

    6、项目管理

    这里的项目管理不是指项目经理角色所面对的全周期项目管理。主要包含以下部分:

    1、进度安排。主要描述从需求发起,到上线各个部门及干系人需要定时输出的成果。用于从一开始就确定好项目协同的资源。

    2、风险和应对措施分析。

    本次系统上线或升级可能带来的风险和应对策略,主要是面向用户。包含:

    风险描述:描述风险具体内容。

    规避策略:描述建议通过什么手段规避风险,一般都是投入更多的资源等。

    7、附件

    主要包含参考的文献,以及设计规范内容(一般规定UI规范也可单独成文管理)。

    ~完~

    文档下载

    关注公众号,回复”p002“,下载完整文档。

    展开全文
  • 人人圆桌 人人圆桌是在群讨论的基础上,通过筛选人员、限制讨论时间的一种讨论模式,以达到帮助新人成长、发散思路和学习交流的目的;而且因圆桌讨论的特殊性,也能在讨论中暴露出一些工作和思维上的问题,避免工作...

    人人圆桌

    人人圆桌是在群讨论的基础上,通过筛选人员、限制讨论时间的一种讨论模式,以达到帮助新人成长、发散思路和学习交流的目的;而且因圆桌讨论的特殊性,也能在讨论中暴露出一些工作和思维上的问题,避免工作时再次犯错。

    规则介绍

    人人圆桌开启时间为每月第二个周四晚上20:30,历时60分钟。圆桌主题确定后会提前在众多报名者中,选择10名合适的成员单独建群讨论。

    圆桌主题则在圆桌招募初期即公布,成员在获知主题内容后都有思考、收集资料的时间,但不允许私下讨论。

    圆桌时间仅有一个小时,无论是否得出结果都必须结束。因而对参与者的思维能力、话题把控能力、沟通能力、时间管理等都是一大挑战。

    本期话题

    对于产品经理来说最重要的三个需求文档是商业需求文档、市场需求文档和产品需求文档,而关于文档的模板资料,质量却参差不齐。本次讨论选取产品需求文档作为讨论的话题,让大家在圆桌讨论中分享各位关于产品需求文档写作思路的干货。

    任务目标

    针对一个工具类App应用(以zaker为例),设计一个合理、可用、完整的产品需求文档模板。

    圆桌记录

    2014年11月13日晚8点30分,经历了严格筛选的产品老鸟们开始了为期一小时的思维碰撞,力求解决“产品需求文档到底该怎么写“这一终极难题。

    首先大家一致确认了PRD的重要性,积极的Phoenix抛出了一个可供大家讨论的模版。


    经过大家确认,一致认为效益成本分析是MRD中已经确认的内容,不应该在PRD中讨论,所以去掉了效益成本分析这一块。

    接下来按顺序分析

    1.概述

    关于概述大家都有不同的想法

    Phoenix提出概述应该包括名词说明;产品概述及目标;产品roadmap;产品风险,节奏提出既然是概述肯定要概括的说明产品的背景;产品的目标;产品的基本介绍等,基于经验大家又发现需要对数据的进行部分说明增添了数据字典的模块,需要对PRD的阅读对象进行分工定义,增添了文档阅读对象。

    发散思维的各种讨论后,讲概述确定为

    1.1产品概述及目标----包括背景介绍和产品目的

    1.2名词解释----声明文档中出现的名词含义

    1.3数据词典----介绍本产品中数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等。

    1.4文档阅读对象----声明本文档输出的阅读对象和注意事项

    确认了概述时已经时间用去三分之一,各大神明显觉得时间过得好快。。。所以接下来的讨论加快了速度,快速的确认接下来主要讨论的内容:产品描述和功能描述。

     2.产品描述

    讨论完概述后,大家一致认为使用者需求这个词语容易造成歧义且范围过窄,所以将名称改为了产品描述。

    产品描述章节介绍了产品的整体逻辑流程,概括性的描述产品需求、产品版本规划、产品整体的框架结构以及功能列表。产品整体流程与产品框架都需要使用相应的图表展现方式

    产品描述经过确认包括

    2.1产品整体流程----展示产品框架图和用户流程图。

    2.2产品需求描述----描述产品核心功能,解决哪些情景下的哪些需求。

    2.3产品版本规划----叙述产品版本迭代计划,版本号、主要模块、功能点、计划开发时间、计划结束时间、备注。

    2.4产品框架----展示页面层级及备注信息

    2.5功能列表----展示产品功能名称、对应模块、功能说明、备注等信息。

    3.功能描述

    功能需求章节需详细描述产品所涉及的各个功能点。将整体框架拆成数个独立的功能点,分别描述每个功能点的逻辑流程图、界面、字段说明以及业务说明。统一采用usercase方式进行描述。

    这块其实是pm比较熟悉的部分,所以基本上是大神们毫无歧义的就敲定了如下内容:

    3.1流程图

    3.2界面

    3.3字段说明(包括数据字典)

    3.4业务说明(usercase)

    此时 最初的PRD框架已经被细化为一个 有细化分支的 详细框架,如下


    此时时间已经过去四分之三,开始讨论非功能需求、附录及部分大家没有之前想到的东西。

    比较重要的是非功能需求和上下线需求及后续运营计划。

    4.非功能需求

    关于非功能需求,大家的考虑又开始出现分歧,主要是由于各公司的定义不同,造成内容不同的差异化,总结了下大家提及到的是安全、可用性、伸缩性、数据统计、易用性、接口需求,通过沟通消除各公司的语义差别和部分理解偏差,最后提供了一个可供参考的、比较合适的非功能需求内容。

    4.1安全需求

    4.2统计需求

    4.3性能需求

    4.4可用性需求

    此时已经接近尾声,大家大致讨论了下上下线需求的内容和运营计划该写的方向,加上其他声明的附录,产出了文档。

    最后的成型模版框架为:


    文档模板戳这里:百度盘 http://pan.baidu.com/s/1dDnPDWP

    写在最后:

    本次圆桌在筛选人员上进行了十分严格的人员把控,力求选取工作一线上经验丰富的产品人员,通过圆桌讨论的方式将接触到的文档进行还原与输出,大家在讨论中也表现出了经验赋予产品经理的睿智,和产品经理应有的自检自查,高效沟通的素质。一小时的讨论过程是对自己经验的总结、考验,也希望产出的模板在以后的实际工作中能给大家带来参考和指引。

    展开全文
  • 腾讯公司的PRD模板

    千次下载 热门讨论 2020-07-30 23:32:22
    腾讯的PRD文档模板,挺不错的,有很多干货
  • PRD(Product Requirement Document,产品需求文档), 这对于任何一个产品经理来说都不会陌生的一个文档, 一个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中的。

    一个产品经理需要考虑如何与其它部门之间的沟通合作,

    文档很大一部分的功能是提醒你要做的工作,同时不断补充将要面临的工作。

     

    5、 概述

    概述就是总结,它包括的点有:

    名词说明、

    产品概述及目标、

    产品roadmap、

    产品风险。

     

    名词说明:名称、说明。

    名称就是对文档中会出现的比较新的名称,说明则是对这些名称进行解释。
    产品概述及目标:解释说明该产品是干什么的,为什么需要这样的产品。

    同时产品想要达到什么样的目标。产品概述及目标就是对产品核心功能讲解,

    同时希望可以达到的期望。
    产品roadmap:产品分期目标,阶段描述,以及时间点的确定,

    产品是个不断演进的过程,很多时间一期产品只完成了产品70%的功能,

    二期才会继续去完 善剩下的30%,同时有可能会推翻了重新推出第二版。

    产品roadmap并不及着全部规划好所有的阶段目标,

    而是更多的通过维护来保持产品的更新和迭代。
    产品风险:描述产品可能存在的风险,比如商务谈判的风险,外部合作的风险,

    不当使用的风险等等。风险级别为高中低。

     

    6、 使用者需求

    使用者需求一般只是需求描述。

    需求描述有以下几项内容:

    目标客户、需求描述、场景描述、优先级。

    目标客户:即为产品的最终用户,确定产品的最终使用者。
    需求描述:是对目标客户的需求描述,表达用户最需要的是什么,找到用户的最根本需求。
    场景描述:产品在哪种情况下会被用户使用,就是用户场景模拟。
    优先级:是指用户对于当前产品功能需求的优先级,哪些是用户最想要的功能优先级则排前。

     

     

    7、 可选方案

    列出所有可以选择的达到该产品目标的方案要点(主要思路),

    给各方案适当的评价,并推荐最优方案。

    你在做这个产品规划时一定有很多的备选方案,别放弃这些方案,

    永远没有过时的idea,只有最适合时机的idea。

    所以可以写出几个可选方案,或许是你下期产品改版一个方向。

     

    8、效益成本分析

    产品经理是个全才,在这点上得到了体验。

    产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。

    一般的效益成本分析包括三个方面:

    效益预测、

    产品技术中心成本、

    非产品技术中心支持成本。

    效益预测:是指提供在各种产品环境中的效益预测,并标明主要的变量及假设,

    最好能包含现在和过去的效益数据。

    如网站的PV值,软件的使用数都是效益预测数据。
    产品技术中心成本:是指设计及部署此产品的产品技术中心所需的资源需求,

    包括人力成本,软硬件支出等。

    很大时候这份成本需要由项目经理来协助,

    需要有什么样的人才加入产品中需与人力协助。
    非产品技术中心支持成本:产品不是只有产品组完成的,同样需要其它部门的配合与协助。

    比如:需要客服部投入多少的资源用于该产品的服务,

    需要运营部投入多少的资源运营该产品。

     

    8、 功能需求

    功能需求一般是由四部分组成,

    功能总览、功能详情、整合需求、BETA测试需求。

    8.1 功能总览:

    一般包括二个部分,

    一个是流程图,

    一个是功能表。

    流程图:是对产品的整体走向的流程的规划,流程图是用来对产品整体功能的梳理。

    所以在做产品前建议所有的产品经理先梳理一下产品流程。

    功能表:是将流程图文字化,同时将列出产品的功能点。

    8.2 功能详情

    这是所有的产品功能的描述和规划。

    包括以下内容:
    简要说明:告诉此功能主要干什么的。
    业务规则:每上产品在使用时都有自己的规则,

    而产品的业务规则则是将产品的流程细化。

    个人建议将这个功能的业务规则,包括一些细节,如排版形式、

    日期显示方式全定好,这样方便其它人员的沟通和理解。
    界面原型:产品经理在这时做的原型界面只是显示的框架,

    别细化,这样会给交互和UI造成错觉。

    只需做一个简单的界面即可,更多的时候只是个框架图。
    执行者:产品使用者。
    前置条件:具体的操作。
    后置条件:操作后的展示。在UC(user case)中后置条件又是另一种情况,

    所以对于建议在PRD中的前置条件和后置条件结果合起来。
    主流程:把主流放在最后是有道理的,结合上面所说的,做出主流程说明。

    将此功能的流程走向做个分点说明。

     

    8.3 整合需求

    产品经理很重要的一个能力就是体现在产品整合能力上,

    利用公司现有的资源或外部资源(合作公司等)实现产品功能需求的整合。

    实现功能贯穿的同时,更多的如何在新产品上实现功能的拓展来辅助核心功能。

     

    8.4 BETA测试需求

    很多产品都有BETA版本放出,为了就是收求意见和一些性能测试。

    这部份内容不是必须的,但现在很多产品已经开始先推出BETA版本再推出正式版,

    当然也可以通过升级来解决。

    所以BETA测试需求并不是一定需要的。

    如果有BETA测试需求,则需写出BETA版测试的要求和期望达到的目标要求。

     

    9、 非功能性需求

    都说产品经理是全才,在这点上得到彻底的体现。

    很多产品经理在这点上忽视了,但很多方面是用到的,只是在产品过程中弱化了。

    一般情况下非功能性需求包括以下几个部分:

    产品营销需求、

    规则变更需求、

    产品服务需求、

    法务需求、

    财务需求、

    帮助需求、

    安全性需求等。

    与其说是全方位的掌握技能,还不如说是沟通,

    如何与不同的部门人员之间的沟通,让更多的人协助产品的正常使用与上线。

     

    10、上、下线需求

    上线时限需求:此产品预定上线日期?上线日期有无任何特殊依据或规定?
    下线需求(活动类需求必须明确下线时间):此产品预定下线日期?下线日期有无任何特殊依据或规定?

     

    11、运营计划

    说明产品的后续运营计划。

    包括与运营部的协作运营。

    更多的是给产品经理如何让更多的产品功能展示给用户,产品经理是核心需求的把握者,

    参与到产品整体运营计划显得特别的重要。

    ……

     

    写PRD并不是产品经理的全部工作,但却是不可少的一部分,

    很大程度上反应了产品经理的思维和产品核心功能把握上,

    同时对产品经理沟通、协调、规划等都得到了一定的验证,

    但每个产品经理的第一职能是会写一份让其它人员看得懂的PRD。

     


    ​模板如下:

    公司名-产品名-PRD-版本号

     

     

     

     

     

     

     

    日 期

    制定人

    审核人

    批准人

    2017-02-07

     

     

     

     

     

     

     

     

     

    xx公司 版权所有

     

     

     

    版本记录 

    版本

    作者/日期

    变化内容描述

    审核人/日期

    批准人/日期

    D1.0

    2017-02-07

    创建

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

       

     

     

    1.     概述

    1.1. 名词说明

    名称

    说明

     

     

     

     

     

    1.2 产品概述及目标

     

    1.3 产品roadmap

     

    1.4 产品风险

    风险

    风险级别

    描述

    改善策略

     

     

     

     

     

     

     

     

     

    1.5 问题

     

    2.     使用者需求

    2.1 需求描述

    目标客户

    需求描述

    场景描述

    优先级

     

     

     

    1

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    3.     可选方案

     

    方案介绍

    优点

    缺点

     

     

     

     

     

     

     

     

     

    4.     效益成本分析

    4.1 效益预测

     

    4.2 产品技术中心成本

     

    4.3 非产品技术中心的支持成本

     

    5.     功能需求

    5.1 功能总览

    5.1.1 流程图

    5.1.2 功能表

     

     

    5.2  功能详情

    5.2.1       简要说明

    5.2.2       业务规则

    5.2.3       界面原型

    5.2.4       执行者

    5.2.5       前置条件

    5.2.6       后置条件

    5.2.7       主流程

     

    5.3  整合需求

    5.4 BETA测试需求

     

    6      非功能需求

    6.1 产品营销需求

    6.2 规则变更需求

    6.3 产品服务需求

    6.4 法务需求

    6.5 财务需求

    6.6 帮助需求

    6.7 安全性需求

     

    7      上下线需求

    7.1 上线时限需求

    7.2 下线需求

     

    8      运营计划

     

     

    展开全文
  • 第二:我在自学PRD文档的编写过程中,总是遇到PRD文档里的对应产品总是找不到或是下架的情况,很难找到比较全面以及详细的参考模板,故一气之下撸了一篇,写好分享之。 关于这篇文章: 1.PRD本来就没有固定的...

    为什么写这篇文章?

    第一:写PMCAFF的PRD文档,大家都是用户,比较好参考与理解,方便大家来找我写的不好的地方。

    第二:我在自学PRD文档的编写过程中,总是遇到PRD文档里的对应产品总是找不到或是下架的情况,很难找到比较全面以及详细的参考模板,故一气之下撸了一篇,写好分享之。

    关于这篇文章:

    1.PRD本来就没有固定的版式,根据团队以及个人的需求有所差别,本篇力求简单,不累述。

    2.这篇PRD可以再写的详细些,因为怕内容太多阅读太麻烦,对于需求说明以及用例做了一些简化与合并。

    3.此文档为逆向文档,一般的文档中的界面示例应该是产品原型图(线框图,高低保真图)

    修订记录:

    fetch_file5969e4c132cf1e698661cd2309b7cb9d-picture

    一、 简介本文档主要定义PMCAFF  APP的功能详细描述和前端页面的各个模块的内容和逻辑

    1.    目的

    此文档的目的主要是清晰、有层次的定义页面原型中各个模块的内容来源和相关逻辑。

    2.    范围

    此文档主要描述PMCFF APP中前端页面涉及到的功能点、相对应的后台管理功能支持、以及部分交互细节。本文档主要读者为技术部的前端工程师,以及视觉部的视觉设计师。

    二、 用户角色描述

    fetch_file5af09576e4de81f64d3e69fa2f128eb5-picture

    三、 产品概述

    最大化满足市场和产品以及运营工作者对于产品学习、交流、讨论、社交、求职,以及开展与产品相关的组织和活动所产生的需求,为用户带来一个全面的服务、组织与对接平台和优秀的用户体验,为公司带来固定的高粘度的用户,带给用户有价值的社区,构建帮助用户提升技能,拓展交际,快速学习与思考工具与平台。

    1.目标

    构建全国最大的产品类社交、学习交流与求职线上平台。

    2.总体流程

    fetch_file22959597526947011ef9eb0e292a4acc-picture

    3.产品结构图

    fetch_file57bdd8d662b32921f670819ee28c2986-picture

    4.产品信息结构图

    fetch_fileca2a8fd846d7d75bdb1830e2b2a2b75a-picture

    5.功能摘要

    fetch_file902de878b855bbedda2e537310fecdd3-picture

    四、 产品特性

    1.登陆注册

    1.1需求说明

    fetch_file685c5f7744ec9df7f2c2e302bb0054a9-picture

    1.2用户界面

    fetch_file87cfff169928de58c14c8d5fc3686288-picture

    1.3用例流程

    fetch_file18c7d935363190af89a9fb2d3bb205c2-picture

    2.提问与搜索

    2.1需求说说明

    fetch_file5d1563beafd2bbc5df31314e0ce09e56-picture

    2.2用户界面

    fetch_file15245c5c6e69ec4539678622631b866d-picture

    2.3用例流程图

    3.主题导航列表页

    3.1需求说明

    fetch_filefe4ff5d203e40ce4c31ae600c1363d76-picture

    3.2用户界面

    fetch_filefb7808e180a77b2b16d289ad0b97006e-picture

    3.3用例流程图

    4、问题(文章)内容页面及互动

    (此模块可以再细分进行用例说明)

    4.1需求说明

    fetch_filefff68fd18126c287c762837a1e41d4b4-picture

    4.2用户界面

    fetch_filebc9a2e624f713c839e0c148efcf3eaae-picture

    4.3用例流程图

    fetch_file50e70d9eb526f92431e3f902be869df2-picture

    5.个人资料

    5.1需求说明

    fetch_filecb69754d3ab35ce174358fa7e6f7356d-picture

    5.2 用户界面

    fetch_filec8205cc7f9c5db314f779c343f9c509e-picture

    5.3 用例流程图

    6.消息中心

    6.1需求说明

    fetch_file6a8b9a6db5082cd6dddb0875fcf33134-picture

    6.2用户界面

    fetch_file8c050bf111a97fa696b6a8d8036d1f98-picture

    6.3用例流程图

    7.个人中心(我的互动)

    7.1需求说明

    fetch_file3430a51e413ef4c901f9e687dc76cbc6-picture

    7.2用户界面

    fetch_file8e0c6ba4ebeff4adbe6a1d0f08681d29-picture

    7.3 用例流程图

    8. 设置

    8.1 需求说明fetch_file5eb2be53b75cdd2c3335248376c8d790-picture

    8.2用户界面

    fetch_fileb4100f34adecc8c2a5a4494216e36268-picture

    8.3用例流程图

    8.3.1忘记密码fetch_filea37abbe9aaef032f0adf14e4aa8f7184-picture

    8.3.2修改手机号码与密码

    fetch_file641b737e79431984b1b358288e959160-picture

    五、 其他产品需求

    1.    性能需求

    前端阅读页面以及列表页面,需滚动流畅,滚动阅读时不停顿不卡顿。

    后台数据处理能力应满足几十万用户的操作使用。

    更改与设置密码与手机号时,后台应立即发出短信。

    2.    监控需求

    3.    兼容需求

    需兼容iPhone4及以上机型,iPad2和iPad mini及以上机型、touch5,并且需支持iOS7.0或更高版本

    六、 风险分析

    fetch_file6554de9d3572dae8976a761e1606eebd-picture

    七、 相关文档

    APP UI原型文档、后台管理文档


    会飞的鱼人转载自互联网 ,仅供学习交流,版权归原作者所有,不得用于商业用途。如涉及作品内容、版权和其它问题,请及时与我们取得联系,我们将在第一时间删除内容!


    展开全文
  • 产品经理PRD模板

    2020-07-30 23:30:05
    PRD作为产品经理日常文档之看得最多文档。该资源就是一份标准的PRD文档模板,想了解别人怎么写PRD或者没写过PRD同学,想要看看标准文档里应该有那些内容的,都可以了解了解。后续还会上传MRD模板,敬请关注!
  • 一个标准的产品需求说明书,来自拼多多。个人目前在使用,整体来说还是很规范的。
  • 最近在一次公司组织的内部培训会上,老师提供了一份PRD文档的模板,个人觉得这个PRD模板比较轻量,现在分享给大家。 1、概述 产品概述及目标 名词解释 数据词典 文档阅读对象 2、产品描述 产品整体流程 产品...
  • 产品需求文档 PRD模板.docx
  • 第二:我在自学PRD文档的编写过程中,总是遇到PRD文档里的对应产品总是找不到或是下架的情况,很难找到比较全面以及详细的参考模板,故一气之下撸了一篇,写好分享之。 关于这篇文章: 1.PRD本来就没有固定的...
  • 对于PRD文档的书写,上篇博客我讲了,需求文档的内容会根据软件内容的不一样而有所变化,因此我们需要找到一个能够覆盖你所涉及的项目的所有需求的需求文档模板。接下来我会根据我做的需求文档模板进行讲解,因为为...
  • Axure_PRD文档模板v1.0.rp

    2020-07-30 23:31:34
    axure 自定义元件库整理大全 ,整理了上千个自定义库,包括web端,移动端,包含很多组件库,交互功能,图标等
  • Axure编写产品需求书PRD最佳实践

    千次阅读 2017-10-19 18:25:03
    撰写需求文档(PRD)文档是每个产品人必备的技能,对于大公司工作的产品经理,不必考虑PRD文档应该包含什么内容、应该采取什么格式的问题,大公司有自己成熟的产品方法论,PRD文档都是固定的模版,不可更改的。...
  • 产品需求文档prd,概述部分是概括地说明产品背景,简述产品功能,预期实现的目标,分阶段实现的阶段性目标。
  • 详细介绍了PRD文档的作用和写作方法。 还有文档实例。
  • 产品经理在工作中,除了产品的原型策划,另一项最常的场景是PRD的撰写。通过对产品功能、边界值、逻辑的描述,减少沟通的成本与产品任务的描述。但实际在工作中,我们很多时候的PRD不仅是文档,还可能是原型甚至有的...
  • RP版PRD产品需求文档文档模板
1 2 3 4 5 ... 20
收藏数 1,332
精华内容 532
关键字:

prd模板