Wir kommen langsam zum Ende unserer kleinen Blogserie RE für Einsteiger. Im letzten Teil zur Theorie behandeln wir noch das Requirements-Management, die vierte Haupttätigkeit im Requirements-Engineering.
Requirements-Management (im Folgenden kurz RM genannt) bedeutet, Informationen zu Anforderungen und anderen Dokumenten so abzulegen, dass jeder Projektbeteiligte Zugang zu benötigten Informationen hat. Sie können gar nicht „Nicht verwalten“. Ab dem Moment, zu dem Sie Dokumente ablegen, führen Sie bereits erste Verwaltungsschritte durch.
Früher oder später im Projektverlauf werden andere Projektbeteiligte auf Ihre Anforderungen zugreifen – insbesondere auch Personen, die nicht zu den Anforderungsautoren zählen. Ein Stakeholder taucht mit einem Change-Request (Änderungsantrag für eine Anforderung) im Handgepäck auf, ein Programmierer kommt auf Sie zu und erzählt Ihnen, dass eine Anforderung so doch nicht realisiert werden kann, und so weiter. Darum müssen Anforderungsdokumente jederzeit für alle Projektbeteiligten zugreifbar sein. Wir sind hier sehr nah am Thema der Dokumentation, welche wir bereits im Beitrag RE für Einsteiger (Teil 3) – Warum Dokumentation essentiell ist behandelt haben.
Doch wie sieht RM jetzt in der Praxis aus?
Um für Klarheit in unserer Anforderungssammlung zu sorgen, stellen wir erst einmal sicher, dass wir uns eindeutig auf einzelne Anforderungen beziehen können. Ein wichtiger Schritt dabei ist die Objekt-ID. Weisen Sie von Beginn an jeder Anforderung oder anderen Artefakten (Use-Cases, User-Storys, etc.), welche Sie formulieren eine eindeutige ID zu. Den Kontext der Anforderungen in so einer ID wiederzugeben ist ebenfalls von Vorteil. So ist in der Übersicht sofort ersichtlich, mit welcher Art Anforderung man es zu tun hat, z. B. LH für Lastenheft, PH für Pflichtenheft, UC für Use-Case, und so weiter. Diese Bezeichnungen waren für uns anfangs ein bisschen gewöhnungsbedürftig, doch sie helfen dabei, sich zurecht zu finden. ;-)
Beispiel für eine Anforderungs-ID:
Das Bibliothekssystem muss dem Kunden die Möglichkeit bieten, die Registrierung abzuschließen.
RQ steht in diesem Fall für Requirement, also Anforderung.
Wie Sie sehen, hat unsere Anforderung in der ID neben der Kontextinformation auch eine Nummer erhalten – und diese macht die ID erst eindeutig, denn sie wird nur einmal vergeben. Nummerieren Sie alle Anforderungen durch, während Sie diese erstellen. Falls Sie anschließend eine Anforderung, aus welchen Gründen auch immer, wieder entfernen, ziehen Sie die Nummerierung der anderen nicht nach, denn die IDs lassen sich auch zum „Verlinken“ von Anforderungen verwenden, also der Verknüpfung einer Anforderung mit anderen Informationen, um für Nachvollziehbarkeit zu sorgen.
Falls Sie also eine Anforderung verlinkt haben und die ID der Anforderung nachträglich ändern, würde das später zu großer Verwirrung führen, denn dann zeigt Ihre Verknüpfung letztendlich auf eine andere Information als ursprünglich geplant. Stellen Sie sich den Aufwand vor, wenn sie hunderte oder tausende von Anforderungen überprüfen müssen…
Requirements-Management wird umso wichtiger, je größer die Anzahl der Anforderungen ist. Rechnen Sie also damit und legen Sie ihre Anforderungen von vornherein so ab, dass sie auch in sehr großer Menge nicht an Übersichtlichkeit verlieren. Wir haben beispielsweise mit Anforderungen in Word begonnen und schnell gemerkt, dass einfaches Herunterschreiben auf Dauer nicht funktioniert. Mit Überschriften auf verschiedenen Ebenen und Einrücken wurde es etwas übersichtlicher. In der Dokumentenstruktur-Ansicht konnte man so schnell und einfach von Kapitel zu Kapitel springen.
Optimal sind Word (und andere Standard-Office Tools) für das Requirements-Management dennoch nicht. Damit Sie stets Herr Ihrer Anforderungen bleiben, empfehlen wir Ihnen den Einsatz eines geeigneten Requirements-Management-Tools. Diese haben den entscheidenden Vorteil, dass jede angelegte Anforderung und auch Änderungen zur Anforderung nachverfolgbar dokumentiert werden können. Beispielsweise ermöglicht ein RM-Tool die Versionierung jeder Anforderung. Wird eine Anforderung geändert, legt das Tool eine neue Version der Anforderung an. Sie sehen also auf den ersten Blick, ob und wie oft an einer Anforderung herum gebastelt wurde. So lassen sich Änderungen im Laufe des Projektes besser nachvollziehen und gegebenenfalls auch rückgängig machen, da die alten Versionen der Anforderung erhalten bleiben.
Für die Übersicht bilden außerdem Gliederungen ein passendes „Skelett“ für die einzelnen Anforderungen. Es gibt Standard-Gliederungen für RM, welche Sie nutzen können. Ein Beispiel sehen Sie in Abbildung 1. Der Grafik können Sie entnehmen, welche Informationen an welcher Stelle der Gliederung eingefügt werden können. Dabei handelt es sich um mehrere Arten von Informationen, nicht nur um Systemanforderungen. Auch Ziele des Projektes und bereits durchgeführte Testfälle sind integriert. Volere wurde von Suzanne und James Robertson entwickelt, andere Quellen für solche Standardgliederungen wären IEEE 29148-2011[1] und das V-Model XT[2].
Abbildung 1: Beispiel für eine mögliche Gliederung
Standardgliederungen dienen als Beispiele, wie Ihre Anforderungen und Informationen gegliedert werden können und sind nicht allgemein verpflichtend, dennoch sollten sie als Orientierungshilfe genutzt werden. Und wenn Sie merken, dass eine Gliederung nicht auf Ihr Projekt passt, können Sie diese nach Ihren Wünschen umstellen oder eine andere Gliederung verwenden.
Gliederungen sind zudem für ein das Change-Management sehr nützlich. Wenn Änderungswünsche auftreten, lassen sie sich mit einer guten Gliederung effizient verwalten, so dass die Qualität der Anforderungen auch bei größeren Veränderungen nicht leidet.
Dabei spielt auch die „Baseline“ eine wichtige Rolle. Sie können eine Auswahl an Anforderungen auf einem bestimmten Stand „einfrieren“. Eine solche Auswahl nennt man Konfiguration. Wenn eine Konfiguration alle Anforderungen für ein Release umfasst, dann spricht man von einer Baseline. Sie ist wichtig, weil Sie so auf der Basis eines konsistenten Stands der Informationen arbeiten können. Falls Ihnen also zum Beispiel auffällt, dass Sie einen Use Case mitsamt der zugehörigen Anforderungen voreilig entfernt haben, können Sie ihre Spezifikation bei Bedarf wieder auf den alten, eingefrorenen Stand zurückzusetzen.
Wenn Sie Ihre Anforderungen mit Attributen wie eindeutigen IDs, Versionsnummer und Informationen zu Autor und Quelle versehen und in eine sinnvoll aufgebaute Gliederung einsortiert haben, sind Sie in punkto Requirements-Management schon recht gut unterwegs. Natürlich gibt es noch eine ganze Reihe weiterer Techniken, vom Sichten bilden bis zum Priorisieren. Mehr dazu finden Sie in unserem Buch Requirements-Engineering und –Management: Aus der Praxis von klassisch bis agil.
Wir beenden hier erst einmal unseren Theorieteil… hier und da sind bereits einige Beispiele aus der Praxis in unseren Projekten durchgesickert, und so wird es im nächsten Beitrag auch weitergehen. Anhand einer Sammlung unserer besten und kompliziertesten ersten Erfahrungen und Herausforderungen werden wir Ihnen die Praxis zur Theorie erläutern. Freuen Sie sich auf eine spannende Erzählung! :-)
Bis bald!
Ihre SOPHISTen
————————————-