1、 现在的应用和以前大不一样。现在的应用是一种庞大的集成，包括跨平台，网络，数据库等等，而且新技术的出现越来越快，任何人都无法精通甚至是掌握全部技术。简单例子：现在有Windows,Unix,Linux等平台，有SQL Server,Oracle,Sybase等数据库，有C++,VB,Delphi等工具，谁能全部精通呢？如果不能，那么如何确定是Windows+SQL Server+Delphi好还是Unix+Oracle+C++合适？
2、 客户没有需求。我做过银行、电信等大客户及各种小客户，他们无一另外的说"我要做一个OA系统"，"我要做一个企业网"，"我要做一个……"。可他们无法确定要实现什么，因为很少有用户是真正由于业务的需求而做项目的；而且他们也不清楚能够实现什么(因为他们不懂notes,不懂企业网)。
3、 需求与环境的变化。由于在项目开发前客户没有实质性的需求，加上软件开发人员不熟悉客户的业务，就导致在开发过程中需求的不断变化，严重时将导致分析与设计作废。
4、 对象化的工具和过程化的程序现在的开发工具已经很对象化了，而我们开发的程序却很过程化。也就是说你虽然努力的模块化，层次化，可只要运行环境有所变化，你还要不断地修改再修改。
上述的实际情况说明我们确实需要把实际中的做法修改一下。一个项目如果做到了80%的时候才真正明确这个系统是什么样子的话，我认为是设计者的失败。所以在设计阶段不但应该做好传统做法的各种文档和论证，而且，应该做一些具体的设计工作。比如，系统的整体运行设计及系统各功能模块的具体设计。而且这些设计应当都有详细的设计说明书。当这些说明书完成后，应当能做到：随便找个程序员他都能只通过看某功能模块的设计说明书就能够开始代码的开发而不用再重新思考该怎样去做了，程序员在这里就真的只是一个设计者的实现工具。当然，也象某些兄弟说的那样，现在的系统都越来越繁杂、越来越庞大、越来越向集成性质靠拢，似乎是没有多少人能掌握具体用什么做效果如何，但关键就在这里。莫非真的没有人能做到这点吗？非也！只不过是目前的显示情况是，设计人员的水平偏低，有些公司的设计人员根本就没有多少的开发经验，他又怎能了解太多的系统呢。
系统设计在目前看来似乎是个拿钱多干活少的工作，这是不正常的现象。培养一个程序员根本不用花多大的力气，一个人只要不太笨不太蠢，给他一个机会，相信就能掌握某门技术或方法。但要掌握若干种方法，就不是能够通过速成解决的了。问题也在于此。目前似乎所有的系统设计人员都能够设计所有的东西。其实不然。很多人都有知识的局限性，这就决定他只能对某些方向的东西做出决策和设计。客户固然不知道他要做什么，但我们应该知道。如果在前期能够多接触用户、多深入实际，把设计人员当成客户工作中的一员，他就能够真正了解到客户的需求，当然也就能够为他做出合适的设计。
至于说到各种系统之间的好坏对比，我想，任何东西都没有绝对，有的只是某些方面的权衡。比如性能或空间的权衡、价格和性能的权衡和功能侧重上的权衡等等如此而已。计算机里的东西没有哪一样的存在不是包含了这种权衡在内的。虽然从商务上似乎总想说服用户什么东西好什么东西不好，其实从技术上讲无所谓好和不好，有的只是区别及该区别所针对的问题而已。这就象有人总在争论Linux和Window到底谁好一样。或许从"技术"上讲，Linux比Window好，但这其实并不公正，因为漂亮的GUI界面和友好的人际交互同样应该是"技术"中应该考虑到的一部分。把所有的东西结合起来一看就知道没有绝对的好。所以，不见得非要在用户决定之前由系统设计的人员事先来为各种方案做个排队，只需要了解用户的需求，然后从大方向上决定一个方向再做具体设计就可以了。
在这里我只从过去的实践角度举例来说，至于理论方面实在没时间深入。首先，认同两个说法：
1. 项目(或说工程)有三个主要方面：功能，时间，成本。
2. 系统分析的任务：将用户的业务逻辑转化为程序逻辑，计算时间和成本。
让我们来做一个概要设计：
1) 功能：简单的信息发布系统。
2) 系统分析员根据项目的时间和成本，在充分权衡各种方案的利弊的基础上提出SQLSERVER+CORBA+DELPHI的方案……用户很满意，OK，开始详细设计：
1) 为方便用户的安装使用三层结构。
2) 客户端包含信息分布和查询两个模块。
3) 使用各种图或语言描述各种函数，过程，模块，层次……一切顺利，开始编码……编码完成，用户试用，这时用户提出：在客户端要能实时跟踪信息的变化，而你却发现DELPHI的CORBA不支持回调！转用其它方按时间上不可能，补救措施也不灵(比如使用timer，但客户的网络环境不允许多个用户的频繁刷新)，怎么办？
分析一下问题出在哪里：
1) 有人会说系统分析员不真正了解客户的需求，可这不可能(项目时间的限制)也不现实(不可能让分析员到每个岗位都去操作一下)。
2) 有人会说系统分析员的知识和经验不足，可现实却是分析员认为应该的客户觉得没必要，而客户觉得必须的分析员又不可理解。这是不同的工作造成的，俗话说隔行如隔山。
3) 有人会说系统分析员的水平不够，可问题绝大部分是出在细节而不是大方向上，掌握全部细节可能吗？这就是一个长期困扰我的问题：细节(而不是方向)往往成为成功与失败的关键(注意，这里的成功是包含了时间和成本的)，而细节是不可能全部发现与分析清楚的。
如何在这种不完整的需求上构造完整的系统呢？或是根本不可能呢？这种问题我遇到过多次──当然都是别人做的设计。但我认为这个过程中不足的地方就是：把东西做死了，没有切实地为用户着想。很多人在做设计时，可能考虑的最多的是实现上的方便，而不是系统的扩展及更新。需知道，用户的需求是在不断变化的，如果总是在设计前就"善意"地替用户假设，是难以预料后事的结局的。所以我想，在设计阶段就因该把可能出现的问题都摆到桌面上讨论，包括其特点、效果和后果，而不是自以为是地、好心地替用户"假设"。其实一个系统设计的优劣，其系统的扩展性能是一个很重要的指标，一个单纯就事论事地针对某件事情而做出的"专用"系统是没有任何远见的
文章来源于领测软件测试网 https://www.ltesting.net/
