Der Requirements-Engineer fungiert als Vermittler zwischen den Stakeholdern (Fachbereich), der eine Umsetzungsidee hat, und dem Umsetzungsbereich (meist Entwicklerteams). Bis zum Go-Live gewährleistet der Requirements-Engineer eine kontinuierliche Kommunikation zwischen den Bereichen.
Sie stehen den entsprechenden Stakeholdern jederzeit für Informationen über den aktuellen Stand zur Verfügung und übermitteln die notwendigen Informationen. Teilweise sind sie auch maßgeblich an funktionalen Tests beteiligt, da sie die Funktionalität definiert haben.
Das Anforderungsmanagement beginnt in der Ideenphase oder im Innovationsmanagement. Je nach methodischem Ansatz endet es jedoch unterschiedlich. Teilweise erstreckt sich der gesamte Anforderungsprozess bis zum Go Live (manchmal sogar bis zum End of Life). Aus meiner Sicht gehören auch Phasen nach dem Go Live, wie Betrieb, Support oder sogar das Ausphasen einer Anforderung, zu diesem Prozess.
Im Anforderungsmanagement-Prozess werden die Liefergegenstände für die einzelnen Projektphasen definiert, die dann als Governance-Punkte dienen. Ein gut strukturierter Anforderungsprozess sorgt für klare Zuständigkeiten und Aufgabenverteilung.
Das agile Manifest besagt, dass Personen und Interaktionen wichtiger sind als Prozesse und Werkzeuge. Dies wird manchmal so interpretiert, dass Prozesse und Werkzeuge keine Bedeutung haben, was meiner Meinung nach falsch ist. Ein gutes Anforderungsmanagement kann trotz einer prozessorientierten Herangehensweise zur Agilität beitragen.
Bei der Anforderungsdefinition geht es um die fachliche Analyse der Anforderungen und die Definition der Differenz zwischen dem aktuellen Zustand (Ist) und dem gewünschten Zustand (Soll). Dabei müssen auch Schnittstellen zu anderen Systemen berücksichtigt und möglicherweise neu definiert werden. Das Ergebnis wird entweder in einem Pflichtenheft oder im Product Backlog auf höherer Ebene festgehalten. In dieser Phase werden auch die ersten Abhängigkeiten zur bestehenden Software hergestellt.
Die Anforderungsdokumentation muss je nach Perspektive differenziert betrachtet werden. Aus Sicht eines Auftraggebers ist es ein Lastenheft, aus der Sicht eines Auftragnehmers ein Pflichtenheft.
Im traditionellen Projektmanagement wird aus dem Lasten- oder Pflichtenheft zunächst ein Grobkonzept erstellt und nach dessen Freigabe ein Fachfeinkonzept (FFK). Leider wird das FFK oft als Dokumentation für die zukünftige Ist-Anwendung verwendet, was zu Problemen führen kann, da Änderungen eines Entwicklers während der Entwicklung nicht ausreichend dokumentiert sind. Das kann dazu führen, dass bei Änderungen am System ein „Reverse Engineering“ erforderlich ist.
Die Anforderungsdokumentation ist jedoch im Verlauf eines Projekts ein lebendiges Objekt, insbesondere bei Verwendung agiler Methoden. Das zunächst formulierte Lasten- oder Pflichtenheft kann in Form eines „Epics“ niedergeschrieben werden. Daraus ergeben sich dann einzelne Stories, die so klein geschnitten werden, dass sie in einem Sprint umgesetzt werden können. Wenn der Entwickler (eventuell mit Unterstützung durch einen Business Analysten) diese Stories so genau dokumentiert, dass der aktuelle Ist-Zustand beschrieben wird, kann genau nachvollzogen werden, wann welche Änderungen vorgenommen wurden. Gerade diese Vorteile agiler Methoden sollten genutzt werden, um in Zukunft solide Grundlagen zu schaffen.
Im agilen Manifest wird betont, dass funktionierende Software wichtiger ist als umfassende Dokumentation. Dies ist zweifellos richtig, bedeutet jedoch nicht, dass auf Dokumentation komplett verzichtet wird, was in manchen agilen Projekten geschieht.
Die Validierung dient der Bewertung eines Produkts während oder am Ende eines Implementierungszeitraums, um sicherzustellen, dass es den Anforderungen gerecht wird. Es wird hinterfragt, ob im Laufe der Zeit das richtige Produkt entwickelt wurde. Im Projektmanagement wird dazu differenziert beantwortet, ob das Produkt den Anforderungskriterien und der Spezifikation entspricht (hier kann unter anderem das Business Model Canvas verwendet werden).
Die Validierung gibt Auskunft über die Anwendbarkeit im Hinblick auf das ursprüngliche Problem. Sie bewertet nicht nur das Produkt, sondern prüft auch den Lösungs- und Bewertungsansatz im Hinblick auf den Projektvertrag. Die regelmäßige Kommunikation in Refinements und Sprint-Reviews ermöglicht eine fortlaufende Validierung, sodass Projektänderungen frühzeitig eingeleitet werden können.
Die Anforderungsverwaltung beschäftigt sich mit Fragen wie „Wie gewährleiste ich, dass das Produkt allen Anforderungen gerecht wird und kein Aspekt vergessen wird?“ oder „Wie bestimme ich, welche Anforderungen relevant sind und wie sie zueinander in Beziehung stehen?“
Meistens werden dafür einschlägige Werkzeuge im Rahmen von Produkt- und Projektmanagement verwendet. Zum Beispiel werden Gantt-Diagramme erstellt, um Abhängigkeiten zwischen Entwicklungsschritten darzustellen (zum Beispiel ist es schwer, zu tapezieren, wenn die Wände noch nicht stehen). Diese Werkzeuge ermöglichen auch eine zeitliche Planung, die insbesondere bei traditionellen Projektmanagementmethoden gerne genutzt wird. Diese Abhängigkeiten können auch in agilen operativen Aufgabenmanagement-Tools abgebildet werden, indem die Elemente entsprechend verknüpft werden.
Neben der Darstellung der Abhängigkeiten erfolgt in der Verwaltung auch die Priorisierung der einzelnen Komponenten, um eine Grundlage für die Meilensteinplanung und damit für das Projektmanagement zu schaffen.
