1. 项目(或说工程)有三个主要方面：功能，时间，成本。 　　
 
2. 系统分析的任务：将用户的业务逻辑转化为程序逻辑，计算时间和成本。 　
　
让我们来做一个概要设计： 　　

1) 功能：简单的信息发布系统。 　
　
2) 系统分析员根据项目的时间和成本，在充分权衡各种方案的利弊的基础上提出SQLSERVER+CORBA+DELPHI的方案……用户很满意，OK，开始详细设计： 　　
 
　　(1) 为方便用户的安装使用三层结构。 　　

　　(2) 客户端包含信息分布和查询两个模块。 　
　
　　(3) 使用各种图或语言描述各种函数，过程，模块，层次……一切顺利，开始编码……编码完成，用户试用，这时用户提出：在客户端要能实时跟踪信息的变化，而你却发现DELPHI的CORBA不支持回调！转用其它方按时间上不可能，补救措施也不灵(比如使用timer，但客户的网络环境不允许多个用户的频繁刷新)，怎么办？ 　
　
分析一下问题出在哪里： 　　
 
1) 有人会说系统分析员不真正了解客户的需求，可这不可能(项目时间的限制)也不现实(不可能让分析员到每个岗位都去操作一下)。
 　　
2) 有人会说系统分析员的知识和经验不足，可现实却是分析员认为应该的客户觉得没必要，而客户觉得必须的分析员又不可理解。这是不同的工作造成的，俗话说隔行如隔山。 　　

3) 有人会说系统分析员的水平不够，可问题绝大部分是出在细节而不是大方向上，掌握全部细节可能吗？这就是一个长期困扰我的问题：细节(而不是方向)往往成为成功与失败的关键(注意，这里的成功是包含了时间和成本的)，而细节是不可能全部发现与分析清楚的。 　　

　　如何在这种不完整的需求上构造完整的系统呢？或是根本不可能呢？这种问题我遇到过多次──当然都是别人做的设计。但我认为这个过程中不足的地方就是：把东西做死了，没有切实地为用户着想。很多人在做设计时，可能考虑的最多的是实现上的方便，而不是系统的扩展及更新。需知道，用户的需求是在不断变化的，如果总是在设计前就"善意"地替用户假设，是难以预料后事的结局的。所以我想，在设计阶段就因该把可能出现的问题都摆到桌面上讨论，包括其特点、效果和后果，而不是自以为是地、好心地替用户"假设"。其实一个系统设计的优劣，其系统的扩展性能是一个很重要的指标，一个单纯就事论事地针对某件事情而做出的"专用"系统是没有任何远见的。