At the core of the traditional approach is the assumption that someone can come up with a consistent set of requirements, which can then be decomposed into specifications and linear thought processes. The system is really what is contained in the documentation or contract specifications. People go to great lengths to insure that the requirements are exactly what the user wants. Requirements become an entity unto themselves, a focal point of litigious contention in contract work. Systems analysts assume that people who have never seen the system operate can examine paper definitions of the system and comprehend the operation of the system in their setting. Design methodologies assume that there is a single overiding point of view which drives the entire system.
Most information systems don't conform to this simplistic linear model. It may be impossible to elicit the requirements of a system sufficient to produce specifications. Users may not know what they want until they see it. External forces such as governmental regulations may provide the small change which generates enormous change in the system behavior. Once the system is installed, it may influence the users' behavior in such a way as to invalidate some of the requirements. The development process may take so long that the organization changes, markets change, or more pressing priorities arise. All in all, information systems development is a very turbulent, unpredictable process, no matter how hard we try to linearize it.
