主要功能:是描述什么样的功能和特点的产品可以在市场上取得成功
目标市场分析
目标用户分析
竞争对手分析
产品需求概况
通过哪些功能来实现商业目标
功能性需求和非功能性需求
需求的优先级
主要是给产品、运营、研发等业务线上的人看的,在需求被一致认可后,来商量该怎么做、如何做、什么时候做
BRD:Business RequirementsDocument,商业需求文档。产品生命周期中最早的文档,内容涉及市场分析、销售策略、盈利预测等,通常是和老板过的PPT,比较短小精炼,没有产品细节
主要是产品、运营、研发等的管理层。要讲清为什么有这个需求,需求的边界和业务目标,所需资源等。
PRD:ProductRequirementsDocument,产品需求文档。进一步细化,是PM写的最多的内容,也就是传统意义上的需求分析,主要内容有功能使用的具体描述。
给单个职能单位看,沟通非常具体的实施方案
先有BRD,决策是否要开始一个产品。再有MRD,决策如何开始一个产品(when、how)。最后是PRD,决定要开始的产品具体是什么样的(what)。
BRD比较笼统的说是我们要做某件事,并说明做这件事的好处,相当于抛出一个论题。MRD相当于用论点支持我们的论题,具体论述我们该通过什么样的方式来达到我们的商业目的,在一系列分析以后,拿出可行性办法,输出指导性的文档。PRD则是具体的论据,如何具体实施产品方案。
MRD主要就是围绕当前市场、用户、竞品、自身产品四个因素做分析,得出相关结论
市场需求文档(MRD)
文档说明
市场分析
用户分析
竞品分析
产品分析
包括 文档基本信息 和 版本修改记录 。
文档基本信息包括产品需求名称、文档创建日期、创建人/联系方式、部门/职位。
版本修改记录包括日期、版本、修改人、修改内容、备注,一般以表格的形式出现
包括市场问题现状、目标市场分析、市场分析结论
A市场问题现状
现有市场存在问题才有机会,有机会才有可能去做。
就互联网而言可以从以下(不限于)几方面来选择性表述:
用户方面(例如:用户需求没有得到充分满足)
产品方面(例如:产品设计体验差)
技术方面(例如:图像识别技术存在难点)
运营方面(例如:缺乏必要的市场曝光)
商业模式方面(例如:有更有效的商业技巧)
B目标市场分析
很多行业的市场都很大,选择其中最有机会最可能成功从市场。例如互联网金融市场,互联网金融市场里又细分为互联网保险市场、p2p等,p2p里又分为专门做车贷、房贷的,每一个都各自成为一个市场,组合在一块是个大市场
目标市场分析的三个角度:市场规模、市场特征、发展趋势
市场规模大不大,鱼塘里的鱼够不够多,值不值得我们卷起裤子下去捞 相关的数据和分析报告可以从易观智库、企鹅智酷、比达咨询等数据网站获取
市场特征是指市场现状
发展趋势相关行业的最新政策消息、各种智库的相关数据和分析报告
市场分析结论综合上述的分析内容,得到一个比较有市场商业价值的结论,否则这个文档就没有存在的意义。结论得出选择这个市场会带来多大收益,能有多大把握,证明该市场有价值,值得去做。
目标用户群体
用户画像构建
用户使用场景
用户动机目标
A目标用户群体
年龄
性别/地域/学历
经济条件
生活习惯
B用户画像构建
用户画像既不能太粗,也不能太细,需要具有代表性
a用户信息:昵称、年龄、性别、收入、职业、居住地
b用户特征:性格、爱好、技能、习惯
C用户使用场景
用户使用场景就是描述用户在某个环境下完成了某个任务的故事。类似小学记叙文三要素:时间、地点、人物、事件。最终要明确用户在什么场景下会想起你的产品,又在什么场景下使用你的产品
D用户动机目标
分析用户动机的时候,要区分表面动机和本质目标。例如,想吃米线是表面动机,填饱肚子是本质目标。
竞品对象
竞品基本情况
竞品优缺点分析
A竞品对象
寻找竞争对手的关键是要找全找准,不要把眼光局限在同行中
直接竞争对手
间接竞争对手
例如:摩拜单车的直接竞争对手包括ofo、小蓝单车……;间接竞争对手包括滴滴、地铁、公交……
B竞品基本情况
背景历史
市场现状
目标用户
运作/商业模式
运营推广策略
C竞品优缺点分析
竞品的优点能否继承,缺点能否规避,判断是否有机会超越竞品
产品定位
产品核心目标
产品结构
产品路线图
产品功能性需求
产品非功能性需求
A产品定位
一句话描述你的产品是做什么的,我们用什么样的产品满足用户或用户市场。
B产品核心目标
产品帮助目标用户解决什么问题。
解决核心目标的工作优先级是最高的,明确产品目标有助于整个团队专注不迷失。
C产品结构
为了满足用户需求、完成产品目标,需要哪些方面的物料准备。
D产品路线图(roadmap)
产品路线图是产品成长中的每个任务节点组合而成,是以任务为导向的时间节点图。将目标拆分,在不同阶段完成不同的功能。Roadmap的形式非常多,可以是甘特图,也可以是泳道图。无论用那种形式的路线图,必不可少的元素就是时间、任务,必要的时候科技增加子任务和里程碑。
E产品功能性需求
一个产品的重点功能罗列。这里需要主要,MRD只能做功能罗列,不讲具体功能实现逻辑和方法。
F产品非功能性需求
性能需求
安全需求
扩展性需求
兼容性需求
运营市场需求
1.不同的公司、项目要求是不一样的,在敏捷开发的时代,即使是PRD也并非必需品,更何况是MRD,但这并不代表着MRD的内容就不用思考。
类似MRD的内容的思考一定会而且一定要有,只不过不再通过文档的形式表现,敏捷项目对制作MRD文档这一步骤省略的目的在于提高效率,但类似MRD的思考一定存在。
2.BRD/MRD/PRD哪个更重要?如果少做,可以少做哪个?
BRD肯定是最重要的,因为要说服老板或投资人投入,MRD是最有可能被省略的,因为一线员工往往更关注具体怎么做(PRD)。
3.一般谁来写MRD?
产品实习生、产品助理、基层产品经理一般是不写MRD的,更多的是PRD,只有高级产品经理、产品总监才会主要写BRD和MRD。
4.MRD的重点内容是什么?
重点内容:目标市场分析、目标用户分析、竞品优缺点分析、产品功能性需求。
总之MRD要重点论证出为什么要做和要做什么。
6. MRD一般写多少,用什么文档格式写?
MRD的内容很多,如果都详细写的话,甚至可以出本书了,这种情况下,写的人累,看的人也累,因此实际工作中往往根据需要进行缩减,格式上更建议PPT,重点突出。(详细叙述用word,突出重点用PPT)
本节课重点讲解了MRD的结构可内容,所谓的模板仅供大家参考。在实践的工作中,切忌照本宣科、生搬硬套,要根据自身所在公司的情况,酌情增减内容,重点内容多写,次要内容可以少写甚至不写,把握住用户问题和产品机会这个重要的目标来组织我们的MRD,要突出MRD的作用,而不要为了走形式,让MRD成为一纸空文。
撰写自家产品的MRD文档?
模板:
公司名-产品名-MRD-版本号
**公司 版权所有
版本记录
1、产品需求名称
2、目标市场分析
2.1 目标市场:
2.2 市场规模:
2.3 市场特征:
2.4 发展趋势:
3、目标用户分析
3.1 用户分析:
3.2 用户画像:
3.3 使用场景:
3.4 用户动机总结:
4 竞品分析
4.1 直接竞品
4.2 间接竞品
4.3 竞品的模式分析
竞品的商业模式。
竞品目标用户。
竞品运营、营销、推广策略。
技术分析。
市场份额。
5、产品需求概况
5.1 产品定位
5.2 产品核心目标
5.3 产品的结构图
5.4 产品路线图
5.5 产品的功能性需求
5.6 非功能性需求
总结:
如何写需求分析报告(软件需求说明书GB856T-88)
近来学校的一些科研项目又在申报了,一些学弟开始Q我一些软件工程上书面的问题。大概的总结了下,写到这里。本文涉及到的是需求分析部分的书写,主要是根据国家标准文档中的要求来的。
在互联网公司或者一些敏捷开发的公司里,其实大家都是秉承着重开发,重讨论,而轻文档的态度。这个轻文档并不是指没有文档或者几乎不做文档,而是在严格的文档流程中解脱出来,只把最最实际的部分写出来。这个特征是有互联网本身迭代周期短,版本发布快等特点决定的。而在实际的兼职项目的时候,同学们就要注意了,最重要的应该就是在签合同的时候一定要附上最清楚的一份需求分析,虽然这份需求说明可能不是按照某些标准文档而来的,描述清楚每个功能达到的效果,而这个效果一定要让客户点头确认,而不能出现“应该是”、“可能是”、“也许是”这样的模糊回答。否则在项目后期就会比较难过了。在学校申请的项目和大型公司项目开发中,是重视文档流程的,一部一部来。所以还是看情况来对待文档的深度和标准。
一、目录:目录要用word的“引用”—>”目录”,自动生成目录,一般都是要三级目录。通常这部分基本都不需要改结构,直接更新页码即可。
二、内容部分。国家标准软件需求说明书G856T-88下载
1引言
1.1编写目的
说明编写这份软件需求说明书的目的,指出预期的读者。
(这部分说明需求分析报告的概况,例如:本X需求分析报告是为S系统而编写的。+S系统的两句话概述。+本X报告旨在使U1(需求者)明确S系统的要求和细节,给U2(开发人员)了解需求实现的难度和困难,最终提供给U3(审核人、管理者)讨论和审核,达到沟通效果)
1.2背景
说明:
a.待开发的软件系统的名称;
b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;
c.该软件系统同其他系统或其他机构的基本的相互来往关系。
(这部分可以将a,b,c分为2部分,例子如下:
1.2.1项目概况
本需求分析报告所预期开发的软件系统是:S。S是(不是则无)SS系统的某一个功能子模块,S和S1、S2等系统之间的联系,以及概述其他系统的状态等等。
1.2.2任务分配
a.任务提出者:xxx
b.软件开发者:xx
c.产品使用者:xx
d.文档编写者:xx
e.预期产品使用者:xx
)
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
(这部分很简单,就是描述专业词汇,比如
1.XML(ExtensibleMarkupLanguage)即可扩展标记语言,它与HTML一样,都是SGML(StandardGeneralizedMarkupLanguage,标准通用标记语言)。
2.Word2,解释。。。
)
1.4参考资料
列出用得着的参考资料,如:
a.本项目的经核准的计划任务书或合同、上级机关的批文;
b.属于本项目的其他已发表的文件;
c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。
2任务概述
2.1目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
(
本模块开发主要是为SS的整体服务,完成SS工作中的XX部分以及相关的工作。其涉及的范围就是,从下达A、B命令后,到给出C结果的过程。具体描述:B1,来完成B11功能;B2,来完成B22功能;等等。本部分是(否)耦合在分词工具包其他部分中的,主要为嵌入方式和先后方式相互交互。
图
图1.该系统的组成同其他各部分的联系和接口
)
2.2用户的特点
列出本软件的最终用户的特点,充分说明 *** 作人员、维护人员的教育水平和技术专长,以及本软件的预期使甩频度。这些是软件设计工作的重要约束
(例如:二次开发和系统调用人员:具有很高的专业知识水平,理解XX的运行机制。可以对开放代码进行阅读和分析,以完成其系统独特的需求,提供给这部分用户开放API手册和Debug版本的源代码即可;预期这部分用户会占本系统总用户量的多大部分。
xx使用者:具有一定的计算机 *** 作能力和知识,了解xx领域的相关概念和用途。提供给这部分用户 *** 作手册即可。预期这部分使用者主要是来简单的xx *** 作。
维护人员:具有较高的计算机专业水平,可以对常见的系统Bug进行追踪和分析,具有一定的测试能力。这部分用户主要是采用了本系统之后的后期工作维护者。
等等
)
2.3假定和约束
列出进行本软件开发工作的假定和约束,例如经费限制、开发期限等。
(这部分重要是对你有的技术力量、资金状况、人力资源等情况的假设,以使得你可以在什么样的情况和时间范围内完成工作。工期约束,经费约束,人员约束,地理约束,设备约束等几个方面列举说明。)
3需求规定
3.1对功能的规定
用列表的方式(例如IPO表即输入、处理、输出表的形式),逐项定量和定性地叙述对软件所提出的功能要求,说明输入什么量、经怎样的处理、得到什么输出,说明软件应支持的终端数和应支持的并行 *** 作的用户数。
(例如:
INPUT输入
PROCESS处理
OUTPUT输出
LOAD负载量
A
预处理,做怎样的动作,
AA
CC
B
BBBB
Bb
v
C
CCCC
cc
v
表一、xx模块IPO表
对IPO表的简单文字描述。
)
3.2对性能的规定
3.2.1精度
说明对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。
(例如:
Xx目标处理:1Byt_10M,包括左右边界值。
yy精度范围:.
ZZ的精度:由于xx的特殊性,本系统均采用xx型来进行字符统计运算,概率部分以及其他比率部分精度精确到0.0x%。
)
3.2.2时间特性要求
说明对于该软件的时间特性要求,如对:
a.响应时间;
b.更新处理时间;
c.数据的转换和传送时间;
d.解题时间;等的要求。
(这部分只要一一列举就可以:
由于xxx过程中,需要大量xxxx *** 作或怎样,故xx解题时间占总时间的最大部分。其次就是xx转换和存储的开销。其具体时间特性要求,如下:
a.xx响应时间:xxms左右;
b.yy更新处理时间:yy;
c.zz数据的转换和传送时间:zz;
d.vv解题时间:vv。
等等
)
3.2.3灵活性
说明对该软件的灵活性的要求,即当需求发生某些变化时,该软件对这些变化的适应能力,如:
a. *** 作方式上的变化;
b.运行环境的变化;
c.同其他软件的接口的变化;
d.精度和有效时限的变化;
e.计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
(这部分按列举来即可,由于本模块第一目的是用于xxx,其次则是xxxx。故本模块的灵活性在于实际应用者的不同。当需求发生某些变化时,该软件对这些变化的适应能力。具体情况如下:
f. *** 作方式上的变化:采用集成运行制和独立运行制两种模式,集成运行制是把本模块嵌入到分词工具包的主框架中,提供给用户具有一定UI的可 *** 作软件;独立运行制是可以独立运行于后台,并提供给各种程序调用的模式的工作方式,以增强其生命力。
g.运行环境的变化:主采用Windows平台的编译版本运行和调试,在时间允许的情况下,同步开发支持SUSELinux的服务器版本。;
h.同其他软件的接口的变化:在尽量保证接口不出现变动的情况下,允许接口的重载和再定义。但接口的命名规则是统一的;
i.精度和有效时限的变化:精度在必须调整的条件下,可以上下浮动10个百分点;有效时限则依据现实的测试情况允许稍大范围的变化。
j.计划的变化或改进:工作时间安排会存在必然的浮动,这部分要协同分词工具包课题设计组其他成员一同来进行商定,前期的计划可以稍微有些变动,后期的安排尽量按照计划执行。
等等
)
3.3输人输出要求
解释各输入输出数据类型,并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。
(这部分可以把输入输出分为3.3.1输入要求和3.3.2输出要求,如下给出一个单元的例子。
XXX输出
数据名称:XXX输出数据
实际含义:用于XX,表示XXXX
数据类型:Character(字符串)
数据格式:XX
数据约束:由于xxx,,大小在xx以内
)
3.4数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作出估算。
(
根据实际系统要求列举即可
Name名称
Number数量
Size大小
Increase增长
词典xx
xx
xxxx
并行执行,其大小依据实际xx大文本而增长
)
3.5故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
(包括软件压力,内存不足,硬件损坏等,这部分可以根据百度到其常见故障。)
3.6其他专门要求
如用户单位对安全保密的要求,对使用方便的要求,对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
(例如安全保密性:密钥更换等;预期扩展:扩展兼容等;OS更换:Slackware转SUSE等
)
4运行环境规定
4.1设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能,包括:
a.处理器型号及内存容量;
b.外存容量、联机或脱机、媒体及其存储格式,设备的型号及数量;
c.输入及输出设备的型号和数量,联机或脱机;
d.数据通信设备的型号和数量;
e.功能键及其他专用硬件
(列举说明即可)
4.2支持软件
列出支持软件,包括要用到的 *** 作系统、编译(或汇编)程序、测试支持软件等。
( *** 作系统和版本:xxxx
支撑环境和版本:xxxx
备用IDE环境和版本:xxxx
与该软件有关的软件组件:xxxx
后续可能扩展环境:xxxx
)
4.3接口
说明该软件同其他软件之间的接口、数据通信协议等。
(例如:
a.用户和主程序调用接口(图中接口1)。这个接口采用封装API形式和函数调用形式,分别以外部调用和内部调用的方式为不同用户提供使用本机械分词工具的入口。例如以xxxx方式调用DLL文件,以xxxx方式调用函数。如下图2所示。
图2.软件接口调用图
b.xx接口(图中接口2)。这里是一个xxx的接口调用过程。xxxx
)
4.4控制
说明控制该软件的运行的方法和控制信号,并说明这些控制信号的来源。
(例如:
下面通过图表的形式,将本模块以及涉及到本模块的软件模块的运行方法、控制信号,以及这些控制信号的来源,其中箭头所指方向对应的模块的控制信号来自箭头另一方向的模块,具体情况如下:
图3.控制流程图
图3的具体说明情况如下表所示:
Name模块名称
Method运行方式
Signal控制信号
Forward控制去向
主程序模块
运行框架
用户调用或运行
1.调用xx模块
2.调用xx方法
3.调用标准输出模块
xxx模块
xxx
xxx调用
Xxx模块
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)