软件需求的层次

 

无论是开发人员,需求分析员,或者是测试工程师,做为软件行业的从业者,在每个项目的开始阶段大家都会自然而然地谈到需求。也许是因为被周围的人和大量的相关资讯影响,也许是软件工程的指引,也许是前一个项目的惨痛教训,大家都知道需求是如此的重要。不过,现实依然是参痛的--需求的质量依然不高。

 

我们都知道需求是分层次的,但是需求为什么要分层次呢?我们先从需求怎么分层次开始谈起。

 

从工程角度来看,需求分为业务需求,功能需求,用户需求。以企业应用系统为例,业务需求是从业务角度描述需求,从较高层面概述业务定义,参与者,业务范围以及目标。功能需求是在业务需求的基础上进一步细化,为了满足业务需求的定义及目标,系统+用户必须完成的职责及范围等。用户需求就很明确了,就是用户要求系统必须提供的特性,以便协助用户完成自己的职责,当然,其中也包括用户如何与系统交互。

 

从经济学角度看,需求分为基本型需求,期待型需求,兴奋型需求。我最初是在一本关于广告销售的书里看到这种分类方式,发现也同样适用于软件领域。所谓基本型需求,就是产品必须具备的特性,否则用户不会接受此产品。例如手机必须具备拨/接听电话和收发短信的功能,不然没人会买。期待型需求,是产品可有可无的特性,对用户来讲,有了更好,没有也无所谓。例如手机短信容量达到1000条,支持WiFi.兴奋型需求,就是那些可以让用户为之倾倒并甘愿付出高溢出价的特性,见过iPhone或者Mac book的人应该很容易理解什么叫兴奋型需求。

 

我们之所以要区分需求的层次,无非是为了提高ROI.无论你的用户是最终消费者,还是处于同一企业的同事,ROI是任何时候都要考虑的事情。为什么同一领域的企业,有的利润率高有的利润低?如果一个企业自上而下各个层面无时不刻不在考虑ROI,平衡长期和短期收益,这个企业的利润率不可能不高。一款具备基本型需求,包含少量期望型需求,适当数量的兴奋型需求的产品,如果不大卖热卖,那一定是销售出了问题。


需求分层的另一个目的是让大家在不同层面和角度去理解需求。在一个项目组中不同成员对需求的理解是不同的,项目经理只需要在必要的时候关注业务需求以便于决策,架构师要了解的是功能需求及非功能性需求,开发人员和测试人员要了解的是用户需求。

需求分层还可以帮助需求分析师自上而下分析需求,思路清晰,易于沟通。各个feature之间,层次之间的关系会更稳定,抽象重用更容易。

也许你还有不同的分层方法,欢迎补充。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值