Agiles Requirements Engineering
Neuerdings ist es in Mode, sogar auf Requirements Engineering-Konferenzen einen Abgesang auf das Requirements Engineering zu singen. Laut dem agilen Manifest¹ ist die Software wichtiger als die Dokumentation, das Reagieren auf Änderungen wichtiger als einen Plan zu verfolgen, Kommunikation wichtiger als Prozesse, Verträge und Werkzeuge. Und was ist eine Anforderungsspezifikation anderes als eine Dokumentation, ein Plan, ein Vertrag und ein Werkzeug? Also weg damit?
Anforderungen und Requirements Engineering werden immer gebraucht
Wer die Anforderungsspezifikation mit den Anforderungen gleichsetzt, begeht denselben Fehler wie derjenige, der die Wanderkarte mit der Landschaft verwechselt. Es handelt sich in beiden Fällen um ein Abbild unter Weglassung irrelevanter Details.
In jedem Projekt, ganz gleich in welchem, ist es unabdingbar, die Anforderungen der Stakeholder zu kennen. Denn diese sollen ja erfüllt werden. Ob und wie man sie aufschreibt, ist eine andere Frage. Aber kennen muss man sie. Dass man zu diesem Zweck kommunizieren muss, steht außer Zweifel.
Eisenhower sagte über Pläne: „Planning is everything, plans are nothing”. Genauso ist es auch beim Requirements Engineering. Das Wichtigste ist nicht die Spezifikation, die am Ende dabei herauskommt, sondern die Tatsache, dass man miteinander über die Anforderungen gesprochen hat.
Und die Kunst, zu richtigen, vollständigen und widerspruchsfreien Anforderungen zu gelangen, kann man ruhig immer noch Requirements Engineering nennen. Auch diejenigen, die für die „Abschaffung“ des Requirements Engineerings plädieren, schlagen neue Begriffe wie „Digital Design“ (Kim Lauenroth) oder „Digital Business Analysis“ (Ursula Meseberg) vor. Die Tätigkeit als solche soll nicht wegfallen, sondern sich anderer und zusätzlicher Methoden bedienen.
Agiles Requirements Engineering in Reinform
Auch in agilen Projekten ermittelt man die Anforderungen, um sie umzusetzen. Requirements Engineering nach der reinen Lehre von Scrum funktioniert so, dass möglichst wenig aufgeschrieben wird. Das Wissen soll vor allem in den Köpfen der Teammitglieder existieren. Da alle im kleinen Kreis regelmäßig miteinander kommunizieren, genügen User Storys oder allgemeiner Backlog Items als kurze Erinnerungsnotiz für die Anforderungen, über die ausführlich gesprochen wurde. Zu den User Storys wird eine minimale Anzahl an Attributen notiert wie z.B. Story Points und / oder geschätzter Nutzen. Das war’s dann.
Das agile Requirements Engineering in dieser Form ist ein sehr schönes Idealbild dessen, was man mindestens aufschreiben sollte. Das heißt, man sollte nicht vergessen, dass eine bestimmte Anforderung überhaupt existiert, und falls man bereits irgendeine Schätzung dafür durchgeführt hat, sollte diese Arbeit nicht verloren gehen. Das ist das Mindeste.
Die Grenzen des agilen Requirements Engineering
Doch das Mindeste genügt oft nicht. Schließlich ist die agile Arbeitsweise ideal für kleine Teams und für Technologien, deren Komplexität gering genug ist für kurze Iterationen. Jedoch verlangt manches Projekt ein größeres Team, eine umfangreiche Architekturplanung, die Analyse von Sicherheitsanforderungen oder eine längerfristige Releaseplanung.
Darum haben sich innerhalb der agilen Welt Methoden und Prinzipien neu entwickelt, teilweise bekannte Requirements Engineering Methoden in neuem Gewand. Das Storymapping beispielsweise ist doch die gute alte Geschäftsprozessanalyse mit einfachen Mitteln. Auch die Spezifikation der Anforderungen auf mehreren Abstraktionsebenen kehrt mit agilem Namen wieder. Hinzu kommen Artefakte wie Personas, Qualitätsanforderungen, Glossare und die Definition of Ready als Qualitätskriterien für den Review der Anforderungen – pardon: der Backlog Items.
Ordnung ins Chaos: CPRE RE@Agile
Um die unübersichtliche Vielfalt an neuen Praktiken des agilen Requirements Engineering zu ordnen, und auch passende klassische Techniken auszuwählen, die sich im Agilen bewährt haben, hat das IREB (International Requirements Engineering Board) zwei Standards mit dem Titel CPRE RE@Agile entwickelt – den RE@Agile Primer und das Advanced Level RE@Agile.
Das Prinzip ist dasselbe wie bei den anderen CPRE-Standards: Sie stellen einen Werkzeugkasten dar, aus dem man sich bei Bedarf passend bedient. Dazu werden Artefakte und Techniken vorgestellt und deren Einsatzmöglichkeiten diskutiert. Dazu kommt der philosophische Hintergrund des Ganzen sowie die Diskussion konkreter praktischer Fragen, insbesondere die Skalierung des agilen Arbeitens für größere Teams.
Es kommt darauf an …
Nun fragen mich die Teilnehmer/innen in der Schulung gerne, woher man denn wisse, wann welche Technik und welches Dokument nötig sind. Das kommt darauf an … Einfache Formeln oder Entscheidungsbäume dafür anzubieten, würde der Komplexität des Requirements Engineerings nicht gerecht.
Aber eine schlichte Überlegung kann man leicht anwenden: Man denkt einfach von hinten her. Wer wird wann welche Information brauchen? Aber auch: Was lässt sich aus technischer Sicht überhaupt konfigurieren? Da man hinterher immer klüger ist, macht eine Lessons Learned Analyse nach dem Projekt Sinn.
Ein typischer Spezialfall des Requirements Engineering ist z. B. das Customizing einer Standardsoftware. Wenn diese ihr spezifisches Oberflächendesign schon zwingend mitbringt, braucht man während des Requirements Engineerings über Farben und Schriftgrößen gar nicht zu sprechen. Oft liegt auch schon ein vorgefertigtes Datenmodell vor, in dem Datenfelder am besten nur noch umbenannt werden. Oder der Standardprozess einer Bestellung soll verwendet werden. Dann lässt sich das Requirements Engineering entsprechend leichtgewichtig gestalten, indem man ein Demosystem der Standardsoftware als Prototyp verwendet und nur in Freitext oder als Bild dokumentiert, wo man modifizieren möchte. Komplette Use Case Szenarios kann man sich hier sparen bzw. es verursacht wenig Freude, wenn man zunächst eine ausgefeilte Prozessanalyse anstellt mit gründlicher Berücksichtigung von Usability-Aspekten, und am Ende sieht alles aus technischen Gründen doch ganz anders aus.
Aber das Problem kannte das Requirements Engineering schon immer. Als ich noch die Anforderungen erhob, waren meine Faustformeln fürs leichtgewichtige (nicht-agile) Requirements Engineering: Ich höre auf zu spezifizieren, wenn der Programmierer nickt und sagt, er wisse, wie er es umsetzen wird. Und ich erstelle noch ein Modell, wenn wir anfangen, mit Händen und Füßen zu reden oder das Whiteboard an der Wand mit der Komplexität unserer Diskussionen überfordert ist. Dann bestand hier offensichtlich noch Spezifikationsbedarf, und dann wählte ich diejenige Notation, die sich für den Sachverhalt am besten eignete.
Auch bevor man sich in der agilen Entwicklung auf stichwortartige Notizen beschränkte, bestand in Projekten ein Bedarf an leichtgewichtigen Spezifikationen, in denen nur genau so viel geschrieben stand, wie später gebraucht wurde. Verwirrende Diagramme, nutzlose Informationen und widersprüchlicher Text waren nicht nur unnötig, sondern richteten sogar Schaden an.
Fazit
Die agile, auf das Allernötigste beschränkte Anforderungsspezifikation ist in vielen Fällen zu schlicht. Als erster Versuch sind diese Ansätze jedoch gar nicht falsch. Da man in der Agilität seine Arbeitsweise ohnehin iterationsweise bewertet und verbessert, kann man im Sprint Review bemerken, wenn Informationen, Diagramme oder Tätigkeiten gefehlt haben. Um dann kompetent die richtigen Praktiken auszuwählen, die das beobachtete Problem lösen, ist es nötig, sich mit der Vielfalt an agilen und klassischen Requirements Engineering Methoden auszukennen.
Hinweise:
Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.
[1] Agiles Manifest
Alles Wichtige über Requirements Engineering auf 37 Seiten jetzt als Download zum Mitnehmen.
Im t2informatik Blog hat Dr. Andrea Herrmann weitere Beiträge veröffentlicht, u. a.
Die größten Hindernisse im Requirements Engineering
Die Inspektion der Spezifikation
7 IT-Anwendungsfälle mit ChatGPT
Dr. Andrea Herrmann
Dr. Andrea Herrmann ist seit 2012 freiberufliche Trainerin und Beraterin für Software Engineering. Sie hat mehr als 28 Berufsjahre in Praxis und Forschung.
Frau Dr. Herrmann war zuletzt als Vertretungsprofessorin an der Hochschule Dortmund tätig, sie hat mehr als 100 Fachpublikationen veröffentlicht und hält regelmäßig Konferenzvorträge. Sie ist offizielle Supporterin des IREB-Board, sowie Mitautorin von Lehrplan und Handbuch des IREB für die CPRE Advanced Level Zertifizierung in Requirements Management.