Was sind IT-Projekt Anforderungen?

Ein wesentlicher Teil der Zeit wird – besser gesagt sollte – für die Analysephase aufgewendet (werden). In dieser Phase werden die meisten Fehler mit teils immenser Auswirkung auf Qualität, Zeit und Kosten verursacht, während Fehler in der Testphase „nur mehr“ gefunden werden können. Folgende Bilder sollen das verdeutlichen.

Es ist dabei grundsätzlich unerheblich, ob ein System gekauft und eventuell angepasst oder neu entwickelt wird. Ohne zu wissen, was das geplante System leisten muss, kann weder ein Zukauf noch eine Eigenentwicklung die benötigten Anforderungen korrekt abdecken.

Eine Umsetzungsphase lässt sich in vier grobe Teile unterteilen – Analyse/Anforderungen, Entwurf/Design, Implementierung und Test. In jeder dieser Phasen kann alles richtig gemacht werden oder es entstehen Fehler durch Missverständnisse, fehlerhafte Umsetzung oder durch Unvollständigkeit etc.

Die einzige Möglichkeit, zu einem (möglichst) fehlerfreien Produkt zu kommen ist es, in allen Phasen alles richtig zu machen:

Werden nun Fehler nur in der Testphase gemacht, führt dies zu einem zumindest scheinbar fehlerhaften Produkt:

Die Korrektur ist vergleichsweise einfach – es müssen nur jene Tests wiederholt werden, die fehlerhaft durchgeführt wurden oder fehlerhafte Ergebnisse geliefert haben. 

Fehler in der Implementierungsphase führen hingegen bereits unweigerlich zu einem fehlerhaften Produkt, unabhängig davon, ob in der nachfolgenden Testphase alles richtig gemacht wird oder vielleicht dort auch Fehler entstehen:

Konsequenz ist: Wiederholung der fehlerhaften Entwicklungsschritte plus notwendiger, unter Umständen aller zugehörigen, Tests. Wie zuvor erwähnt ist es für diese Betrachtung grundsätzlich gleichgültig, ob die Implementierung eine Entwicklung eines Systems bedeutet oder die Anpassung, Konfiguration und Modifikation eines Zukaufsystems.

Ebenso gelten obige Überlegungen für Fehler in der Designphase, sprich in jenem Projektabschnitt, wo die Architektur eines Systems geplant und festgelegt wird. Das Design kann wiederum eine Eigenentwicklung, aber auch ein Zukaufsystem betreffen. Bei Eigenentwicklungen ist die Designphase deshalb wichtig, weil hier Festlegungen getroffen werden, die sich in weiterer Folge auf die Performanz, auf die Wartbarkeit und auf die Erweiterbarkeit auswirken. Bei Zukaufsysteme muss zumindest eine Rechnerumgebung vorhanden sein oder geschaffen werden, es ist zu klären, wie die Benutzer auf das System zugreifen oder es ist zu definieren, wie der Softwarelieferant von außen Eingriffe in das System nehmen kann.

Dramatisch werden Fehler in der Anforderungsphase. Wird hier etwas falsch verstanden oder sind nicht alle Anforderungen bekannt führt dies mit Sicherheit zu einem unbrauchbaren Produkt:

Konsequenz ist: Zurück an den Start und nochmaliges Durchlaufen des teilweisen oder vollständigen Entwicklungszyklusses – beispielsweise können übersehene Anforderungen Einfluss auf das Design des Systems haben, wodurch sich umfangreiche Änderungen ergeben können.

Die obige Darstellung zeigt zwei Dinge:

• Es ist essentiell wichtig, von Beginn an alles möglichst richtig zu machen. Auch in der heutigen Zeit hat sich diese Erkenntnis noch nicht vollständig durchgesetzt und führt dazu, dass die Phasen der Analyse, der Anforderungen und des Designs mit den daraus resultierenden Konsequenzen oft vernachlässigt werden. Requirements Engineering und Business Analyse sind in den letzten Jahren zu zwei eigenständigen Disziplinen herangewachsen, um diesen Problemen zu begegnen.
• Die Kosten für Fehlerbehebungen steigen exponentiell an – je später ein Fehler entdeckt wird, desto teurer wird dessen Behebung. Man spricht von 100- bis 1000-fachen Kosten, wenn beispielsweise Fehler erst nach der Auslieferung anstelle in der Analysephase entdeckt werden.

Gleichzeitig ist es nicht wirtschaftlich, beliebig viel Aufwand in die Analyse- und Anforderungsphase zu stecken, da – ähnlich wie in der Testphase – ab einem gewissen Punkt der Nutzen nur mehr marginal im Vergleich zum Aufwand steigt: