Teil 2: Anforderungsmanagement in Theorie und Praxis

Wird bereits zum Projektstart ein aktives Anforderungsmanagement aufgesetzt, können die in Teil 1 der Blog-Serie beschriebenen Probleme stark gemildert werden. Unter Anforderungsmanagement versteht man die ineinandergreifenden und wiederkehrenden Tätigkeiten Ermitteln, Dokumentieren, Prüfen und Abstimmen sowie Verwalten von Anforderungen. Ein Anforderungsmanager legt zu Beginn fest, wie diese Tätigkeiten bezogen auf den aktuellen Projektkontext ausgeführt werden. Dazu gehören sowohl geeignete Vorgehensweisen als auch die Definition der passenden Arbeits- und Ergebnisdokumente. Noch unerfahrene Anforderungsautoren, wie im Beispiel aus der Fachabteilung II, können sich daran gut orientieren. Gegebenenfalls führt ein Anforderungsmanager auch die notwendigen Arbeiten selbst durch.

Die beschriebene Projektsituation erforderte ein zügiges und individuelles Vorgehen, denn das Projekt befand sich bereits in einer fortgeschrittenen Konfliktsituation. Weder war ausreichend Zeit, um im Nachhinein umfassende Methoden und Prozesse einzuführen, noch war das Projektteam adhoc in der Lage, adäquate Spezifikationen und Modelle zu erstellen. Eine Verschiebung des Go-Live-Termins stellte keine Option dar, deshalb mussten an anderer Stelle Kompromisse gefunden werden.

In den folgenden Abschnitten möchte ich die Aufgaben des Anforderungsmanagements, und wie diese mit Blick auf die besondere Projektsituation ausgeplant wurden, beschreiben.

Ermitteln der Anforderungen

Um Anforderungen zu ermitteln muss sich ein Anforderungsmanager zunächst mit den vorhandenen Informationsquellen auseinandersetzen. Dies können Stakeholder, vorhandene Dokumente oder im Betrieb befindliche Systeme sein. Mithilfe geeigneter Techniken werden die notwendigen Informationen zusammengetragen. Je nach Situation eignen sich hier Interviews, Brainstormings, Systemarchäologie oder Beobachtungstechniken.

In meiner Situation habe ich mich gezielt auf die bereits teilweise erfassten Anforderungen und begonnenen Implementationen konzentriert und eine Priorisierung eingefordert. Daraufhin haben wir uns im Team, bestehend aus besagtem Fachbereich II und Entwicklern, zusammengesetzt und eruiert, welche die tatsächlich wichtigen Funktionen und welche weniger wichtig waren.

Mithilfe grober Schätzungen der Entwickler und Tester konnten wir dann recht früh hochrechnen, ob der Termin überhaupt noch haltbar war. So kannten wir nach einigen Runden zumindest den Funktionsumfang zum Go-Live und damit unser Ziel. Nun mussten wir es nur noch beschreiben, damit die Entwickler starten konnten.

Dokumentieren der Anforderungen

Diese Beschreibung oder auch Dokumentation der Anforderungen kann sowohl in natürlicher Sprache als auch modellbasiert (UML, BMPN, EPK, etc.) erfolgen, wobei sich eine Mischform in der Praxis am besten bewährt hat. Welche Ergebnisdokumente dabei entstehen sollen, hängt oft vom Umfeld ab. Sowohl Tabellen, Lastenhefte als auch Tickets in Online-Ticket-Systemen sind häufig anzutreffen.

In besagtem Projekt mussten wir uns auf den kleinsten gemeinsamen Nenner im Rahmen der Dokumentation verständigen, um nicht weitere Zeit zu verlieren. Dies waren Tabellen mit geeigneten Attributen sowie ein Spezifikationsdokument, ergänzt durch UML Aktivitätsdiagramme. Letztere eignen sich besonders gut, um einfach und schnell Abläufe zu dokumentieren, da sie auch für Unerfahrene leicht zu lesen und zu erstellen sind. Zudem half diese Art der Darstellung, sich auf die Standardaktivitäten zu konzentrieren und nicht ständig zu den Ausnahmefällen abzuschweifen. Dies fiel dem Fachbereich besonders schwer, da er die Standardfälle aus dem Effeff kannte und für ihn die Besonderheiten bedeutend waren. Dies war jedoch in dieser Projektsituation kontraproduktiv. Es galt erst einmal, eine 80%-Lösung zu erstellen und sich im zweiten Schritt mit Anomalien zu beschäftigen.