Drei Tipps: mit Requirement Engineering IT-Projekte sauber aufsetzen

Requirements Engineering (RE), auch als „IT-Anforderungs-Ingenieurwesen“ bekannt, ist seit einigen Jahren die Antwort auf die Frage, wie wir es in der IT-Welt schaffen, Projekte erfolgreicher durchzuführen. Die Methode vereint Erhebung, Dokumentation, Validierung und die Verwaltung von Anforderungen an ein IT-System unter einem Dach. Drei wertvolle Tipps von Felix Holzke, Senior Consultant bei NTT DATA.

Requirements Engineering verspricht ein Fundament für die reibungslose Umsetzung eines IT-Projektes zu sein. Schlussendlich soll Requirements Engineering absichern, dass der Auftraggeber das erhält, was er sich gewünscht hat, als er das Projekt ins Leben rief. Die saubere Aufnahme der Anforderungen an ein IT-System ist eine komplexe und kommunikative Herausforderung. Von seitenlangen Wunschzetteln bis zur Aussage „eh klar“ wird das ganze Spektrum der Zusammenarbeit abgedeckt.

Wie lassen sich Stolpersteine umgehen, die eine Umsetzung der fachlichen Anforderungen in ein IT-System behindern? Welche Punkte sind besonders kritisch zu Beginn eines IT Projekt, und sollten klar geregelt werden?

Tipp 1: Stakeholder zum Mitmachen bewegen

Auf die Frage was das neue System leisten soll, antworten die Mitarbeiter in den Fachbereichen oft: „Das neue System soll funktionieren, wie das Alte auch.“ Die Aufgabe eines Requirements Engineers ist es, aus diesen generellen Aussagen die Detailaspekte herauszuarbeiten. Damit diese Art der Kommunikation und Dokumentation von allen Beteiligten unterstützt wird, ist es entscheidend, die Rückendeckung der Stakeholder und des Projektmanagements zu bekommen. In der Praxis hat es sich als großer Vorteil herausgestellt, beim Stakeholder von Anfang an ein Bewusstsein dafür zu schaffen, dass alle Anforderungen so klar wie möglich formuliert sein müssen. Requirements Engineering nimmt Anforderungen auf Basis eines Methodenbaukastens sachlich und umfassend auf. Darüber hinaus sollte die Projektverantwortlichen ein erstes Gefühl für verschiedene Arten und Kategorisierungen bekommen. Im Kano-Modell gibt es beispielsweise die drei Anforderungstypen Basis-, Leistungs- und Begeisterungsanforderungen. Diese haben unterschiedlichen Einfluss darauf, wie der Stakeholder die Qualität des schlussendlich erstellten IT-Produkts beurteilt.

Tipp 2: Klare Trennung von was und wie

Anforderungen aus den Fachbereichen sind häufig sehr generisch. Sie definieren Prozesse und gewünschte Ergebnisse aus ihrer eigenen Perspektive. Beispielsweise „Wir möchten Kundendaten im Formular erfassen.“ Requirements Engineering soll zunächst die Erwartung des Fachbereichs verstehen und beschreiben, was das System umsetzen soll. Im ersten Schritt geht es aber noch nicht darum wie es das System realisieren soll. Wichtig ist hier zunächst welche Kundendaten, wann und in welcher Form erfasst werden sollen sowie welche Ausprägungen es gibt. Umgangsprachliche Formulierungen werden dazu mit Hilfe von Satzschablonen in einfachster Form in einer Excel-Tabelle katalogisiert. Die Aufgabe des Requirements Engineers ist es, das Problem des Stakeholders in positiver Form als Fähigkeit des künftigen Systems zu formulieren. Aber eben noch nicht in erster Phase zu erklären, wie das System diese Anforderung umsetzt. Zum Beispiel bewegen sich User Stories auf dieser Ebene, die als Gutes Beschreibungs¬mittel in der agilen Methodik Scrum propagiert werden. Nachdem das Problem dokumentiert und mit dem Fachbereich abgeglichen ist, kann der Requirements Engineer die Anforderungen in eine fachliche IT-Lösung übersetzen: Hierzu stehen Mittel wie Anwendungs- und Aktivitätsdiagramme oder ausformulierte Use-Case-Spezifikationen zur Verfügung. Diese Formen der Dokumentation sind noch unabhängig von der späteren technischen IT-Lösung. Aber wo liegt die Trennlinie zwischen anwendungsbasiertem fachlichen Konzept und dem „IT“- oder „DV“-Konzept, für das klassischerweise Systemarchitekten zuständig sind?

Tipp 3: Grenze zwischen Fachlichkeit und IT

Da Fachbereiche und Manager klassischerweise in Bildern und weniger in Abläufen denken, ist es Aufgabe des Requirements Engineers, im Hintergrund bereits die technischen Möglichkeiten des Zielsystems zu eruieren – aber noch nicht konkret zu beschreiben. Welches IT-System genutzt wird, ist hier außen vor. Er wird als Übersetzer der Bilder für die Systeme genutzt. Neben der Beschreibung, was der Nutzer tut, muss der Requirements Engineer alle Aktionen aufnehmen, die das System vollzieht. Diese werden so formuliert, das sie auf klassische papierbasierte Aktenverarbeitung abbildbar sind. Hierzu gehören etwa Tätigkeiten wie Formular mit Kundenname ausfüllen, Formularinhalte prüfen, mehrere Formulardaten verschmelzen, Folgeformular ablegen, Zwischenformular vernichten. Wie die IT diese Anforderungen dann technisch umsetzt, und wie der Prozess im System abläuft, gehört dann eindeutig in die Verantwortung der IT.

Im Idealfall sind in der Spezifikation abwechselnd die Interaktion zwischen einem Akteur und dem IT-System im Rahmen eines sogenannten Normalablaufs beschrieben. Empfehlenswert ist bei der Formulierung, sich auf solche immer gleich benannten Objekte und ihre Eigenschaften zu beziehen. Diese hat der Requirements Engineer in der Strukturperspektive für das System definiert, meist in Form eines UML-Klassendiagramms. Aufgabe eines Requirements Engineer ist es, darauf zu achten, dass die formulierten Anforderungen eindeutig, widerspruchsfrei und testbar sind. So muss beispielsweise zuerst ein Kundenname erfasst werden, bevor eine daraus erzeugte Kundennummer überhaupt weiterverarbeitet werden kann. Die Spezifizierung der Ausnahmesituationen (fachliche Fehlersituationen) darf dabei keinesfalls unterschätzt werden. Ihre Beschreibung beeinflusst signifikant das Bild, welches Tester, Auftraggeber und Entwickler vom IT-System haben und vermeidet Diskussionen beim Test und der Abnahme des Produkts. Denn das ist Requirements Engineering: Teure Korrekturtätigkeiten im Projektverlauf vermeiden. Den Stakeholder-Wunsch mit dem ersten Anlauf erreichen.