软件需求的层次

 

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

 

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

 

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

 

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

 

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

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

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

也许你还有不同的分层方法，欢迎补充。