需求设计文档怎么写-需求文档撰写规范

作为一名合格的产品经理我们都要学会输出一个需求文档。我是将需求文档和产品文档进行了区分。这里的需求文档他们之间的区别是,这里需求文档不涉及界面原型和交互。(因为交互和原型里面有很大细节,经常改动hi是文档变得不易维护,又一些耗费精力。也会使文档呢的内容变得很复杂之类。)

要给需求起一个方便理解的名称,让团队成员快速理解要做什么样的事情以及实现的目标。最终也会成为项目名称。(有机会或者有条件的情况下,产品经理可以把需求的名称给到技术同事、业务同事看一下 ・ 问下他们对名字的理解是否有歧义。)

背景在这里描述需求的背景及为什么要做这个需求。

在文档中讲清楚,做这个需求的预期收益以及想实现怎样的目的。

背景、目标和收益的内容,可以来自我们之前做的商业需求文档、用户调研报或者市场需求文档 ,不管信息的来源是哪里。需求实现的目标是最关键的,它能够让团队不忘初心。

需求以列表和用例图的方式展现出来,可以大致知道这些需求包含嘛些内容,为后续评估工作量和阅读文档提供便利。

以下是大家最熟悉的模块了

6.1业务概念

在这一部分放上需求分析时的实体关系图。在实体关系图之后,解释每一个元素具体定义是什么,以及具体包括的属性数据有哪些。产品经理提供这些描述,有助于理清业务概念,也可以帮助技术同事拿到需求设计。

6.2流程展示

在这里加入流程图和数据流程图 (下一篇文章给大家介绍数据流程图) ,用可视化的方式一让大家快速了解业务和需求。

6.3需求描述

需求描述是比较重要的一部分,我们可以用前面提到的用例的方式来描述需求。

需求描述可以包括的内容有哪些,通过填写需求描述,将需求一并描述清楚。

非功能需求是一个系统的特征,一般是用形容词或者副词来表示,比如快捷、安全、高效、稳定等。这些词语可以用在功能与功能之间、系统与系统之间、产品与产品质检之间的比较。用户用这些形容词和副词对产品进行了比较,进而就会对产品进行选择。

想要打造出一款触动人心的产品,需要产品经理的心思多分给非功能需求一些。当然,并不是要求系统和功能要满足。

非功能需求清单书写非功能需求就像对手机进行测评一样,总是要把性能的好坏拆分成各种具体的参数和跑分,量化的标准才可以进行参考和比较。所以,非功能需求也要做到量化。

比如,搜索单号要在 0 . 5 秒内反馈结果。同时,非功能需求也是,整体系统和软件的要求。比如,搜索单号要在 0 . 5 秒内反馈结果,那么整体白软件功能都要符合这样的要求。

以上就是我们在分析需求阶段要得到的需求文档。(产品需求文档则比本章讲的需求文档多了2个点产品需求说明以及产品原型)

DRD(Data Raquirements Document) 顾名思义同PRD一样,作为同研发团队沟通的一种凭借。便于管理当前数据埋点的状态和历史迭代逻辑的追述。也是建设公司良好数据体系管理的基础,那么如何写一份高质量的DRD文档呢?

首先, 要明确数据需求 。只有从业务本身实际需求出发,才能够采集满足业务所需要的真实数据。是想了解整个用户浏览页面内容的情况?还是想了解某个功能整体使用情况?只有需求清晰明确了,才能够合理设计埋点采集方案定义埋点指标。

数据是判断你工作目标是否达成的关键依据,是服务于每一次迭代上线后的效果衡量。通常指标定义好之后,围绕着定义好的一些指标进行事件和属性设计就可以着手写DRD文档了。

下面结合具体实例来说一下写好一份DRD文档分几步。

一、明确需求定义指标:

通过需求拆分出核心的数据指标。定义指标前要了解产品的结构、用户行为来明确分析的范围。

实例:

数据需求:通过埋点采集用户行为,分析用户使用情况和选择偏好及流失原因。

指标类别:

1、常用报表指标:新增、日活、启动、周活、月活及注册数据、会员数据、使用时长、留存、系统稳定性。这些通常为日常关心的核心数据指标可以做到报表里供日常观察的指标。

2、营销指标:营销banner曝光、点击及各个营销位的点击排行、展示排行、业务转化等营销板块的数据指标。

3、用户价值指标:新用户的次日留存、7日留存、月留存、成本、用户的产品生命周期模型。

4、运营指标:会员和活动任务的热度、业务转化、会员新增、累计、续费等指标。

5、产品功能指标:导航栏、按钮点击、功能入口的点击和转化等指标。

通过指标常用的类别确定我们需要分析的数据指标,就可以进行埋点事件设计了。

二、事件设计

主要会从两个方面去进行事件设计一个锁定是核心要分析的页面所产生的行为,一个是锁定核心功能产生的行为。

1)页面事件-锁定要分析的页面和页面上的内容以及在这些内容和页面上产生的点击、浏览等行为。

2)功能事件-锁定要分析的功能比如:搜索、登录、注册、购买、会员付费、签到、扫一扫等,这些功能的入口、点击和完成行为。

三、属性设计

每个事件都有对应的事件属性来说明该事件具体分析的维度。属性可分为通用属性和具体属性。通用属性如:版本、设备、网络、IP等。具体属性如:各事件的来源、各页面加载时长、各内容的位置、各内容的ID等。

埋点时需要进行采集这些事件的参数和属性用来分析。事件属性维度的拆解可以依照4W1H(who、when、what、where、how)的方法去进行思考避免遗漏,这里就不在多说了,多多练习就好了。

――通常的页面时间的属性参数会涉及到事件的来源位置、页面曝光时长、页面上曝光的内容、内容ID、内容类型、有无图片等。

――功能按钮点击的事件属性设计时,一般只需要监控按钮点击数即可,不需要进行其他背后的属性说明,例如扫一扫、广告图片点击等。也 有的时候可以把按钮所属的页面作为一个事件,把各个按钮名称作为参数,去设计埋点方案。

事件的采集就是在确定产品范围内找到用户的点击、曝光、完成等系列行为,最后针对各个行为进行属性和参数的细分说明。这样一份高质量的数据文档就完成了一大半。

这里值得注意的一点就是 时刻清晰明确做数据埋点的目的是什么然后通过场景化思考进行方案设计 , 这样有效避免数据遗漏或复杂而无用造成的低效数据埋点方案。 这一方法论不仅适用于埋点方案设计时也适用于在其他所有地方和场景中做产品方案设计时,值得大家牢记。

四、完善文档细节

正如本文开头说的,DRD是作为同技术研发沟通的一种凭借。是为了便于管理当前数据埋点的状态和历史迭代逻辑追述。那么就不可少了对文档一些细节说的备注,上线时间点,当前埋点时的状态。便于后续追溯。

所以一份完整的DRD具有的维度有:事件名、英文名、事件说明、事件属性名、事件属性英文名、属性值类型、属性说明、当前状态是否在线、埋点的形式是前端采集还是后端采集、及上线的版本记录及当时状态的备注说明。这样一份完整的DRD就完成了!

在写需求文档之前我们需要弄明白需求文档是什么?他是用来做什么用的?

首先,根据根据找图网所定义的概念,我们可以了解到产品需求文档(简称PRD)是产品项目由“概念化”阶段进入“图纸化阶段的最主要的一个文档。广义上来讲,产品需求的描述应该包含有产品的战略和战术,战略是指:产品定位、目标市场、目标用户、竞争对手等。战术是指产品的结构、核心业务流程、具体用例描述、功能、内容描述等。

PRD的主要使用对象有:开发、测试、项目经理、交互设计师、运用及其他业务人员

开发可以根据PRD获知整个产品的逻辑;测试可以根据PRD建用例;项目经理可以根据PRD拆分工作包,并分配开发人员;交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前,必须要通过评审确定的最重要文档。

简单了解了需求文档是什么后,我们需要知道,写一个需求文档需要具备哪些要素,我们应该从哪些方面去写。

二、修订记录

三、产品概况

1、项目背景

2、产品定位

3、用户

四、用户角色

五、术语及解释

六、产品结构

1、产品结构图

2、信息结构图

3、业务流程图

七、产品功能

以上是撰写PRD文档的基础内容,除此之外我们还可以写一些非功能性需求,这里就不一一展开说明了。

产品需求文档是记录产品功能的重要文档,也是和开发测试沟通的重要桥梁,但是需求文档也没有完全统一的规范和样式,不同的公司会有不同的要求,因此,我们需要针对不同的产品以及场景对需求文档进行适当的删减,目的是能够表达出产品的实际需求。