The waterfall method prescribes the formulation of requirements as the project result of the definition phase. Ideally, there should be little further deviation from these requirements throughout the rest of the project. The development of software according to the waterfall method requires the investment of considerable time in the beginning of the project in analysing the necessary functionalities (requirements). This leads to a functional design (for more details on functional designs, see [i]). Using the functional design as a guide, the software architect makes a technical design in the design phase. The technical design includes a description of how the desired functionalities should be implemented.

Although this may appear quite straightforward, consider the following situation (example adapted from McConnell, 1996, p. 138). There is a project to produce a new automobile. As an active automobile driver, you are asked to formulate the requirements for an automobile. You consult with other drivers and create an extensive list:

• The automobile must accommodate four people.
• The automobile must have a steering wheel in the front on the drivers left-hand side, a
• brake pedal, a gas pedal and a hand brake.
• The automobile must have four wheels.
• The automobile must have white headlamps and red tail lamps. et cetera (the actual list would obviously be enormous)

Using your list as a guide, the designers develop a new design, which is subsequently built several months later. One day, as you are walking down the street, you see an automobile stopping. You realise that you neglected to include brake lamps in your list! You immediately telephone the engineer of the automobile manufacturer, who nearly explodes in reaction to your call. You maintain that it is only a small change. For the automobile manufacturers, however, it is a disaster. The automobiles that have already been made must be completely disassembled, cables must be stretched from the brake pedals to the rear, the rear of the automobile must be completely re-designed in order to accommodate the brake lamps, the boot hatches that had already been produced would have to be discarded and the list goes on.

While the example above is somewhat absurd, it reflects an almost daily reality in software development. Programmers erroneously assume that the clients, customers or users of the software that is to be developed know precisely what they want Clients erroneously assume that the software builders can make (and adapt) everything in the shortest possible time. This problem is the greatest source of conflict between customers and software builders.

The following anecdote illustrates the fact that there are many conflicts between customers and software suppliers. A beginning entrepreneur wanted to obtain legal insurance for his business. He asked about the possibilities. When the broker asked him to identify the sector in which his business was active, the entrepreneur replied, ‘IT’. Too bad, replied the broker, ’there are so many lawsuits between IT suppliers and customers that there are no insurance companies that will write legal-insurance policies for IT companies’.