De watervalmethode schrijft voor dat in de definitiefase de eisen en wensen als projectresultaat geformuleerd worden. Idealiter geval wordt van die eisen of wensen niet of nauwelijks meer afgeweken. Bij softwareontwikkeling volgens het watervalmodel wordt er in het begin van het project veel tijd besteed aan het analyseren van de benodigde functionaliteiten (eisen en wensen). Dit leidt tot een functioneel ontwerp (voor een nadere toelichting op functioneel ontwerpen, zie bijvoorbeeld [i]). Op basis van het functionele ontwerp gaat de softwarearchitect in de ontwerpfase een technisch ontwerp maken. In het technische ontwerp wordt beschreven hoe de gewenste functionaliteiten gerealiseerd moeten worden.
Dit lijkt allemaal vrij recht toe recht aan, maar stel de volgende situatie voor (voorbeeld aangepast van McConnell, 1996, p. 138): Er is een project voor de productie van een nieuwe auto. U bent een actieve autorijder en aan u wordt gevraagd de eisen en wensen te formuleren die er aan een auto zijn. U overlegt met andere autorijders en komt met een hele lijst:
- de auto moet plaats bieden aan 4 personen
- de auto moet een stuur linksvoor hebben, een rempedaal, een gaspedaal, een handrem
- de auto heeft 4 wielen
- de auto heeft witte koplampen en rode achterlichten enz. enz. (In de realiteit zou het een enorme lijst worden.)
De ontwerpers maken op basis van uw lijst een nieuw ontwerp, dat vervolgens, maanden later, gebouwd wordt. Dan, u loopt over straat en ziet een auto remmen. U realiseert zich dat u in deze lijst vergeten bent de remlichten te noemen! U belt onmiddellijk met de ingenieur van de autofabriek die zowat ontploft van uw telefoontje. U oppert nog dat het slechts om een kleinigheidje gaat. Maar voor de autobouwers is het rampzalig. De gemaakte auto’s moeten helemaal opengemaakt worden, er moeten kabels van de rempedalen naar achteren getrokken worden, het ontwerp van de achterkant moet helemaal opnieuw om ruimte te bieden voor de remlichten, de achterkleppen die al geproduceerd zijn moeten worden weggegooid, en ga zo maar door.
Bovenstaand voorbeeld lijkt misschien wat absurd maar bij softwareontwikkeling is het bijna dagelijkse realiteit. Programmeurs gaan er ten onrechte vanuit dat de opdrachtgever, klant of gebruiker van nieuw te ontwikkelen software precies weet wat hij wil. De opdrachtgever gaat er ten onrechte van uit dat de softwarebouwers in de kortste tijd alles kunnen maken (en aanpassen). Dit probleem is de grootste oorzaak van conflicten tussen klanten en softwarebouwers.
En dat er veel conflicten zijn tussen klanten en softwareleveranciers blijkt wel uit het volgende. Een startende ondernemer wilde een rechtsbijstandverzekering voor zijn bedrijf afsluiten. Hij informeerde naar de mogelijkheden. De tussenpersoon vroeg in welke branche de ondernemer actief zou zijn, waarop hij ‘ICT’ antwoordde. “Helaas dan”, reageerde de tussenpersoon, “er zijn zo vaak rechtszaken tussen ICT- leveranciers en klanten dat er geen verzekeraar meer is die voor ICT-bedrijven een rechtsbijstandsverzekering wil afsluiten”.
