Anforderungen an unternehmenskritische Software müssen schriftlich, genau und vollständig dokumentiert sein.
Welch gewaltiger Schaden entstehen kann, wenn man das nicht beherzigt, zeigen die folgenden beiden Beispiele:
- The Mars Climate Orbiter space probe failed to land on Sep 23, 1999, because its thruster control software was based on English units while the team responsible for adjusting its trajectory was using the metric system!
- A few months later, the Mars Polar Lander also experienced a setback during its landing. It was still 40 metres above its final landing point when its feet deployed, as expected, but the software interpreted it as an imminent event. As a result, the computer shut down the descent engines, leading to an abrupt crash and total loss of both mission and hardware. System engineers had advised the software developers to not rely on the transient signal from the legs of the lander as they were deploying but, apparently, they failed to document this information in the software specifications.
Quelle: Software Quality Issues, 22 Jun 2015, by Claude Y. Laporte
Beide Beispiele zeigen klar und deutlich, dass keine Anforderung
- als selbstverständlich gelten
- oder auch nur undokumentiert bleiben darf.
Es reicht auf keinen Fall, Anforderungen nur mündlich zu kommunizieren — schon allein deswegen nicht, weil später hinzukommende Tester sie dann ja nicht kennen und deswegen auch nicht gezielt verifizieren werden.
Dass guter Ausgang eines Projekts, in dem es nicht einfach nur um Prototyping gehen soll, höchst genaue Dokumentation sämtlicher Anforderungen noch vor Beginn der Implementierung zwingend voraussetzt, zeigt auch ein Projektdesaster, das SAP erlitten hat beim Versuch für die Firma Waste Management (in USA) ein neues ERP-System zu implementieren. Das Projekt endete in einem Zustand, in dem Waste Management SAP vor Gericht sogar des Betruges bezichtigte [E].
Zu welcher Komplexität sich diese juristische Auseinandersetzung schon während der ersten 2 Jahre aufgeschaukelt hat, geht hervor aus SAPs Statement We’ve spent millions so far on the Waste Management suit.
Da der Prozess schließlich mit einem Vergleich endete, der vorsah, dass SAP an Waste Management eine nicht öffentlich gemachte Summe zu überweisen hatte, kann man sich vorstellen, welch enormer Schaden in diesem Projekt für SAP, wahrscheinlich aber auch für den Auftraggeber entstanden war.
Dass das Desaster ganz wesentlich auf viel zu ungenaue Anforderungsdefinition zurückführbar war, lässt sich ablesen an folgenden 3 Fakten:
- Der Kunde (Waste Management) argumentierte: SAP gave Waste Management software that it knew was “unstable and lacking key functionality”, …
- Der Auftragnehmer (SAP) konterte: Waste management breached its contracts with SAP by failing to “timely and accurately define its business requirements”.
- Der Prozess endete mit einem Vergleich, was ja wohl nicht anderes bedeutet, als dass es Versäumnisse auf beiden Seiten gab.
ggreiter 