需求管理之被遗忘的需求

      现实世界里非常多人分析需求的过程就相似于这位专家。他们把注意力放在用户提出的功能点上。而对用户的实际需求没有兴趣。有不少软件公司和程序猿，事实上都在做相似的基因project。假设这个专家把注意力放在生产队长的业务需求上，而不是太在乎他提出的功能点。他会说：“我认识一个卖拖拉机的，能够带你去看看。”

      软件的维护为什么这么痛苦。一个非常重要的原因在于：需求已经被遗忘了。

      需求是对用户具有直接商业价值的活动。而不应该牵涉到不论什么的功能实现方式。实现同一个需求能够使用多个方案。每一个方案有自己的功能方式，在某个方案中至关重要的功能点，或许在还有一个方案中根本无关紧要。

      瀑布式的开发过程，首先是由一批懂得用户业务的专家去调查用户的需求，分析出这个系统应该具有哪些功能，形成一个非常关键的文件——《xxx系统需求规格说明书》。客户认可了这个《说明书》，在上面签字盖章，增加合同附件，到时候项目验收就以此为准。

这时候。需求就已经分解成了一个个功能点，从这时候開始，需求本身就渐渐被人们遗忘。设计人员环绕着这些功能点进行工作，考虑用什么样的技术手段把功能点制造出来。

功能点的制作细节形成了另外一份关键的文件——《xxx项目设计规格说明书》。这个《设计规格说明书》交给程序猿去进行编码。

      这种做法在开发中已经形成了非常大的问题。

      首先。面对这种《需求规格说明书》，设计人员已经无法知道最初的需求是什么。假如这个《需求规格说明书》中的功能点没有出现互相矛盾的情况。而他们串起来却和用户的需求不同。设计人员没办法发现这种情况。编码人员也无法发现。

假如測试也是依据这个《需求规格说明书》来做的。測试人员也发现不了。直到最后客户看见这个程序展如今他们面前。

需求的分析须要在随后的过程中不断得到反馈，传统的过程不是没有反馈，而是反馈的时间太长了。

      其次，因为设计人员已经无法知道主要的需求是什么，也就无法对业务进行建模。

这种需求分析是以开发者的须要为核心的，可是结果恰恰妨碍了开发者对需求的理解。

假设开发者对用户的业务过程不甚了解，他们仅仅有一种选择：不要试图去了解需求了，直接依照这些功能点做吧。

于是，他们建立的对象模型就不是以需求为核心的。而是以功能、界面为核心的。我见到过非常多这种系统，开发者确实有非常高的抽象思维水平，程序中设计了非常巧妙的控制器和界面，能够非常方便的进行开发和变更。只有业务层的对象非常简陋，一旦发生实际业务的变更。仍然十分辛苦。

      更大的困难发生在维护程序的时候。

     假设有一个移动通信公司须要制造一个系统，用来解决手机用户入网的问题。这个需求有以下几个要点：

     1：用户付钱，得到一个SIM卡和一个号码，把这个SIM卡装到手机里就能够通话。

     2：营业员收的钱要记录下来，提供给稽核人员，现金和帐目必须是平的。

     3：用户付的话费要划入他自己的帐户，能够打印票据。
     4：用户要在入网合同上签字，然后营业员把合同归档。

     这几个要点都是和通信公司的商业利益直接相关的。没有牵涉到不论什么系统实现方式。

假设不考虑通信公司内部的业务规范，实现方案能够有几十种，以下列举两种：

      1：SIM卡发给营业员。用户入网的时候。选择一个号码。然后付钱。

营业员把SIM卡号码和电话号码输入系统，在交换网络上进行注冊，这个SIM卡就能够通话了。

然后各种费用记入各人帐户，合同归档。

     2：SIM卡在下发给营业员之前。先在交换网络上和注冊。而且已经预先设置了一定的话费。

用户选择了这个号码，付钱之后直接SIM卡拿走就能够打电话了。

营业员事后再输入用户的合同资料，费用计入各人帐户。合同归档。

     这两种方案在实现过程上是不同的。因此具有不同的功能点。比方另外一种方案中的SIM卡在出售之前是能够进行通话的，所以必须对这种号码的通话费用进行监控。这个功能在第一种方案中是根本不须要的。而且两种方案在帐目的核对方式上差别也是比較大的。这两种方案是不同的功能点的集合。他们完毕的是同一个业务需求。

      系统在开发阶段假设没有保留用户的业务需求情况，而是仅仅留下一个功能点的列表。会给维护人员带来成非常大的困难。维护人员无法从这样一堆功能点中发现最初的需求是什么样子。

各位能够试试，假设我们忘记上面的四个需求要点。仅仅看以下的某个实现方案。从这个复杂的实现过程中。我们非常难知道用户如今的需求究竟是什么。一旦需求发生了变化，这些功能点就会出错，或者是功能点的时序发生意料不到的错误，或许帐目核对不上了，或许是用户拿走的SIM卡不能打电话了。

     看不见需求在哪里，不知道手里这段代码会触动需求的哪根神经。维护人员的痛苦大部分来源于此。

   “不要紧，客户记得自己的需求。

”可是客户通常不懂技术，即使他们懂技术，他们也不知道系统是怎样实现的。

假设开发者依靠客户提出新需求的解决方式，结果就是让软件project变成“生物project”。到最后是钱基本花光，人基本累死，甲乙两方感情基本破裂。

      软件开发必须划分成几个过程，可是各个步骤应该有一个统一的核心——业务需求。

     在需求调查阶段要搞清楚用户的业务需求，为了达到这个目的。能够提问回答，能够对用户进行跟踪採訪，或者做一个demo给用户看看，终于的目的是为了搞清楚用户在做什么事。遇到了什么问题，程序应该去解决什么问题，这就是这一阶段的工作。

      然后開始进行设计，设计系统的逻辑结构和物理结构，逻辑结构要符合需求的概念。各个对象互相调用要能够实现需求中的业务过程。同一时候物理结构划分合理，符合实际的分布状况，能够达到要求的的性能，业务过程的物理执行方式合理高效。

这一阶段仍然是以业务需求为核心。

     接下来是编码。

首先是编写一些基础设施，比方网络通信、数据库、文件的读写、分布式计算，这些基础设施和业务需求没有什么关系，有非常多现成的框架，借助这些框架我们能够尽快度过这个黑暗的阶段。

然后编写业务对象，这时候业务需求中的一些概念逐步出如今代码中。接着这些业务对象串接起来，实现业务过程，如今业务需求又回到了人们的视野其中。

业务需求是什么，怎样实现，在这里一目了然。最后将这些过程在UI或者接口中调用。将功能提供给用户或者别的系统。

     測试更是要环绕着业务需求来进行，正常的业务流程应该产生正常的结果，假设缺少某个资源，或者输入了不合适的数据。应该出现业务含义明白的异常。而且系统的业务对象是处在一个独立的层次上，与UI和基础设施没有非常大的关联，这样能够方便的採用自己主动化的測试方法。

     这种系统维护起来一定少非常多痛苦。