1995 hat die Standish Group (CHAOS Report) eine Studie veröffentlicht, laut der viele gescheiterte Projekte aufgrund unzureichend definierter Anforderungen gescheitert sind. Die saubere Definition von Anforderungen zu Beginn eines Projektes ist immer wieder eine Herausforderung. Die Erhebung, Analyse, Dokumentation und Wiederverwendung von Anforderungen wird allgemein als Anforderungsanalyse, bzw. Requirements Engineering bezeichnet.
Anforderungen werden aus Sicht des Auftraggebers definiert und legen die Eigenschaften eines Produktes fest. Sie lassen sich in drei Kategorien unterteilen:
Das Requirements Engineering steht an Anfang eines Projektes, da Anforderungen (logischerweise...) zu Beginn eines Projektes definiert werden (sollten...). Fehlerhaft definierte oder vergessene Anforderungen kosten in späteren Projektphasen sehr viel mehr Geld als zu Beginn. Das Requirements Engineering ist eine der fünf Phasen im Rahmen eines Entwicklungs- oder Integrationsprozesses von Applikationen oder Infrastruktursystemen. Vor dem ersten Schritt ist eine vorbereitende Analyse notwendig, deren Ergebnisdokument der Projektantrag mit Zielen, Inhalten, Zeit- und Ressourcenbedarf, Beschreibung der kritischen Erfolgs- und Einflussfaktoren ist.
Der Lebenszyklus einer Anforderung kann drei Phasen unterteilt werden:
Die ermittelten Anforderungen sind in jedem Fall zu dokumentieren. Je nach Art des Produktes sind unterschiedliche Dokumentationen denkbar (z.B. UML für Anwendungsfalldiagramme). Abnahmekriterien müssen definiert und Testfälle modelliert werden. Abnahmekriterien müssen testbar, vollständig und effizient sein. Das Analysemodell dient der Untersuchung und Bewertung der Anforderungen. Mit dem Analysemodell lassen sich z.B. fachliche Anforderungen prüfen und Anforderungen visualisieren. Besonders hervorzuheben ist hier der Aspekt der Qualitätssicherung. Das fachliche Modell eignet sich sehr gut zum Aufspüren von begrifflichen Unsicherheiten oder Missverständnissen. Nach der Definition von Anforderungen, Testkriterien und Testfällen, sowie der Erstellung des Analysemodells, kann ein Simulationsmodell erstellt werden. Das Simulationsmodell ist ein Prototyp. Er bildet die formulierten Anforderungen ab.
Es liegt in der Natur der Sache das sich Anforderungen ändern können, auch dann, wenn ein Projekt schon läuft. Ändern sich Anforderungen, dann ändern sich teilweise auch Projektgrenzen und/ oder Ziele. Die Änderung von Anforderungen muss in jedem Fall koordiniert geschehen. Dafür sind entsprechende Prozesse notwendig (Change Management). Änderungen werden über Änderungsanträge (Change Requests) eingeleitet. Sie dienen der Dokumentation und auch der Erläuterung der Rahmenbedingungen. Aus einem Änderungsantrag muss hervorgehen warum die Änderung notwendig ist und welche Auswirkungen die Änderung hat.
Die Archivierung, Wiederverwendung und Löschung von Anforderungen dient primär der Dokumentation. Damit wird der Entscheidungsprozess transparent und nachvollziehbar. Die Wiederverwendung hat maßgeblichen Anteil an der Wirtschaftlichkeit des Requirements Engineering. Einmal definierte Anforderungen können, sofern sauber dokumentiert, in anderen Projekten wiederverwendet werden. Das senkt den Aufwand zur Anforderungsdefinition und steigert die Effizienz des gesamten Prozesses. Anforderungen, welche veraltet sind oder nicht mehr benötigt werden, sind zu löschen. Auch dieser Vorgang muss dokumentiert werden.
Der gesamte Prozess sieht etwa so aus:
![]()
Ich hatte erst letzte Woche so einen Fall: Es wurden bereits abgestimmte Anforderungen in der Phase der Implementierung geändert, ohne dass dies an den notwendigen Stellen bekannt war. Bemerkenswert an dieser Stelle: Der Kunde selbst hatte die Anforderung in der Designphase aus Kostengründen verworfen, sie aber in der Implementierungsphase wieder eingebracht. Kollegen haben diese dann in Verbindung mit dem Account Management (!!) auf dem kurzen Dienstweg umgesetzt und nicht dokumentiert. Nun ist diese geänderte und umgesetzte Anforderung aufgefallen, und wurde aus technischer Sicht kritisch hinterfragt. Hier hat eindeutig das Change Management versagt.
Anforderungen werden aus Sicht des Auftraggebers definiert und legen die Eigenschaften eines Produktes fest. Sie lassen sich in drei Kategorien unterteilen:
- fachliche bzw. funktionale Anforderungen
- nicht-funktionale Anforderungen
- technische Anforderungen
- innovative Anforderungen
- bestehende Anforderungen
Das Requirements Engineering steht an Anfang eines Projektes, da Anforderungen (logischerweise...) zu Beginn eines Projektes definiert werden (sollten...). Fehlerhaft definierte oder vergessene Anforderungen kosten in späteren Projektphasen sehr viel mehr Geld als zu Beginn. Das Requirements Engineering ist eine der fünf Phasen im Rahmen eines Entwicklungs- oder Integrationsprozesses von Applikationen oder Infrastruktursystemen. Vor dem ersten Schritt ist eine vorbereitende Analyse notwendig, deren Ergebnisdokument der Projektantrag mit Zielen, Inhalten, Zeit- und Ressourcenbedarf, Beschreibung der kritischen Erfolgs- und Einflussfaktoren ist.
Der Lebenszyklus einer Anforderung kann drei Phasen unterteilt werden:
- Systemanalyse
- Änderungsmanagement
- Archivierung/ Wiederverwendung/ Löschung
Die ermittelten Anforderungen sind in jedem Fall zu dokumentieren. Je nach Art des Produktes sind unterschiedliche Dokumentationen denkbar (z.B. UML für Anwendungsfalldiagramme). Abnahmekriterien müssen definiert und Testfälle modelliert werden. Abnahmekriterien müssen testbar, vollständig und effizient sein. Das Analysemodell dient der Untersuchung und Bewertung der Anforderungen. Mit dem Analysemodell lassen sich z.B. fachliche Anforderungen prüfen und Anforderungen visualisieren. Besonders hervorzuheben ist hier der Aspekt der Qualitätssicherung. Das fachliche Modell eignet sich sehr gut zum Aufspüren von begrifflichen Unsicherheiten oder Missverständnissen. Nach der Definition von Anforderungen, Testkriterien und Testfällen, sowie der Erstellung des Analysemodells, kann ein Simulationsmodell erstellt werden. Das Simulationsmodell ist ein Prototyp. Er bildet die formulierten Anforderungen ab.
Es liegt in der Natur der Sache das sich Anforderungen ändern können, auch dann, wenn ein Projekt schon läuft. Ändern sich Anforderungen, dann ändern sich teilweise auch Projektgrenzen und/ oder Ziele. Die Änderung von Anforderungen muss in jedem Fall koordiniert geschehen. Dafür sind entsprechende Prozesse notwendig (Change Management). Änderungen werden über Änderungsanträge (Change Requests) eingeleitet. Sie dienen der Dokumentation und auch der Erläuterung der Rahmenbedingungen. Aus einem Änderungsantrag muss hervorgehen warum die Änderung notwendig ist und welche Auswirkungen die Änderung hat.
Die Archivierung, Wiederverwendung und Löschung von Anforderungen dient primär der Dokumentation. Damit wird der Entscheidungsprozess transparent und nachvollziehbar. Die Wiederverwendung hat maßgeblichen Anteil an der Wirtschaftlichkeit des Requirements Engineering. Einmal definierte Anforderungen können, sofern sauber dokumentiert, in anderen Projekten wiederverwendet werden. Das senkt den Aufwand zur Anforderungsdefinition und steigert die Effizienz des gesamten Prozesses. Anforderungen, welche veraltet sind oder nicht mehr benötigt werden, sind zu löschen. Auch dieser Vorgang muss dokumentiert werden.
Der gesamte Prozess sieht etwa so aus:
Ich hatte erst letzte Woche so einen Fall: Es wurden bereits abgestimmte Anforderungen in der Phase der Implementierung geändert, ohne dass dies an den notwendigen Stellen bekannt war. Bemerkenswert an dieser Stelle: Der Kunde selbst hatte die Anforderung in der Designphase aus Kostengründen verworfen, sie aber in der Implementierungsphase wieder eingebracht. Kollegen haben diese dann in Verbindung mit dem Account Management (!!) auf dem kurzen Dienstweg umgesetzt und nicht dokumentiert. Nun ist diese geänderte und umgesetzte Anforderung aufgefallen, und wurde aus technischer Sicht kritisch hinterfragt. Hier hat eindeutig das Change Management versagt.