Lessons Learned im Requirements Engineering #1: Versionierung und Baselines

Ich habe mich entschieden, gelegentlich kurze Gedanken aus meiner Erfahrung im Requirements Engineering zu teilen – kleine Lessons Learned aus verschiedenen Projekten: Dinge, die gut funktioniert haben, und Dinge, die ich beim nächsten Mal anders machen würde.

Das erste Thema: Versionierung und Baselines.

Auch im CPRE-Syllabus des IREB spielt Requirements Engineering Configuration Management eine wichtige Rolle. Ein wichtiger Bestandteil davon ist die Versionierung von Anforderungen und die Definition von Baselines in Requirements-Dokumentationen.

In der Praxis wird diese Disziplin jedoch oft vernachlässigt – sowohl in Projekten, in denen ich als Business Analyst (BA) / Requirements Engineer (RE) gearbeitet habe, als auch in Projekten, in denen ich als Entwickler tätig war. Ehrlicherweise muss ich sagen, dass ich teilweise auch selbst Teil dieses Problems war – meist aufgrund von Zeitdruck, neuen Prioritäten oder begrenzter Kapazität im Team, aber auch, weil Versionierung und Baselines nicht immer explizit als Qualitätskriterium für Anforderungen festgelegt waren.

Wenn Anforderungen keine klare Versionierung und Baselines haben, entstehen schnell Probleme:

der Unterschied zwischen dem vorherigen und dem aktuellen Zustand eines Systems oder einer Anforderung ist schwer verständlich der Zweck oder die Art einer Änderung geht verloren – z. B. ob es sich um eine Erweiterung, ein Refactoring oder eine neue Anforderung handelt das Onboarding neuer BAs wird erschwert, da bisherige Änderungen oder Implementierungen nicht klar nachvollziehbar sind

Anforderungen entwickeln sich weiter – ihre Historie sollte sich ebenso strukturiert weiterentwickeln.

-> BEISPIEL (ohne klare Versionierung / Baseline):

Ursprüngliche Anforderung / Product Backlog Item: Das System überprüft die Benutzer-ID. Späterer Stand der Dokumentation: Das System überprüft die Benutzer-ID und validiert zusätzlich das Format der Eingabe.

Ohne klare Versionierung oder Baselines kann ein neuer BA oder PO später nur schwer nachvollziehen:

ob diese Änderung eine neue fachliche Erweiterung darstellt ob sie aus einem Bugfix entstanden ist ob es sich um ein Refactoring der bestehenden Logik handelt oder ob die Änderung auf eine regulatorische Anforderung zurückgeht

Die Nachvollziehbarkeit des Änderungskontexts geht verloren.