精华内容
下载资源
问答
  • 需求文档

    千次阅读 2019-03-29 18:10:18
    因为每个人的习惯和团队要求都是不一样的,所以产品需求文档没有统一的行业规范标准,无论以什么样的格式撰写产品需求文档,最终的目的都是让执行人员能够理解产品需求,根据需求完成产品。 产品需求文档的表现形式...

    产品设计是一个由抽象的概念到具体形象化的处理过程,通过文字或图像等方式将我们规划的产品需求展现出来。它将产品的某种目的或需求转换为一个具体的物理或工具的过程,把一种计划、规划设想、问题解决的方法,通过具体的操作,以理想的形式表达出来。

    由于产品设计阶段要全面确定整个产品策略、外观、结构、功能,从而确定整个产品系统的布局,因而,产品设计的意义重大,具有“牵一发而动全局”的重要意义。如果一个产品的设计缺乏具体形象的表述,那么研发时就将耗费大量资源和劳动力来调整需求。相反,好的产品设计,不仅表现在功能上的优越性,而且便于执行时理解,从而使产品的研发效率得以增强。

    1、产品需求文档介绍

    产品设计的最终表述的形式被称为产品需求文档,业界常常称呼为PRD文档,这是英文Product Requirement Document的缩写。产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式,主要用于产品界面设计和研发使用。

    PRD文档是基于BRD、MRD的延续文档,主要是一份给执行层面的工作人员阅读的文档,这部分人群绝大多数是设计与技术人员。在这类人群中,设计师更多依赖于产品原型进行交互或视觉的设计,因此看这份文档的人主要是技术人员。相对于技术人员,他们不太关注产品的商业需求和市场愿景,因为在进行产品讨论立项时,产品的定义就已经向参与设计和研发的人员宣讲过,因此技术人员更多的是关注界面、功能、交互、元素等等内容,因此产品需求文档是一份详细的产品功能需求说明文档,是产品文档中最底层和最细致的文档。

    因为阅读人类的因素,所以产品需求文档是一份没有闲话,直入主题的功能说明文档。并且产品需求文档是没有标准规范的,也没有统一的模板,每个公司都不一样和每个人也不一样,这个取决于个人习惯和团队要求。虽然产品需求文档没有明确的规范,但是目的都是一样的,必须能够明确产品的功能需求,便执行人员理解任务要求。

    2、产品需求文档写作

    产品需求文档是产品经过规划和设计之后的最终执行文档,因此这份文档的质量好坏直接影响到执行部门是否能够明确产品的功能和性能。

    2.1、罗列信息(信息结构图)

    在写产品需求文档之前,我们需要先罗列出产品功能的信息内容,这一步是将想法逐渐清晰的第一步,也是帮助我们接下来设计功能的辅助信息,同时也可以辅助服务端技术人员创建数据库。因为这是第一步,所以我们不需要罗列的很详细,在之后的步骤里,我们会逐步改进和完善信息内容。

    罗列信息内容的方式有很多种,文本形式、思维导图形式等等都可以,最主要的是能够清晰易懂,我最常用的方法就是使用思维导图软件(MindManager)罗列成结构图,因此我称这一步为“信息结构图”。

    shu-17

    上图是一张以Blog系统为示例的信息结构图。信息结构图是一种接近数据库结构的图表,在罗列信息结构时,更多的是考虑信息数据,但是他并不是真正意义的数据库结构。信息结构图是提供给产品经理自己梳理信息内容的结构图,也是方便产品经理和服务端技术人员沟通数据结构的参考图,技术人员会根据这张图表的内容再结合产品原型或需求文档,然后规划和设计出真正意义上的数据库结构。

    信息结构图中关于友情链接功能的信息数据只有“名称”和“链接”两个内容,但是在实际功能需求中,友情链接还有两个功能,分别是“显示或隐藏”和“是否新窗口打开”,这两个功能会在产品原型和需求文档中详细描述,但是在信息结构中是没有体现的,因为从产品层面上来说,这两个只是功能,并不是信息内容。但是在真正数据库中,友情链接的这两个功能分别也是有字段参数的,程序在读取该参数后便知道友情链接的属性,然后处理友情链接是显示还是隐藏,是新窗口打开还是本窗口打开。通过友情链接这个例子,我们就知道了在实际中数据结构和信息结构是不一样的,信息结构只是产品层面的数据内容。

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

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

    2.2、梳理需求(产品结构图)

    当我们对产品的信息结构了解后,我们就需要规整脑海中的产品需求,让想法更加结构化,因此这一步就要梳理产品的需求。在设计产品原型之前,我们首先要罗列出产品的功能结构,包括频道、页面、模块及元素。这一步依然使用思维导图软件,像绘制楼盘鸟瞰图一样将产品的结构绘制成结构图,因此我称这一步为“产品结构图”。

    产品结构图是一种将产品原型以结构化的方式展现的图表,结构内容也如同产品原型一样,从频道到页面,再细化页面功能模块和元素。所以产品结构图是产品经理在设计原型之前的一种思路梳理的方式,并不是给其他工作人员查看的文档,通过类似鸟瞰式的结构图可以让产品经理对产品结构一目了然,也方便思考。

    shu-18shu-19

    如上图示例,“活动大全”的产品结构依次是:产品 -> 频道 -> 页面 -> 页面元素 -> 操作 -> 元素。我们换一个角度观看示例,产品结构图实际上就是一种结构化的产品原型。这样做的目的就是梳理产品结构逻辑,让我们清楚的知道产品有几个频道,频道下面有没有子频道或者有多少个页面,这些页面里又有哪些功能模块,这些功能模块里又有哪些元素。

    shu-19

    上图以我们第一步的“信息结构图”为基础绘制的“产品结构图”,有了这份结构导图,我们可以对产品进行鸟瞰式考虑和完善,当有问题时,修改起来也比原型和文档方便很多。比如在后续规划中,我们发现文章的图片等附件上传后,管理不太方便,这时就可以在结构图中增加一个“附件管理”频道。如果我们使用产品结构图的方式,那么附件管理的功能增加和修改就会比原型工具更加便捷和效率。

    产品结构图的方法同样适用于移动互联网产品的设计,并且比起Web产品更加容易梳理产品结构。

    产品结构图是一种让产品经理通过思维导图的方式梳理思路的方法,通过这种方法可以明确产品有多少个频道、有多少个页面、页面有多少个功能模块、功能模块有多少个元素,逐步的将脑海里的想法明确梳理成结构。虽然这种方法能够明确产品的结构,但是这样的思维导图也就只有产品经理自己能够看懂,因为对于设计和技术人员这是一个抽象的表述方式,如果没有详细的讲解,是很难理解的。

    产品结构图是将产品原型具体化的一种方式,只是罗列了产品的频道页面和功能,但是没有详细的进行推演,关于细化方面是否符合产品逻辑,是否符合用户体验,这些都是没有深思过的,因此我们接下来就要进行原型设计,开始具体的考虑可行性。

    2.3、原型设计(界面线框图)

    当我们逐渐清晰了产品的需求后,并梳理了产品的各个频道及页面,那么这一步就要开始验证这些想法的具体界面表现和方案的可行性了。

    原型设计是帮助我们更细致的思考,并做各项需求的评估,同时也是将自己脑海里的想法进行输出的一种方式。通过原型设计后,我们就可以进行产品宣讲了,相比较于抽象的文字描述,原型则更加直观的展现产品的需求,设计和技术人员或者老板也能够更加直观的了解到产品意图。

    原型设计是将结构化的需求进行框架化,因此原型也被称为线框图,具体的表现手法有很多种,相关的辅助软件也有很多,例如:Axure RP、Balsamiq Mockups、UIDesigner等等。

    当到了原型设计这一步时,已经不仅仅是构思了,我们需要更加深入的了解每个页面上元素和这些元素的属性。例如按钮元素,我们就需要考虑这个按钮的功能,并且这个功能操作后带给后端和前端的反馈。例如注册会员按钮,用户操作后,第一步逻辑是验证用户输入的信息是否合法,不合法则给出前端反馈;合法则和后端通信验证是否已经存在同样信息,已经存在则给出前端反馈,不存在则进入下一步,注册成功;注册成功后的反馈是跳转页面,还是弹出层提示用户完善资料,这些都是需要更详情的考虑。当然这些更细致的思考是留在需求文档撰写时的,而此时我们需要做的就是把这些元素通过原型表现出来。

    原型设计的表现手法主要有三种:手绘原型、灰模原型、交互原型。从工作效率的角度考虑,我非常建议先通过手绘的形式快速在草纸上绘制出产品的原型,推演和讨论方案的可行性。当方案的可行性被验证之后,我们再根据个人习惯或团队要求,通过软件工具进行更深入的设计。

    ① 手绘原型

    因为原型也被称为线框图,因此手绘是最简单直接的方法,也是最快速的表现产品轮廓的手法。

    手绘原型

    手绘原型在初期验证想法时非常高效,也方便讨论和重构,同时也适合敏捷开发时快速出原型。

    ② 灰模原型

    灰模原型是由图形设计软件制作而成,最常用的软件是Photoshop和Fireworks,相对手绘原型,灰模更加清晰和整洁,也适用于正式场合的PPT形式宣讲。

    灰模原型
    phone

    灰模原型也可以称之为平面原型,所以如果不会使用图形软件也可以使用Axure RP设计,相比交互原型,灰模原型只是缺少交互效果,仅仅是将产品需求以线框结构的方式展示出来,让产品需求更加规整的直观展现。

    shu-23

    ③ 交互原型

    交互原型是使用原型设计软件完成的原型,常用软件是Axure RP,通常情况交互原型的设计要早于产品需求文档,是产品经理想法推演的重要一步。通过Axure RP之类的交互原型软件制作出来的产品原型,在功能需求和交互需求的表现上,几乎和正式产品是一致的,所以有时交互原型也被称为产品Demo版。

    通常情况下交互原型是产品经理与交互设计师共同讨论确定,然后由交互设计师制作,但是绝大多数的公司是没有交互设计师这个职位的,因此这类工作最终是由产品经理来负责的。

    以上三种方法并不是渐进的流程,而是三种原型设计的方法,具体取决于你的产品需求和团队要求。

    对于产品经理来说,原型设计是为了帮助我们细致的考虑方案,并论证方案的可行性,同时也是为了产品宣讲时让听众能够清晰直观的了解产品,避免抽象的语言描述导致听众理解困难和理解偏差。产品原型也是为了确保产品在执行过程中,是按产品经理最初设想的需求和期望完成的,因此产品经理的原型是没有很高的要求的,只要对方能够听懂看懂就可以了,所以使用手绘原型是最高效率的方法。

    2.4、用例模型(产品用例图)

    用例(Use Case)是一种描述产品需求的方法,使用用例的方法来描述产品需求的过程就是用例模型,用例模型是由用例图和每一个用例的详细描述文档所组成的。在技术和产品的工作领域里都有用例模型的技能知识。技术人员的用例主要是为了方便在多名技术人员协同工作,或者技术人员任务交接时,让参与者更好的理解代码的逻辑结构。产品人员的用例主要是为了方便技术研发和功能测试时,让参与者更好的理解功能的逻辑。

    用例起源和发展于软件时代的产品研发,后来被综合到UML规范之中,成为一种标准化的需求表述体系。虽然用例在软件研发和技术工作中应用的非常广泛,但是在互联网产品规划和设计中,并不经常使用,互联网产品的需求表达为了敏捷效率,通常采用原型加产品需求文档。

    UML是英文Unified Modeling Language的缩写,中文称为统一建模语言或标准建模语言,是用例模型的建模语言,常用工具是Microsoft Office Visio。产品用例是一种通过用户的使用场景来获取需求的方式,每个用例提供了一个或多个场景,该场景说明了产品是如何和最终用户或其它产品互动,也就是谁可以用产品做什么,从而获得一个明确的业务目标。

    ① 用例图

    用例图并不是画成了图形的用例。用例图包含一组用例,每一个用例用椭圆表示,放置在矩形框中;矩形框表示整个系统。矩形框外画如图所示的小人,表示参与者。参与者不一定是人,可以是其它产品、软件或硬件等等。某一参与者与某一用例用线连起来,表示该参与者和该用例有交互。

    shu-24

    许多人通过UML认识了用例,UML定义为展现用例的图形符号。UML并不是为描述用例定义书写格式的标准,因此许多人误认为这些图形符号就是用例本身;然而,图形符号只能给出最简单的一个或一组用例的概要。UML是用例图形符号最流行的标准,但是除了UML标准,用例也有其它的可选择的标准。

    ② 用例描述文档

    用例图只是在总体上大致描述了产品所能提供的各种服务,让我们对于产品的功能有一个总体的认识。除此之外,我们还需要描述每一个用例的详细信息,这些信息应该包含以下内容:

    shu-25

    用例名称:本用例的名称或者编号

    行为角色:参与或操作(执行)该用例的角色

    简要说明:简要的描述一下本用例的需求(作用和目的)

    前置条件:参与或操作(执行)本用例的前提条件,或者所处的状态

    后置条件:执行完毕后的结果或者状态

    用例描述文档基本上是用文本方式来表述的,为了更加清晰地描述用例,也可以选择使用状态图、流程图或序列图来辅助说明。只要有助于表达的简洁明了,就可以在用例中任意粘贴用户界面和流程的图形化显示方式,或是其它图形。如流程图有助于描述复杂的决策流程,状态转移图有助于描述与状态相关的系统行为,序列图适合于描述基于时间顺序的消息传递。

    在互联网产品和设计中,用例的使用越来越少,通常有了产品原型再加上功能流程图和功能说明文档就能够将产品需求详细的表述清楚,所以也没有必须撰写用例了。但是在大公司里,往往会追求产品流程的规范性,要求撰写用例,不过在敏捷开发的时候也会采用其它更有效率的方式,不一定非要撰写用例。

    前面几步我们将产品需求逐渐细化并且通过原型的方式将产品需求形象化的展现了出来,但是在产品功能的逻辑细节方面,原型就非常不直观了,所以用例是一个非常重要的描述需求过程的文档。

    但是由于用例文档以文字为主,并且格式复杂,不适用于高效率的产品需求表述,所以展现逻辑流程的“功能流程图”是一个简洁直观的可替代用例文档的方式。

    shu-26

    (请点击查看大图)

    如上图所示,功能流程图是一种使用图形的方式表示算法逻辑的图表,因为千言万语不如一张图,通过流程图将“优惠券”功能模块的逻辑和需求非常形象直观、一目了然的展现了出来。

    流程图的展现方式也不会产生“歧义性”,便于理解,逻辑出错时也非常容易发现,并且可以直接转化为程序需求描述文档。

    2.6、需求文档(PRD文档)

    前面的几个步骤是为了帮助我们梳理需求、验证可行性和明确细节,到了这一步的时候我们已经非常清晰的了解产品需求,此时撰写产品需求文档可以大大减少和避免了撰写文档时容易忽略的细节黑洞。

    产品需求文档是将产品规划和设计的需求具体形象化表述出来的一种展现形式,主要用于产品界面设计和研发使用。因为每个人的习惯和团队要求都是不一样的,所以产品需求文档没有统一的行业规范标准,无论以什么样的格式撰写产品需求文档,最终的目的都是让执行人员能够理解产品需求,根据需求完成产品。

    产品需求文档的表现形式有很多种,常见的有Word、图片和交互原型这三种形式,文档内容通常包含信息结构图、界面线框图、功能流程图、功能说明文档。虽然产品需求文档没有标准的规范,但是有两项是必不可少的,那就是文件标识和修改记录。文档在撰写过程中,我们可以自行不断的修改完善,但是如果正式发布或交给团队其他成员后,一旦有了修改,为了文档的同步,我们就需要标注出文档的修改内容,备注修改记录,这样可以方便大家查看和了解改动的内容。关于文件标识和修改记录,格式都大同小异。

    prd

    ① Word

    这是传统意义上的产品需求文档,主要有四个部分组成(具体根据产品要求进行划分),分别是:结构图、全局说明、频道功能、效果图。

    因为产品需求文档的阅读者主要是偏向于技术人员,因此文档的目的性非常明确,就是要描述产品的功能需求,所有产品需求文档没有关于市场方面的描述。为了保证需求的执行效率,建议大家尽量减少不必要的文字,在能够让阅读者看懂并且了解产品意图的情况下,文字越少越好。这主要是因为绝大多数人是没有足够耐心认真看完产品需求文档的,因此我们要尽量减化文档内容。

    ①-1、结构图:

    ①-1.1、信息结构图:主要是辅助服务端技术人员创建或调整数据结构的参考文件

    ①-1.2、产品结构图:主要是辅助设计和技术开发人员了解产品的全局结构。

    ①-2、全局说明:

    主要讲解产品的全局性功能的说明,例如网站产品的页面编码、用户角色,移动产品的缓存机制、下载机制,这类全局性功能的说明。这里我举一个移动产品的“状态维持与恢复”的例子。示例如下:

    状态的维持与恢复

    当用户退出产品时(误操作、Home键、锁屏、自动关机),产品需要维持用户操作前的状态,当用户返回产品时仍可以恢复到之前状态,并继续使用。

    维持状态包括流程操作、信息浏览、文本输入、文件下载。

    锁屏状态时,如果用户在产品中有下载任务时,仍然保持下载。

    ①-3、频道功能:

    以频道为单位,页面为子项,分别描述产品的频道、页面及页面模块元素的功能需求。示例如下:

    1、频道名:频道介绍及需求说明

    2、页面1:页面介绍及需求说明

    2.1、页面模块1:模块功能需求说明

    2.1.1、页面模块1-元素1:功能说明

    2.1.2、页面模块1-元素2:功能说明

    2.2、页面模块2:模块功能需求说明

    在撰写功能需求时,我们需要考虑用户的流程,例如一个“完成”按钮,我们需要描述他完成后,系统要不要给出反馈提示(反馈提示是什么样的形式反馈,内容显示成什么,有没有内容需要调取数据库),或者要不要跳转页面(跳转到哪个页面,这个页面是其他频道页面,还是这个功能的子页面,如果是子页面就需要再描述这个子页面的模块及元素内容)。

    ①-4、效果图:

    效果图是由设计师完成的产品图,和实际开发完成的产品保真度一致。

    这个示例是一个移动产品(iPad)需求文档,其中部分隐私内容已过滤隐藏,并且只保留了首页和地图找房频道的需求说明。由于工作环境没有交互设计师,所以Word文档中包含了部分交互说明。

    ② 图片

    图片形式的产品需求文档是基于效果图的说明文件,将传统Word形式的功能需求说明标注在效果图上,这种方式经常使用在移动互联网领域,实际上是图文形式的交互需求文件,只是在此基础上更深入的描述出功能需求。

    对于图片形式的产品需求文档,我们只需要另外再描述一下全局说明,其他频道页面的需求直接以图片形式展示,这种方式相对于Word文档的纯文字更加生动易读并且直观,因此有一些产品经理非常喜欢用这种方式代替Word形式的产品需求文档。

    picture_prd

    ③ 交互原型

    这里指的交互原型就是前面篇章讲到的原型设计,使用Axure PR之类的交互原型设计软件制作出来的产品原型非常真实和直观,并且原型软件还支持元素标注和导出Word文档,因此很多产品经理都喜欢使用Axure PR来代替Word完成产品需求文档。

    当我们通过Axure PR制作出产品原型后,实际上他已经是很完善的产品Demo了,因此我们只需要加上元素的标注,在标注中说明功能需求,这样导出的HTML文件相比Word文档更直观易懂,是非常高效的产品需求说明方式。

    shu-31

    无论你采用哪种方式撰写需求文档,最终的目的都是为了方便团队成员理解产品的意图,因此哪种方法能够避免细节黑洞,高效完成产品的设计和研发,那么这种方法就是最有效的方法


    展开全文
  • 需求文档 | 产品需求文档(PRD)

    千次阅读 多人点赞 2018-08-07 16:52:56
    首先,与大家先分享一句话:把需求文档当成一个“互联网产品”去管理,理解它的用户,关注它的体验,不停迭代,使其价值最大化。(引用) 既然把它视为一个互联网产品,那我们需要思考PRD的用户是谁,他们通过PRD...

    一份优秀的PRD能够帮助你获取资源,有效推进项目,获得团队成员的信任。

    一、PRD的用户是谁?

    首先,与大家先分享一句话:把需求文档当成一个“互联网产品”去管理,理解它的用户,关注它的体验,不停迭代,使其价值最大化。(引用)

    既然把它视为一个互联网产品,那我们需要思考PRD的用户是谁,他们通过PRD要了解什么内容?

    根据用户以及他们的诉求,我把PRD分成几个阶段:

    image

    1)MRD阶段

    这个时候,主要需要说服我们的老板、或者团队内部评审,也会有需求方,让大家认同你的方案,知道你要做什么怎么做。

    所以这个时候类似于MRD,把整个方案路线说清楚就可以,做一个较粗线条的DEMO图。

    切勿做细化的设计稿,更不要写详细的功能说明,因为这时候被拍的可能性很大。

    2)PRD V1.0

    如果通过了第一步评审,这时可以做细化的内容,做一个相对细化的DEMO图,这一步面向开发、交互,开发进行技术上的评估。

    交互是下一步真正要做事儿的人,会关注一些页面的细节,所以这个时候可以做详细的DEMO图,并在DEMO图右侧配以一些说明,方便交互及UI进行工作。

    不要写详细的界面操作说明,不过可以在进行界面设计期间,先写一些业务逻辑相关的内容。

    3)PRD V2.0

    这个就是全版了,这么细化的内容,只有真正做这块功能的开发同学才会细看,写细写全没得说了。

    了解了不同用户的诉求,那我们就具体说下PRD编写的内容吧。

    二、围绕用户体验要素的PRD编写

    为什么要说围绕用户体验要素来编写PRD,因为产品的设计是围绕着这个经典的框架来的,那写PRD的任务当然是要把这个内容向大家表述清楚。

    用户体验要素

    下面就具体说下PRD如何围绕这个内容编写。

    第一部分:需求概述(战略层)

    其实不仅仅是做产品,任何事情,第一步肯定是要想清楚要做什么,为什么要做,也就是把战略层描述清楚,PRD的第一部分就是要把这块内容说清楚,回答出下面的问题。

    1)用户要获得什么?—— 用户痛点、需求

    建议这块内容,说清楚整体的问题痛点,同时也要举具体case,列举数字,如用户的使用频次,现在的花费等等。

    2)用户是谁?—— 用户细分、用户数量、画像

    用户是谁,并不是如“商家用户”这种粗线条的描述,要说清楚对于当前的功能,是哪类用户在什么场景下的需求,用户的量级是怎样的,有一个相对具体的画像。

    3)用户能通过这个得到什么? —— 用户收益

    这里面补充个内容,俞军老师曾说过,用户净收益=新体验-旧体验-替换成本,替换成本可能是获取成本、认知成本、资金等等, 虽然这些内容并不是真正可衡量的,但在做一款新产品评估其价值时,可以从这几个角度进行思考。

    4)我们能得到什么?—— 对企业能带来什么收益

    这点很重要,做任何产品,给用户赋能,给用户带来价值,其主要目的还是企业自身能够盈利,这点想清楚才能说服老板提供资源呀。

    image

    第二部分:产品规划(范围层)

    最抽象的战略层说清楚了,下一步就要大体说下为了实现上面列举的各种想法目标,要一步一步怎么做了,也就是说清范围层的内容。

    1)功能&信息结构图

    范围层,就是要说清楚,为了实现战略做什么事情,什么功能,提供什么内容。这块一般会通过脑图或者框架图来展现,说清楚我们需要哪些数据,做哪些功能,各个功能与功能之间的关系。

    要注意,这部分需要在长远角度,解决这个问题地整条路线进行思考。举个例子吧,比如要做个评论功能,让用户对产品更了解,并带来更多销量。那第一步先增加评论功能,之后可以对评论进行分析,为用户推荐高质量的产品,发现问题产品保证平台产品质量等等。类似这样,出一个整体的规划蓝图。

    2)路线规划

    蓝图出来了,还是要落地的。所以这一步要把刚才地蓝图,切成一块一块,每一步要做什么,多长时间,这个阶段解决怎么的问题,为后面提供什么铺垫。有些内容,也可以出一个简易的DEMO图,能描述清楚即可。

    image

    第三部分:功能概述(结构层、框架层、表现层)

    这一部分是对当前这一期要做的内容的详细描述了。这部分面向的主要用户是UI、交互、开发、测试同学,具体到做事情上,就是把大家的认知拉齐。

    1)产品流程图

    通过图的方式,可以快速、方便地告知PRD的每个用户这个功能的思路流程。这里最开始放的是比较粗线条的流程图,比如买家购买商品,加入购物车->付款->商家发货->确认收货。而一些细节,比如买家超时未付款,或者卖家修改价钱等等,可以到具体写到这个功能点地时候再出一个细化的流程图。

    2)DEMO,原型制作

    3)UI稿

    4)产品功能点

    image

    补充:

    产品流程图——UML(统一建模语言)

    Unified Modeling Language (UML)又称统一建模语言,为软件开发的所有阶段提供模型化和可视化支持,简而言之,就是用图的方式把事情描述清楚。

    下面我以员工提交权限审批这件事为例,对应地类(或者说是对象)有员工、老板、还是审批单,给大家主要介绍4个图。

    1)活动图

    我们也经常叫流程图,就是要描述清楚各个角色之间的工作流程。

    矩形框内描述当前活动,菱形块列出分叉路线。如果有多个角色,如下面的例子,则将每个角色出一个泳道,对应哪个角色的活动即放到哪个泳道下。

    image

    2)序列图

    这个图是各个对象之间的一个描述,与活动图略有相似,可以看下面的例子,我们在日常工作中,选取其中某一个把事情说清楚就OK了。

    这里每个对象会有一个生命线,我把系统本身单出来,做了一条生命线,员工、老板在进行某些操作后,需要系统这面进行保存或者修改状态,那右侧即对应与数据库的交互,后端同学根据这个,大体就了解自己在什么时候要做什么事情了。

    image

    3)状态图

    状态图的样式,虽说和活动图样式差不多,但其实内容差别还挺大的,状态图是对一个对象的不同状态切换进行描述。比如权限审批这个事情,审批单有“审批中”、“未批准”、“批准”这3种状态,通过这个图可以很清晰地了解各个状态的转换方式。

    image

    4)类图

    描述类的内部结构和类之间的关系,这个用得不多,可以简单了解下。

    还是这个功能,我们有员工、审批单、老板这3个类,他们有些属性,对于员工和老板还有一些操作,可以通过这个类图来表述出来。其中有个±号,+号是public,即其他类可见,-号是private,其他类不可见。比如员工的姓名,其他类无法获知,但可以通过一些对象操作获得。这个就有些偏开发的内容了,不是特殊需要开发同学知道信息,可以不对这块进行标注。

    image

    产品功能细化说明

    这块就是要把功能说得足够细,但也是有一些技巧。

    1)更新说明

    首先,我一般会在功能最上方,列出更新的清单,一般记录有:调整时间、调整功能块、详细说明。

    2)全局说明

    每期功能可能会有多个页面多个功能块,但有一些想通的地方,比如对于数据产品,数字的展现形式,保留2位小数,增加三分位符号等;对于移动端产品,一些操作方式等。这个适用于各个块,不用分别在每个中单独说明,而且后续做其他功能都是可以复用的,可以先列出来说清楚。

    3)具体每个块的功能说明

    • 前置条件:有些功能可能会有这个内容,在什么情况触发这个功能,比如在用户购买什么商品后提供某个功能;
    • 主体功能说明
    • 流程描述:主流程、分支流程,这个就可以使用上面介绍的UML图,把主线条描述清楚;
    • 界面描述:操作、文案,文案建议其他颜色标注出来,防止和描述弄混;
    • 业务规则:这个是在界面看不到的,比如限制条件、表格的排序规则、需要记录的数据、还有一些数字的计算公式等等;
    • 异常描述:这个不能忽略,尤其是C端产品,考虑需要更为全面,因为很可能就是一个小异常,就导致用户使用不爽而流失,比如上传文件没有考虑超出大小怎么办,用户上传后一直没反应,就会认为这个产品不好用,转而使用其他产品,所以,异常地考虑很重要。列几个常见的异常:如未输入、输入错误、无数据,无网络,长时间未操作,异常退出等等。

    最后说下写这块内容的原则

    • 完整:足够细,考虑足够周全;
    • 无歧义:RD同学是拿着这个文档真真切切写代码,所以说得内容,要能够落到代码上,比如用户一段时间未操作则提示。等待多长时间,要写清楚;
    • 有条理:这文档是有人看的,所以序号、符号都适当的用上,让你的文档容易阅读;
    • 及时更新:功能、DEMO的调整,都需要落到PRD上。

    第四部分:数据需求

    需要哪些维度、哪些指标,指标的来源库表字段、计算口径是什么,这些都要清晰地记录下来。

    除此之后,有个内容可能经常会被忽略,就是数据的整理。以某宝的搜索结果页为例,一般会展示图片、标题、价格、销量、卖家名称、包邮会标记出来,这些RD通过UI稿可能会查看到,但有一些比如鼠标移入显示信息,点击操作、是否购买过,都在商品展示时体现出来。

    这些内容,我们可不能指望RD同学从UI稿中一点点发现。所以列出这样的表格,把你认为需要的类及其属性列清楚,有点类似我们上面类图中对象属性要描述的内容,目的是让开发同学对照这个来进行库表设计,不要遗漏某些点。

    image

    第五部分:数据埋点

    包括按钮的埋点&内容的埋点,可以通过截图+表格说明的方式,截图标明需要埋点哪些控件,表格说明对应控件的什么信息,如操作PV、UV、输入内容等。

    第六部分:效果评估方案及上线安排

    对于C端产品,这块内容会更加重要,一般会有个灰度发布过程,因此需要说清楚灰度发布的方式,放量安排、节奏,需要关注的指标,这个指标如何进行评估,达到什么样程度可以全部上线。

    第七部分:人员排期

    OK,大功告成了。

    三、PRD的承载

    PRD的存放:

    • 在axure中完成,在DEMO的右侧进行说明,但这个不好的是:在进行更新后,还要发送给大家,各个版本的存放加上axure本身下载解压就比较麻烦,所以并不是最佳方案。
    • wiki来完成,只要一个链接,更新后只要告知大家同步下信息就好,就是在写功能时候,需要把DEMO对应图贴上去,RD能够比较方便知道是对哪块内容的描述。

    对于上述内容,我一般分成2个wiki页记录,一个记录需求概述和产品规划部分内容;一个记录产品功能及之后的内容,这个是当前这期的事情。一个总分的结构。

    以上是我个人写PRD的一些经验总结,希望对大家有帮助。

    展开全文
  • 项目需求文档

    热门讨论 2007-11-20 13:55:02
    一些简单的项目需求文档,可根据这些来做相应的系统
  • 需求文档评审

    千次阅读 2015-04-06 15:22:40
    需求文档评审
    需求文档评审




    一、何为需求文档
            描述软件系统所应具有的功能、非功能需求。包括软件系统具有的外部行为,系统展示给用户的行为和操作等。



    二、需求规格说明书综述
            需求规格说明书的六大特点:正确性、无歧义性、完整性、一致性、可验证性、可追踪性。




    三、如何做好需求文档评审
















    注:
        如何做好测试工作呢?熟悉被测系统最重要。熟悉被测系统的方法:
    与需求提出方(软件最终的使用者)沟通
    阅读需求规格说明书
    与研发沟通
    阅读设计文档
    浏览缺陷库&阅读用户手册
    参考同类型系统
    运行被测系统



    展开全文
  • 如何梳理需求文档

    千次阅读 2019-01-21 19:11:27
    前提:最近做的项目因为需求文档经常不详细,导致在测试的过程中,总是发现细节问题,或者逻辑不合理的地方,或者因为文档不详细导致开发做的时候就是按自己的意思来,而不是产品想要的意思,导致测试因为确认问题而...
    • 前提:最近做的项目因为需求文档经常不详细,导致在测试的过程中,总是发现细节问题,或者逻辑不合理的地方,或者因为文档不详细导致开发做的时候就是按自己的意思来,而不是产品想要的意思,导致测试因为确认问题而浪费很多时间,所以非常有必要研究下怎么梳理需求文档。

    在项目中需求文档有3种现状:

    1. 有详细的需求文档:这当然是很专业了,测试人员只要认真研读文档,并和产品确认问题即可

    2. 需求文档不明确即有文档但是文档很粗糙:

       1)那么就需要自己去沟通对于文档中不明确的点问清楚,尽量减少因为不明确导致的开发瞎做,到时候确认问题浪费的时间

       2)当然因为条件有限,我们不可能完全想全面,很多问题还是会在测试的时候才能体现,所以这时需要注意的是测试时间一定不要高估,一定要比你以为的时间再增加几天,相信我,你绝对按时完成不了

    3. 没有需求文档:

    第一种靠嘴去问,大家去协调,协商沟通,然后大家都回答没问题了,我会自己写一个概要的需求描述,然后让他去确认,他说可以,那咱们就这样测,有问题就不断的口头沟通;

    第二种要基于用户使用的场景和行业的经验来去做判断它是不是合理的。

     

    • 总结一个我看到的网上的经验,如何判断你已经掌握了足够的需求呢:让负责梳理需求的测试人员直接当做产品人员一样去给测试团队的其他人去讲解需求,如果能够说清楚所有的模块、功能点和必要的流程,且不会被测试团队成员问太多自己回答不了的问题,我觉得需求就算理解的差不多了。如果做不到解答大部分测试人员问的需求问题,那么一定是你的需求还理解的不够到位,需要在进一步去了解和沟通,此过程直接决定着后续测试项目的质量,请大家务必重视!
    • 一个参加测试评审的要点:要多问几个为什么,为什么要提这个需求(设计的背景是什么,以及设计的总体框架是什么,不要先讲细节)?目前是遇到什么困难?现在是怎么做的?如果涉及到业务数量的,还可以问下量大不大?帮助我们评估需求的合理性

     

      

    展开全文
  • 需求文档是根据用户需求转化而来的技术实现需求,需要针对用户提出的产品目标进行细分,总结出具体的每一个功能点,再针对每一个功能点细分为各种不同的操作流程,对每一个操作流程进行技术化定义。也就是说,需求...
  • 软件需求文档(全套)

    千次下载 热门讨论 2010-09-29 23:28:35
    软件需求文档(全套)软件需求文档(全套)软件需求文档(全套)软件需求文档(全套)软件需求文档(全套)软件需求文档(全套)软件需求文档(全套)软件需求文档(全套)软件需求文档(全套)软件需求文档(全套)...
  • app开发需求文档

    千次阅读 2019-09-21 14:45:25
    我们在开发app前都会做需求分析,这个app开发需求文档怎么写呢?一般可以从这几点入手:确定APP方案的目标,APP方案的受众分析,APP开发方案功能设计,APP的操作系统说明方案,APP是是否是原生APP,APP方案的视觉...
  • 在产品研发过程中,《需求文档》与《需求分析报告》以及《需求规格说明书》是产品研发的辅助文档,必不可少。遗憾的是不但外行人傻傻分不清,有时候相关从业者乃至被神化了的产品经理也是分不清楚。是什么导致了分歧...
  • (1)在需求方面达成一致:需求是一种反复进行的过程,涉及到各种各样具有不同背景和要求的用户,需求文档必须有助于需求分析师与用户之间的沟通,以及需求分析师与软件设计师和测试工程师之间的沟通; (2)为软件...
  • 需求文档编写总结

    2019-07-18 11:53:51
    沟通 在公司做开发有时候不可避免的要沟通需求,然后编写需求文档。沟通甚至比技术更难,甚至令人有一种这样的感慨:“宁愿写代码和机器打交道,也不愿意和人打交道”。 ...
  • 产品需求文档怎样编写

    千次阅读 2018-09-07 12:20:06
    产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然,这个定义针对的是一个全新的产品。广义上来...
  • 软件需求文档范例下载

    千次下载 热门讨论 2007-06-29 11:02:26
    软件需求文档范例下载地址
  • 因为需求文档最主要的作用就是能够向甲方和技术清楚的表达出软件的需求,方便技术根据需求文档进行开发,方便甲方根据需求文档确定需求以及修改。 这次我主要介绍的就是对于淘宝商家提供技术支持的计算机公司的需求...
  • 需求文档是根据用户需求转化而来的技术实现需求,需要针对用户提出的产品目标进行细分,总结出具体的每一个功能点,再针对每一个功能点细分为各种不同的操作流程,对每一个操作流程进行技术化定义。也就是说,需求...
  • 结合多个优秀的需求文档案例,总结了下面的需求文档的框架,希望对想学习写需求文档的朋友有帮助。 二、框架 2.1 需求文档的架构 主要围绕着需求来写,包括需求的背景、价值、专业的名词解释...
  • 用axure做产品需求文档

    热门讨论 2020-01-14 11:54:29
    用axure做产品需求文档 分享一个自己做的完整产品需求文档模板,并且内置了思维导图、流程图、微信小程序原型、后台系统原型等示例。 本文档是从真实互联网项目中抽取出来的产品需求文档的原型模板,归纳了互联网...
  • 作为一名程序员,什么原型图,需求文档,这些名词都不陌生吧,虽然这些东西都不是程序员做的,而是产品经理做的,但是程序员是要看的,只有看了原型图和需求文档才知道自己要做什么东西以及其中的一些具体细节,在...
  • 产品需求文档(PRD)

    千次阅读 2019-09-17 16:47:00
    产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。 一、什么是产品需求文档 该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档。当然,这个定义针对...
  • 个人博客系统需求文档

    千次阅读 2019-04-29 21:56:14
    个人博客项目需求文档(一)项目简介项目概述功能概述用户需求分析需求一、写文章角色:作者使用场景用例需求二、已发布文章的修改和删除角色:作者使用场景用例需求三、草稿箱的半成品的修改和删除角色:作者使用...
  • 项目过程管理(五)需求文档

    千次阅读 2019-02-28 16:12:43
    写作思路和本模板的设计原理,请参考《如何写出受技术欢迎的需求文档》。 实际的示例,可参考《倒推盒马鲜生App产品需求文档》。 额外的要求: 文档的标题是1句话,跟需求总表里的一致。 需求描述的基本要求:条理...
  • 通用产品需求文档模板

    万次阅读 2017-06-10 17:25:08
    很多朋友说,产品需求文档怎么写?很多公司的产品需求文档要求各不相同,但也是大同小异,其实就是说清楚: 基于什么样的背景,我们要做什么事情, 满足什么用户哪一个需求? 需求分解出来,产品的逻辑如何? ...
  • 产品需求文档大家都知道,可是什么是一体化产品需求文档呢?其实,这个一体化是我将自己创作的文档命名为一体化产品需求文档。之所以要叫这个名字,是因为此文档除了包含原型和需求描述以外,还承载了产品其他相关...
  • 接口测试需求文档分析

    千次阅读 2019-02-01 11:14:15
    接口测试的依据,往往不是需求文档,而是接口文档。 那么,接口文档的准确性便至关重要。接口文档不管以什么形式存在,需要包含的内容有: 1、接口名称 2、接口类型 3、输入参数:  每个参数名;  每个参数...
  • 如图,我们一旦使用excel写需求文档,会立即知晓需求数量,图有14个需中便求点。你还记的上一个版本做了多少个需求吗? 我们使用excel来攥写需求文档,会很明确每个版本的需求量,比如我在上一个版本里总共开发的...
  • 需求文档(PRD文档)

    万次阅读 多人点赞 2018-03-05 22:11:21
    产品设计是一个由抽象的概念到具体形象化的处理过程,通过文字或图像等方式将我们规划的产品需求展现出来。它将产品的某种目的或需求转换为一个具体的物理或工具的过程,把一种计划、规划设想、问题解决的方法,通过...
  • 【PM】产品需求文档PRD的一般格式

    千次阅读 2018-09-11 11:51:29
    是将商业需求文档(Business Requirements Document,BRD)和市场需求文档((Market Requirements Document,MRD)用更加专业的语言进行描述。 产品需求文档,是交互设计的基础。通常包含了产品的理念宗旨、功能...
  • 一份优秀的需求文档

    千次阅读 2018-11-30 10:31:56
    1.制作原型的步骤 1.分析需求 罗列出原型需要实现的需求...需求文档就是产品功能说明书,包含大量的功能细节,目的是提高沟通效率,避免研发过程出现误会。 3.需求文档包含的内容 1.需求背景与目标说明 你得让别人...
  • 如何写出受技术欢迎的需求文档

    千次阅读 2018-10-31 14:49:01
    正如我们做出来的产品都希望受用户欢迎,开发和测试是需求文档的用户,产品经理也应该重视他们的想法和要求才能写得令人满意。 “写需求文档”说专业点是把用户(或运营、客服等)的需求转化成技术部门的话语,因此...
  • 2.6、需求文档(PRD文档) 前面的几个步骤是为了帮助我们梳理需求、验证可行性和明确细节,到了这一步的时候我们已经非常清晰的了解产品需求,此时撰写产品需求文档可以大大减少和避免了撰写文档时容易忽略的细节...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 51,561
精华内容 20,624
关键字:

需求文档