Anforderungsmanagement ist ein bekanntes Thema zu Beginn von Projekten, um den Fokus und die Ziele eines Projektes abzugrenzen und eine Konzeption zu erstellen. Doch Anforderungsmanagement beinhaltet mehr als diese Aufga-benstellung. Was muss passieren, wenn sich im Laufe der Realisierungsphase eines Projektes Anforderungen ändern oder neuen Anforderungen hinzukom-men?

Um Projekte auch dann noch erfolgreich abschließen und steuern zu können, wird ein durchgängiges, projektbegleitendes Anforderungsmanagement benö-tigt. Was dies bedeutet und wie dies konkret aussehen kann, wird im Folgen-den anhand eines ausgewählten Beispielprojektes aufgezeigt. Für die Durchfüh-rung des durchgängigen Anforderungsmanagements hat sich insbesondere in großen Projekten die Rolle des Anforderungsmanagers als Koordinator zwi-schen den Projektmanagern, Fachbereichen und Softwarearchitekten bewährt.

Ausgangssituation

Ziel des Projektes war die Ablösung von mehreren, auf einem Host laufenden, Altsystemen bei einer Behörde. Diese Altsysteme sollten durch neue Anwen-dungen ersetzt werden. Die Initiative war Bestandteil eines Projektportfolios, welches die gesamte IT-Landschaft modernisieren sollte. Die neue Anwendung stellt das zentrale neue System für verschiedene Fachbereiche dar. Die Reali-sierungsphase der neuen Anwendung war bereits gestartet und hatte eine geplante Laufzeit von mehreren Jahren. Verschiedene Bereiche der neuen Anwendung wurden nach und nach produktiv gesetzt.

Im Vorfeld der Realisierung wurde ein ausführliches Fachkonzept erstellt, welches auch eine klare Abgrenzung zu den anderen Projekten und Systemen vorsah. Außerdem wurden Rahmenbedingungen festgelegt und die benötigten Schnittstellen klar ausgearbeitet. Die Konzeption basierte nicht nur auf Text-beschreibungen, sie bestand auch zu einem Großteil aus in Modellen beschrie-benen Geschäftsprozessen und Anforderungen. Dazu gehörten Prozess-modelle, die Unterteilung in Fachmodule, die schematische Abbildung der zu realisierenden Masken und die Zuordnung dieser Masken zu den einzelnen Prozessschritten. Mit der neuen Anwendung sollte eine optimale Unterstützung der Geschäftsprozesse für die Mitarbeiter erreicht werden.

Neben der Modernisierung der IT-Landschaft fanden in der Behörde zeitgleich weit reichende Umorganisationen statt.  Durch die fortlaufenden Veränderun-gen der Arbeitsabläufe in der Behörde ergaben sich für das Projekt ständig neue oder geänderte Anforderungen. Diese waren oftmals nur in den Fach-bereichen bekannt. Regelmäßige Meetings während der Realisierungsphase sorgten nicht nur für eine kontinuierliche Information der Fachbereiche über den Projektfortschritt und die weiteren Planungen, sondern auch für die zeit-nahe Weitergabe der neuen und geänderten Anforderungen an das Projekt-team.

OPITZ CONSULTING unterstützte das Projektteam der IT-Abteilung des Kunden sowohl beim Anforderungsmanagement als auch bei der Realisierung der neuen Anwendung.

Durchgängiges Anforderungsmanagement

Wie bei den meisten Projekten basiert auch das durchgängige Anforderungs-management auf der Aufnahme, der Analyse, der Spezifikation und der Verifikation der spezifischen Anforderungen. Dazu kommt die Kontrolle nach der Realisierung.  Die Unterschiede zu einem herkömmlichen Vorgehen erge-ben sich beim durchgängigen Anforderungsmanagement in der Ausführung durch den Projektfortschritt und den aktuellen Stand der Anforderungsumsetzung.

Bild 1: Vorgehen im durchgängigen Anforderungsmanagement 

Nach der Weitergabe der Anforderungen an das Projektteam musste durch den Anforderungsmanager zunächst grundsätzlich geklärt werden, ob die Anforde-rungen in den Kontext dieses Projektes oder zu einem parallelen Projekt innerhalb des Projektportfolios gehörten. Durch die Modernisierung der gesam-ten IT-Landschaft  war eine eindeutige Zuordnung von Anforderungen zu den einzelnen Projekten für die Fachbereiche nicht immer sofort möglich. Die sau-bere Abgrenzung des Projektes, der im Projekt zu unterstützenden Geschäfts-prozesse und die klar definierten Schnittstellen zwischen den Prozessen führten zu einer schnellen und eindeutigen Klärung der Frage. Anforderungen, die nicht zum Projektkontext gehörten, wurden an die entsprechenden Projekt-teams weitergeleitet.

Über die nächsten Schritte entschied die Art der Anforderung: Unterschieden wurde zwischen funktionalen oder nicht-funktionalen Anforderungen.

Funktionale Anforderungen

Alle dem Projekt zugehörigen funktionalen Anforderungen wurden detaillierter betrachtet und ihre Auswirkungen auf bestehende Anforderungen untersucht:

• Handelt es sich um eine neue, zusätzliche Anforderung?
• Handelt es sich um eine geänderte Anforderung?
• Macht die Anforderung bisherige Anforderungen obsolet?
• Steht die Anforderung im Widerspruch zu bisherigen Anforderungen?

Diese Fragen konnten durch die vorhandenen Modelle der Prozesse und An-forderungen schnell, einfach und vollständig analysiert werden.

Ein besonderes Augenmerk galt der Prüfung von Abhängigkeiten zwischen den neuen und bereits bestehenden Anforderungen. Als Ergebnis konnte eine starke Abhängigkeit zwischen verschiedenen Anforderungen festgestellt werden, weshalb die verschiedenen Fachmodule der neuen Anwendung teil-weise eine deutliche Verzahnung aufweisen. Zudem führen die Abhängigkeiten dazu, dass andere Module aufeinander aufbauen. Häufig erzwang die Änderung oder Ergänzung einer Anforderung die Anpassung einer ganzen Reihe von weiteren, bestehenden Anforderungen. Diese betroffenen Anforderungen erstreckten sich teilweise über mehrere Projekte. Die Verantwortung für die Abstimmung unter den verschiedenen Projektteams trug der Anforderungs-manager.

Da die Realisierung der Softwarekomponenten bereits lief, mussten auch die Auswirkungen auf die Umsetzung frühzeitig geprüft werden. Dazu war in erster Linie der Stand der Umsetzung aller direkt und indirekt betroffenen Anforde-rungen abzufragen:

(1) Waren die Softwarekomponenten schon realisiert?
(2) Läuft die Realisierung der Softwarekomponenten gerade?
(3) Sollte die Realisierung in Kürze beginnen?
(4) Bestand bis zur geplanten Realisierung noch ein größerer Zeitpuffer?

Traf der vierte Fall zu, so wurde dies weniger kritisch betrachtet. Bis zur Reali-sierung konnten die Anforderungen noch spezifiziert und verifiziert werden, ohne den Projektplan zu beeinflussen. Wenn die Realisierung in Kürze begin-nen sollte, wurden folgende Möglichkeiten geprüft:

• Welchen Umfang hat der Klärungsbedarf für die neue bzw. geänderte Anforderung?
• Ist die verbleibende Zeit ausreichend?
• Kann die Realisierung einer anderen Anforderung vorgezogen werden, um einen größeren Zeitpuffer für die Klärung zu bekommen?

Besonders kritisch und dringlich war die Festlegung des weiteren Vorgehens im zweiten Fall. Dann musste der Anforderungsmanager gemeinsam mit dem Projektmanagement entscheiden, ob zur Abstimmung der Anforderungen und zur Klärung der Widersprüche die Unterbrechung der Realisierung notwendig ist. Dies galt immer dann, wenn der Aufwand für die Realisierung hoch war und die Abstimmung der Anforderungen und die Klärung der Widersprüche ergeb-nisoffen oder tendenziell in Richtung der neuen bzw. geänderten Anforderun-gen verliefen. Erst im Anschluss an die Spezifikation und Verifikation wurden die Arbeiten an der Realisierung fortgesetzt.

Anforderungen, die sich geändert hatten und bereits umgesetzt waren, stellten nicht nur für die Motivation der Entwickler einen potentiell negativen Einfluss dar. Die exakte Klärung dieser geänderten Anforderungen und der Auswir-kungen auf die fertig gestellten Projektteile war in diesen Fällen besonders wichtig.

• Müssen Programmteile geändert werden?
• Müssen Programmteile neu realisiert werden?
• Muss eventuell sogar die Architektur geändert werden?

Diese Punkte wurden durch den Anforderungsmanager in Zusammenarbeit mit dem Architekten geklärt.

Nicht-funktionale Anforderungen

Die grundsätzlichen Fragestellungen in Zusammenhang mit der Bearbeitung von nicht-funktionalen Anforderungen unterscheiden sich nicht von der Bearbeitung der funktionalen Anforderungen. Auch bei den nicht-funktionalen Anforderungen erfolgte ein Abgleich mit den bisherigen nicht-funktionalen Anforderungen. Das Hauptaugenmerk lag jedoch auf den Auswirkungen auf die funktionalen Anforderungen und auf die Architektur. Änderungen nicht-funktionaler Anforderungen konnten sehr viele funktionale Anforderungen betreffen und den Projektstatus sowie den Projekt-Fortschritt erheblich beeinflussen.

Bild 2: Arbeitsschritte

Abwicklung der Anforderungen

In jedem Fall musste die Priorität der Anforderung genau hinterfragt werden. Jede zusätzliche Anforderung und jede vorgenommene Änderung an realisier-ten Anforderungen hatte Auswirkungen auf den Projektplan. Die Verschiebun-gen im Projektplan bedurften erneuter Absprachen des Anforderungsmanagers mit den Fachbereichen. Die Fachbereiche mussten dann entscheiden, wichtige Meilensteine zu verschieben, auf die Realisierung anderer Anforderungen zu verzichten oder die Realisierung von Anforderungen zu verschieben.

Ebenso wichtig wie die Anpassung der Projektpläne war die vollständige und korrekte Dokumentation der neuen bzw. geänderten Anforderungen. Die Über-arbeitung der Modelle für die Prozesse und Anforderungen war entscheidend, um bei der nächsten Anforderung einen konsistenten Zustand für die Analyse zu haben.

Eine zusätzliche Herausforderung für das Anforderungsmanagement bestand in der Vertragsgestaltung zwischen der Behörde und OPITZ CONSULTING. Denn neben den Wartungsverträgen für bereits in Produktion befindliche Anwen-dungsteile existierten Werksverträge für die Entwicklung weiterer Anwendungs-funktionalitäten und -Module. Nach der fachlichen Klärung und Bearbeitung der Anforderungen musste also anschließend geprüft werden, ob die Erweite-rungen und Anpassungen der Anwendung im Rahmen der Wartungsverträge zu bearbeiten waren, Inhalte von Werksverträgen werden mussten oder gar als Gewährleistung umzusetzen waren. In einigen Fällen erzwangen geänderte Anforderungen Anpassungen von noch laufenden Werksverträgen.

Fazit

Ein durchgängiges Anforderungsmanagement in Projekten ist notwendig, um frühzeitig Auswirkungen zu erkennen und entsprechend reagieren zu können. Die werkzeugbasierte Modellierung der Prozesse und Anforderungen ermög-lichte in dem sehr komplexen Projekt eine schnelle und einfache Analyse der Anforderungen und deren Auswirkungen, so dass eine zeitnahe Anpassung der Projektpläne erfolgen konnte. Durch den Steuerungsmechanismus des durch-gängigen Anforderungsmanagements konnten ungeachtet der langen Laufzeit des Projektes nachträgliche Erweiterungen und Anpassungen vermieden wer-den. Die Anwendung entsprach zur Fertigstellung den aktuellen Anforderungen der Fachbereiche.

Colette Ziller ist Dipl.-Betriebswirtin und Seniorberaterin bei Opitz Consulting in München.