Anforderungsmanagement in unterschiedlichen Vorgehensmodellen

Herausforderungen

Anforderungsmanagement steht nach unserer Erfahrung vor der Herausforderung, wichtige Informationen mit verfünftigem Ressourcenaufwand bereitzustellen, sodass die Umsetzung von Software möglich ist.

Unsere ersten Projekte sahen dabei recht einfach gestrickt aus. Wir haben Tarifbücher gelesen, Druckstücke analysiert, und konnten auf dieser Basis die Tarifierung, Angebot und Antragsbausteine für ein Agenturtsysteme entwerfen. Dabei hatten wir die Aufgabe, sowhl die fachlichen Anforderungen zu verstehen, daraus die Analyse abzuleiten und anschließend umzusetzen und zu testen. Das Anforderungsmanagement lieferte also genau die informationen, in dem Detailierungsgrad, der für die Umsetzung und später den Test notwendig waren.

Nehmen wir eines der Folgeprojekte, etwas 80-Mann stark, damit beschäftigt, u.a. Tarifierung, Validierungen und Deckungsinformationen aus einer Host-Anwendung in eine modulare Komponente auszulagern. Das Anforderungsmanagement stand vor erheblichen Fragestellungen. Wieviel Detaillierung benötigen wir, wie können wir Anforderungen in detaillierter Form nachliefern, wie können wir während der Umsetzung, fortlaufend notwendige Entcheidung auf Basis besserer Erkenntnisse zu treffen. Die Wahl fiel auf ein inkrementelles Verfahren mit einer Vielzahl von Artfakten. Das von manchen geforderte Anpassen der Artefakte auf die Ergebnistypen, die notwendig sind, viel allerdings sehr kurz aus.

Dann kam SCRUM. Scrum forderte eine starke Fokussierung auf Sprints. Die Analyse, Umsetzung, und Test sollten innerhalb der (in diesem Fall) 2-Wochen-Sprints abgeschlossensen. Die Herausforderung war natürlich, dass die Teams Abhängigkeiten zueinander hatten, und unterschiedliche Prioritäten auf Themen setzten. Gleichzeitig sollten nur Userstories gezogen werden, von denen man auch überzeugt war, diese in einem Sprint fertigzustellen. So kamen einfach neue Userstory-Typen dazu. Aufgaben, Testaufgaben, Analyseaufgaben usw. in anderen Projekten gab es Spikes oder Elaboration-Stories.

Fokussierung auf das operative Anforderungsmanagement

Die Aufgaben im Anforderungsmanagement haben sich trotz unterschiedlicher Vorgehensmodelle nicht verändert. Die Form der Dokumentation hat sich, vielleicht auch durch neue Techniken heute verändert, allerdings auch nur unwesentlich. Was sind aus unserer Sicht wichtige Metriken beim operativen Anforderungsmanagement:

• Fachliche Anforderungen so beschreiben, dass erkennbar ist, was im täglichen Arbeitsablauf benötigt wird.
• Fachliche Anforderungen können mit Diagramme beschrieben werden, wenn so Prozesse besser beschrieben werden, fortlaufender Text ist oft schwer auf Eindeutigkeit überprüfbar.
• Fachliche Anforderungen basieren immer auf den im Markt üblichen Begriffen, und müssen die Zuordnung zu den technischen Entitäten und Prozessen leisten, denn andernfalls muss es der Entwickler leisten, und erst dann kommen die Detailfragen auf.
• Fachliche Sonderkonstellationen müssen identifiziert sein und bzgl. der Relevanz in der täglichen Arbeit qualifiziert sein.
• Es muss eine Priorisierung der Anforderungen im Team und mit den Stakeholdern möglich sein, damit festgelegt werden kann, welche Anforderungen zu welchem Zeitpunkt umgesetzt werden sollen, mit einer Priorisierung der betroffenen Drittsysteme / Anwender.
• Die fachlichen Anforderungen sind dem Business Analysten, dem Tester und dem Entwickler bekannt. Es gab die notwendige Abstimmung vor der Umsetzung, um das Wissen des Analysten an die Kollegen weiterzugeben, die das anschließend ausarbeiten und testen müssen.
• Das Anforderungsmanagement endet nicht mit einer Übergabe von Themen an die Umsetzung, da zum Umsetzungszeitpunkt immer nochmal Rückfragen kommen werden, und Umsetzungsschwierigkeiten auftreten. Daher ist für uns eine Bgleitung der Umsetzung ein wichtiger Aspekt.
• Begleitung im Test, um sicherzustellen, dass wesentliche Prüfpunkt, natürlich die Korrektheit der Umsetzung, aber auch die Validierung von Annahmen berücksichtigt werden.

Wie also auch das Vorgehensmodell aussehen mag, unser Fokus liegt darauf, für ein Umsetzungsintervall die Anforderungen soweit zu schärfen, dass eine Umsetzung zielführend ist, und im Sinne der Anforderungen eindeutig beschrieben werden kann. Dabei berücksichtigen wir auch, dass es eine Validierung von Annahmen nach der Umsetzung geben kann, insbesondere, wenn man fachliches und technisches Neuland betrifft.

Wie wir unterstützen

Unsere Berater sind iREB®-zertifiziert, und bringen das notwendige fachliche und technische Wissen mit, um Anforderungen zielgerichtet zu ermitteln. Wir hinterfragen Anforderungen, bis wir sicher sind, dass wir die Notwendigkeit verstanden, und auch gegenüber Führungskräften vertreten können. Wir stellen Anforderungen in Frage, wenn sie nicht einleuchten, und freuen uns auf partnerschaftliche Abstimmungstermine mit Experten, die die Anforderungen erläutern können. Durch diese Vorgehen wollen wir sichergehen, dass wir notwendigen Anforderungen berücksichtigen, und Anforderungen, die vielleicht aus der Historie heraus entstanden sind, angemessen bewerten können.

Wir dokumentieren unsere Anforderungen so, dass die Umsetzung und der Test möglich sind. Daher gehen wir früh in die Abstimmung mit den betroffenen Kollegen. in der Regel haben unterschiedliche Entwickler und Testkollegen auch unterschiedliche Erwartungen an Anforderungen. Wir stellen damit sicher, dass die Anforderungen von einem fachlich versierten Experten, von einem Entwickler und vom Testexperten als gemeinsame Gesprächsgrundlage verwendet werden können.