Teil 3: Prüfen, Abstimmen und Verwalten von Anforderungen

Prüfen und Abstimmen

Wie in Teil 2 der Blog-Serie beschrieben, wurden die wichtigsten Anforderungen des Projekts ermittelt. Außerdem wurde festgelegt, wie diese Anforderungen dokumentiert werden.

Mit dem Aufnehmen und Dokumentieren der Anforderungen ist es allerdings nicht getan. Ein Anforderungsmanager muss jederzeit darauf achten, dass z. B. die Widerspruchsfreiheit zu anderen Anforderungen gewährleistet ist. Ebenso muss ein gemeinsames Verständnis über die jeweilige Anforderung unter den Stakeholdern herbeigeführt werden, um zukünftige Konflikte zu vermeiden. Deshalb müssen sie einer stetigen Prüfung unterliegen und können erst als (für den Moment) geprüft betrachtet werden, wenn die Aspekte Inhalt, Dokumentation und Abgestimmtheit durch die Stakeholder freigegeben wurden. Ergeben sich Änderungen an einer Anforderung, muss eine erneute Prüfung erfolgen.

Bevor die Entwickler mit der Umsetzung beginnen, ist es wichtig, dass die Anforderungen inhaltlich und formal korrekt beschrieben sind. Die Business Analysten aus den Fachbereichen waren Experten auf ihrem Gebiet und hatten weitreichende Entscheidungskompetenzen, sodass eine zügige inhaltliche Abstimmung der Anforderungen möglich war. Die formale Prüfung der Anforderungen war meine Aufgabe. Bei diesem Qualitätscheck standen folgende Themen im Vordergrund:

Verwalten von Anforderungen

Anforderungen durchlaufen während des Produktentstehungs- und -lebenszyklus‘ verschiedene Status wie etwa „erstellt“, „geändert“, „zurückgewiesen“, „freigegeben“, „getestet“ oder „erledigt“. Ebenso haben sie zahlreiche weitere Attribute wie Termine, Versionen, Referenzen und Prioritäten mit zum Teil sich ändernden Werten während der Projektlaufzeit. Denkbar ist auch, dass Anforderungen in anderen Projekten wiederverwendet werden.

Für ein Kleinstprojekt kann man sicherlich gut mit Tabellen und Listen arbeiten. Steigen Komplexität und Anzahl der Beteiligten, stößt man damit an Grenzen. Dann müssen Tools zum Einsatz kommen.

Dies können sowohl einfache Ticket-Systeme oder auch mächtige Requirements Engineering Werkzeuge sein. Individuelle Workflows, Zugriffsrollen, automatische Versionierung, Konsistenzprüfungen oder die reine Verfolgbarkeit sind in größeren Projekten erforderlich, aber in einfachen Listen praktisch nicht abbildbar.

Wie schon beschrieben, nutzten wir in dem Projekt Tabellen mit ausgewählten Attributen. Wichtig war, den Überblick darüber zu behalten, womit sich die einzelnen Mitarbeiter beschäftigten, an welchen Stellen sich Anforderungen gerade änderten oder welche Anforderungen final freigegeben wurden. Wir investierten morgendlich ungefähr 30 Minuten in ein Statusmeeting und brachten uns gegenseitig auf den aktuellen Stand. Dies bewahrte die Projektmitarbeiter auch davor, in alte Muster zurückzufallen. Aufkeimende Fehlinterpretationen oder komplexe Abhängigkeiten konnten sofort erkannt und aufgelöst werden.

Der Go-Live-Termin wurde schlussendlich gehalten, wenn auch mit geringerem Funktionsumfang, als sich die Auftraggeber gewünscht hatten. Dafür war das Ergebnis aber erfolgreich getestet und abgenommen. Nach demselben Prinzip wurden auch noch die restlichen Funktionen spezifiziert, implementiert, getestet und ausgeliefert.