先说一个小笑话。有一个生产队队长，他对专家说：“现在我们生产队的地越来越多，牛越来越忙不过来了。我想要这么一种牛，他吃的草和普通牛一样多，但是干的活是普通牛的十倍。”专家说：“这种牛是可以造出来的，现在有基因工程。”队长说：“好吧，你给这造几头这样的牛。”于是专家找到了生物实验室，让生物实验室的人搞一个基因工程，把牛造出来。于是工程浩大，投资无法保证，合作多半是不愉快的收场。
现实世界里很多人分析需求的过程就类似于这位专家，他们把注意力放在用户提出的功能点上，而对用户的实际需求没有兴趣。有不少软件公司和程序员，其实都在做类似的基因工程。如果这个专家把注意力放在生产队长的业务需求上，而不是太在乎他提出的功能点，他会说：“我认识一个卖拖拉机的，可以带你去看看。”
软件的维护为什么这么痛苦，一个很重要的原因在于：需求已经被遗忘了。
需求是对用户具有直接商业价值的活动，而不应该牵涉到任何的功能实现方式。实现同一个需求可以使用多个方案，每个方案有自己的功能方式，在某个方案中至关重要的功能点，也许在另一个方案中根本无关紧要。
瀑布式的开发过程，首先是由一批懂得用户业务的专家去调查用户的需求，分析出这个系统应该具有哪些功能，形成一个非常重要的文件——《xxx系统需求规格说明书》。客户认可了这个《说明书》，在上面签字盖章，加入合同附件，到时候项目验收就以此为准。这时候，需求就已经分解成了一个个功能点，从这时候开始，需求本身就渐渐被人们遗忘。设计人员围绕着这些功能点进行工作，考虑用什么样的技术手段把功能点制造出来。功能点的制作细节形成了另外一份重要的文件—— 《xxx项目设计规格说明书》。这个《设计规格说明书》交给程序员去进行编码。
这样的做法在开发中已经形成了很大的问题。
首先，面对这样的《需求规格说明书》，设计人员已经无法知道最初的需求是什么。假如这个《需求规格说明书》中的功能点没有出现互相矛盾的情况，而他们串起来却和用户的需求不同，设计人员没办法发现这样的情况，编码人员也无法发现。假如测试也是根据这个《需求规格说明书》来做的，测试人员也发现不了。直到最后客户看见这个程序展现在他们面前。需求的分析需要在随后的过程中不断得到反馈，传统的过程不是没有反馈，而是反馈的时间太长了。
其次，由于设计人员已经无法知道基本的需求是什么，也就无法对业务进行建模。这样的需求分析是以开发人员的需要为核心的，可是结果恰恰妨碍了开发人员对需求的理解。如果开发人员对用户的业务过程不甚了解，他们只有一种选择：不要试图去了解需求了，直接按照这些功能点做吧。于是，他们建立的对象模型就不是以需求为核心的，而是以功能、界面为核心的。我见到过很多这样的系统，开发者确实有很高的抽象思维水平，程序中设计了非常巧妙的控制器和界面，可以很方便的进行开发和变更。唯独业务层的对象非常简陋，一旦发生实际业务的变更，仍然十分辛苦。
更大的困难发生在维护程序的时候。
假设有一个移动通信公司需要制造一个系统，用来解决手机用户入网的问题。这个需求有下面几个要素：
1：用户付钱，得到一个SIM卡和一个号码，把这个SIM卡装到手机里就可以通话。
2：营业员收的钱要记录下来，提供给稽核人员，现金和帐目必须是平的。
3：用户付的话费要划入他自己的帐户，可以打印票据。
4：用户要在入网合同上签字，然后营业员把合同归档。