需求管理之被遗忘的需求
”专家说:“这种牛是能够造出来的,如今有基因project。”队长说:“好吧,你给这造几头这种牛。”于是专家找到了生物实验室。让生物实验室的人搞一个基因project,把牛造出来。
于是project浩大,投资无法保证,合作多半是不愉快的收场。
现实世界里非常多人分析需求的过程就相似于这位专家。他们把注意力放在用户提出的功能点上。而对用户的实际需求没有兴趣。有不少软件公司和程序猿,事实上都在做相似的基因project。假设这个专家把注意力放在生产队长的业务需求上,而不是太在乎他提出的功能点。他会说:“我认识一个卖拖拉机的,能够带你去看看。”
软件的维护为什么这么痛苦。一个非常重要的原因在于:需求已经被遗忘了。
需求是对用户具有直接商业价值的活动。而不应该牵涉到不论什么的功能实现方式。实现同一个需求能够使用多个方案。每一个方案有自己的功能方式,在某个方案中至关重要的功能点,或许在还有一个方案中根本无关紧要。
瀑布式的开发过程,首先是由一批懂得用户业务的专家去调查用户的需求,分析出这个系统应该具有哪些功能,形成一个非常关键的文件——《xxx系统需求规格说明书》。客户认可了这个《说明书》,在上面签字盖章,增加合同附件,到时候项目验收就以此为准。
这时候。需求就已经分解成了一个个功能点,从这时候開始,需求本身就渐渐被人们遗忘。设计人员环绕着这些功能点进行工作,考虑用什么样的技术手段把功能点制造出来。
功能点的制作细节形成了另外一份关键的文件——《xxx项目设计规格说明书》。这个《设计规格说明书》交给程序猿去进行编码。
这种做法在开发中已经形成了非常大的问题。
首先。面对这种《需求规格说明书》,设计人员已经无法知道最初的需求是什么。假如这个《需求规格说明书》中的功能点没有出现互相矛盾的情况。而他们串起来却和用户的需求不同。设计人员没办法发现这种情况。编码人员也无法发现。
假如測试也是依据这个《需求规格说明书》来做的。測试人员也发现不了。直到最后客户看见这个程序展如今他们面前。
需求的分析须要在随后的过程中不断得到反馈,传统的过程不是没有反馈,而是反馈的时间太长了。
其次,因为设计人员已经无法知道主要的需求是什么,也就无法对业务进行建模。
这种需求分析是以开发者的须要为核心的,可是结果恰恰妨碍了开发者对需求的理解。
假设开发者对用户的业务过程不甚了解,他们仅仅有一种选择:不要试图去了解需求了,直接依照这些功能点做吧。
于是,他们建立的对象模型就不是以需求为核心的。而是以功能、界面为核心的。我见到过非常多这种系统,开发者确实有非常高的抽象思维水平,程序中设计了非常巧妙的控制器和界面,能够非常方便的进行开发和变更。只有业务层的对象非常简陋,一旦发生实际业务的变更。仍然十分辛苦。
更大的困难发生在维护程序的时候。
假设有一个移动通信公司须要制造一个系统,用来解决手机用户入网的问题。这个需求有以下几个要点:
1:用户付钱,得到一个SIM卡和一个号码,把这个SIM卡装到手机里就能够通话。
2:营业员收的钱要记录下来,提供给稽核人员,现金和帐目必须是平的。
3:用户付的话费要划入他自己的帐户,能够打印票据。
4:用户要在入网合同上签字,然后营业员把合同归档。
这几个要点都是和通信公司的商业利益直接相关的。没有牵涉到不论什么系统实现方式。
假设不考虑通信公司内部的业务规范,实现方案能够有几十种,以下列举两种:
1:SIM卡发给营业员。用户入网的时候。选择一个号码。然后付钱。
营业员把SIM卡号码和电话号码输入系统,在交换网络上进行注冊,这个SIM卡就能够通话了。
然后各种费用记入各人帐户,合同归档。
2:SIM卡在下发给营业员之前。先在交换网络上和注冊。而且已经预先设置了一定的话费。
用户选择了这个号码,付钱之后直接SIM卡拿走就能够打电话了。
营业员事后再输入用户的合同资料,费用计入各人帐户。合同归档。
这两种方案在实现过程上是不同的。因此具有不同的功能点。比方另外一种方案中的SIM卡在出售之前是能够进行通话的,所以必须对这种号码的通话费用进行监控。这个功能在第一种方案中是根本不须要的。而且两种方案在帐目的核对方式上差别也是比較大的。这两种方案是不同的功能点的集合。他们完毕的是同一个业务需求。
系统在开发阶段假设没有保留用户的业务需求情况,而是仅仅留下一个功能点的列表。会给维护人员带来成非常大的困难。维护人员无法从这样一堆功能点中发现最初的需求是什么样子。
各位能够试试,假设我们忘记上面的四个需求要点。仅仅看以下的某个实现方案。从这个复杂的实现过程中。我们非常难知道用户如今的需求究竟是什么。一旦需求发生了变化,这些功能点就会出错,或者是功能点的时序发生意料不到的错误,或许帐目核对不上了,或许是用户拿走的SIM卡不能打电话了。
看不见需求在哪里,不知道手里这段代码会触动需求的哪根神经。维护人员的痛苦大部分来源于此。
“不要紧,客户记得自己的需求。
”可是客户通常不懂技术,即使他们懂技术,他们也不知道系统是怎样实现的。
假设开发者依靠客户提出新需求的解决方式,结果就是让软件project变成“生物project”。到最后是钱基本花光,人基本累死,甲乙两方感情基本破裂。
软件开发必须划分成几个过程,可是各个步骤应该有一个统一的核心——业务需求。
在需求调查阶段要搞清楚用户的业务需求,为了达到这个目的。能够提问回答,能够对用户进行跟踪採訪,或者做一个demo给用户看看,终于的目的是为了搞清楚用户在做什么事。遇到了什么问题,程序应该去解决什么问题,这就是这一阶段的工作。
然后開始进行设计,设计系统的逻辑结构和物理结构,逻辑结构要符合需求的概念。各个对象互相调用要能够实现需求中的业务过程。同一时候物理结构划分合理,符合实际的分布状况,能够达到要求的的性能,业务过程的物理执行方式合理高效。
这一阶段仍然是以业务需求为核心。
接下来是编码。
首先是编写一些基础设施,比方网络通信、数据库、文件的读写、分布式计算,这些基础设施和业务需求没有什么关系,有非常多现成的框架,借助这些框架我们能够尽快度过这个黑暗的阶段。
然后编写业务对象,这时候业务需求中的一些概念逐步出如今代码中。接着这些业务对象串接起来,实现业务过程,如今业务需求又回到了人们的视野其中。
业务需求是什么,怎样实现,在这里一目了然。最后将这些过程在UI或者接口中调用。将功能提供给用户或者别的系统。
測试更是要环绕着业务需求来进行,正常的业务流程应该产生正常的结果,假设缺少某个资源,或者输入了不合适的数据。应该出现业务含义明白的异常。而且系统的业务对象是处在一个独立的层次上,与UI和基础设施没有非常大的关联,这样能够方便的採用自己主动化的測试方法。
这种系统维护起来一定少非常多痛苦。