dot.tipp - Klassisches Requirements Engineering – Fundament erfolgreicher Systeme

Warum ein Glossar sinnvoll ist?

Wir haben nun also ein paar Schritte und Ideen zum Requirements Engineering gesammelt und vielleicht auch gemerkt, dass da ganz schön viele neue Begriffe quasi vorausgesetzt werden. Oder ist uns allen klar, was ein Double-Diamond, der Root-Cause, Analysis Paralysis sind und wo wir Design Thinking einordnen sollen?

Anektoteles

Das Spannende ist, dass wir uns noch gar nicht über kundenspezifische Themen unterhalten haben. Im Kundenkontext kommen zu all den methodischen Begriffen noch eine Vielzahl ganz spezifischer Wörter und Abkürzungen daher, die ihr vielleicht nicht mal aktiv im Wortschatz habt. Also bei mir war das auf jeden Fall so, als ich zum Beispiel bei der SBB im Programm öV-Karte mit den Akronymen IPS, HAFAS, FVP oder GOM konfrontiert wurde. Zum Glück gab es ein umfassendes GOM, ein Geschäftsobjektmodell, in dem alle Begriffe detailliert erklärt wurden.

Übrigens: Anektoteles kennzeichnet Elemente in diesem Blog, bei denen ich von meiner Projekterfahrung erzähle.

Es macht folglich absolut Sinn, sich früh und dann regelmässig mit einer Form von Glossar zu beschäftigen. Ein Begriff, den ich oben eingeführt habe möchte ich definitiv erklären. Gerade weil er eine der grossen Herausforderungen für Requirements Engineers treffend erklärt. Analysis Paralysis bezeichnet das Phänomen, dass man sich in der Analyse von etwas absolut verlieren kann, quasi in einem Rabbit Hole verschwindet und nicht realisiert, dass das eigene Tun keinen echten Mehrwert mehr liefert. Das ist gerade bei Erhebungstechniken, die artefaktbasiert sind, ein grosses Risiko. Nichts ist einfacher als stundenlang Dokumente und Systeme zu analysieren. Ein Kern des Requirements Engineerings ist aber eben auch der aktive Austausch mit Stakeholdern.

By the way, als Stakeholder werden grundsätzlich alle von einem Vorhaben betroffenen Personen bezeichnet. Durch ein gezieltes Requirements Engineering sollen die Betroffenen zu Beteiligten gemacht werden. Hier in diesem Artikel verwende ich den Begriff Stakeholder aber bewusst ohne grosse Eingrenzung und in diesem Sinne als Repräsentation einer Person, die potentiell Anforderungen an eine Lösung hat.

Anforderungen dokumentieren – von Sprache zu Spezifikation

Sobald Anforderungen erhoben sind, stellt sich eine alte, immer wieder neue Frage: In welcher Form dokumentieren wir sie? Und wie schaffen wir es, dabei möglichst wenig Interpretationsspielraum zu lassen? 

Das Problem mit natürlicher Sprache

Natürliche Sprache ist unser naheliegendstes Mittel – und gleichzeitig unser grösstes Risiko. Denn Sprache ist nie eindeutig. Sie ist kontextabhängig, voller Homonyme, Synonyme, impliziter Bedeutungen und kultureller Färbung. Ein Satz wie "Der Benutzer kann das Dokument speichern" ist auf den ersten Blick trivial – bis sich herausstellt, dass niemand weiss, wohin, unter welchem Namen, mit welchen Rechten oder in welchem Format.

• Synonyme & Homonyme (Bearbeiten, Verarbeiten – oder Schimmel, Bank, Zug)

• Kontextabhängigkeit (Was heisst "zügig"?)

• Polysemie & Pragmatik ("Ich frage nur aus Neugier" … oder doch nicht?)

• Strukturelle Mehrdeutigkeit ("Ich sah den Mann mit dem Fernglas")

Das Problem ist nicht nur syntaktischer, sondern vor allem semantischer Natur. Die Syntax – also die formalen Regeln, wie ein Satz gebildet wird – lässt sich recht gut beherrschen. Doch die Semantik – die Bedeutung – bleibt flüchtig. Begriffe wie "schnell", "einfach", "sicher" wirken klar, sind es aber nicht. Was heisst "schnell" in einem medizinischen Notfallsystem? Was bedeutet "einfach" für jemanden mit Barrierefreiheitseinschränkungen?

Vom Text zur Struktur – Formale Dokumentation

Um diese Mehrdeutigkeit zu reduzieren, braucht es Formen der Formalisierung. Und das ist die eigentliche Essenz des Requirements Engineerings. Wir transformieren Sprache von einer informalen Sprache weg hin zu einer möglichst formalen Sprache, idealerweise in Form von Modellen. Eine erste Stufe bilden dabei die Satzschablonen – wie sie etwa die Sophisten eingeführt haben – diese helfen, Anforderungen in eine konsistentere Struktur zu bringen. Noch weiter gehen semi-formale und formale Modellierungssprachen wie zum Beispiel UML (Unified Modelling Language), die sowohl Syntax als auch Semantik definieren. Einige davon erlauben sogar die automatische Ableitung von Code oder Tests – unter der Voraussetzung, dass sie korrekt und diszipliniert eingesetzt werden.

Doch auch hier gilt: Die Form muss zur Organisation passen. Ein hochformalisiertes Modellierungsvorgehen bringt wenig, wenn die Beteiligten nicht mitziehen – oder die Wartung der Artefakte überhandnimmt. Ein zentraler Punkt im klassischen Requirements Engineering ist deshalb die bewusste Entscheidung über das geeignete Mass an Formalisierung. Nicht maximal, sondern passend. Eine kleine Gegenüberstellung von Dokumentationsformen haben wir im Blog, wie man Anforderungen sinnvoll (modellbasiert) beschreibt, publiziert. 

Anforderungen abstimmen – validieren, bevor es teuer wird

Eine Anforderung, so präzise sie auch formuliert sein mag, bleibt hypothetisch, bis sie abgestimmt ist. Die klassische Methode zur Validierung ist der Review – strukturiert, rollenbasiert, mit klaren Prüfkriterien. Diese Disziplin ist kein Selbstzweck, sondern schützt davor, dass falsche Annahmen zum Fundament ganzer Projektabschnitte werden.

Review-Techniken helfen, frühzeitig Klarheit zu schaffen:

• Strukturierte Reviews (Checklisten, Vier-Augen-Prinzip)

• Walkthroughs (geführt durch den/die Autor:in)

• Inspektionen (regelgeleitete, oft moderierte Prüfungen)

Anektoteles

Ein solch formal perfekt organisierter Review ist mitunter wahnsinnig kostenintensiv. Früher habe ich Anforderungslisten oder Use Cases durch einen formalen Review abnehmen lassen. Das ging dann so, dass ich das Dokument allen Review-Teilnehmenden als PDF geschickt habe. Dazu auch ein Excel (schön formatiert und ausgeklügelt gestaltet) in dem sie ihre Review Kommentare erfassen konnten. Diese habe ich dann gesammelt und alle Befunde die sofort und ohne Rücksprache verarbeitet werden können, wurden sogleich in das original Dokument eingearbeitet. Danach wurden alle Review-Teilnehmenden zum offiziellen Review eingeladen, bei den zum einen die Überarbeitung gezeigt, aber vor allem auch die Konfliktpunkte besprochen und geklärt wurden. Konnte man sich einigen, wurden auch die letzten Befunde in dem Original eingearbeitet. Das braucht viel Zeit, Terminorganisation und Kommunikation. Und vielleicht erklärt es auch, wieso das Thema Konfliktmanagement im Requirements Engineering einen solch hohen Stellenwert hat.

Im Gegensatz dazu steht der Review im agilen Kontext – etwa das Sprint Review im Scrum Framework – das stark auf das Produktinkrement fokussiert. Dort steht das Feedback zur Umsetzung im Vordergrund, nicht zur Anforderung. Der Vorteil: schnelles Lernen. Der Nachteil: Fehler in der Anforderung werden oft erst nach Aufwand sichtbar. Klassisches RE setzt hier früher an – und hat, gut gemacht, das Potenzial, viel Energie zu sparen. So gibt es eine Studie über Fehlerkosten die zum Schluss kommt, dass Fehler die in Anforderungen gefunden werden Faktor 90 günstiger zu beheben sind, wie solche im bereits erstellten Produkt. Da ich die Studie selbst nicht mehr finde, verweise ich hier auf einen Artikel aus dem Six-Sigma Kontext, der dieses Phänomen mit der "Role of Ten" anschaulich erklärt.

Anforderungen managen – leben statt ablegen

Anforderungen sind nie statisch. Sie entstehen nicht nur in der Anfangsphase, sondern verändern sich mit jedem neuen Verständnis, jeder Umsetzungsentscheidung, jedem Nutzerfeedback. Requirements Management ist deshalb mehr als Archivierung. Es ist die aktive Pflege von Anforderungen über die Zeit hinweg. Relevant für das Management von Anforderungen sind vor allem:

• Versionierung und Historie

• Nachvollziehbarkeit (Traceability): Welche Anforderung führt zu welcher Funktion / Test / Dokumentation?

• Just-in-Time-Verfeinerung: Auch im klassischen Umfeld hilfreich – wenn diszipliniert betrieben.

• Trennung von Projekt- und Produktdokumentation

Versionierung, Nachvollziehbarkeit und der bewusste Umgang mit Änderungen sind zentrale Disziplinen. Besonders in regulierten Umfeldern – etwa im Gesundheitswesen oder der Finanzindustrie – ist dies oft entscheidend für die Zulassung, Auditierbarkeit und Nachweisführung.

Anektoteles

Damals, vor langer Zeit, haben wir unsere Anforderungen in Excel geführt und verwaltet. Da gab es die Listen von Features und Requirements. Die Traceability-Matrix wurde manuell und mit der Unterstützung komplexer Excel-Formeln geführt. Pivot-Tabellen haben geholfen zu prüfen, ob jedes Features ein Requirement hat, wie der Umsetzungsgrad ist, wie die Verteilung der Requirements auf die verschiedenen Kategorieren, aber auch auf die verschiedenen Komponenten der Lösung ist. Makros und Filterlisten haben uns geholfen, die Requirements konsistent zu halten und dank cleveren Designs und Formeln waren wir im 2010 in der Lage unsere Requirements direkt im Excel in Use Stories umzuwandeln. Diese haben wir dann ausgedruckt und auf einem physischen Sprint-Board mit dem Team als Story Cards verwendet.

Requirements Management ist also ein durchaus komplexer Prozess. Heute unterstützen uns diverse Tools darin, diesen komplexen Prozess zu managen. Leider geht dabei oft vergessen, weshalb und wie das sinnvoll gemacht wird. Das zeigt sich mitunter in einem weiteren Aspekt, der Trennung zwischen projektbezogenen und produktbezogenen Anforderungen. In klassischen Projekten verschwimmt das oft. Doch je klarer wir trennen, was für ein Projekt spezifisch ist – und was langfristig für das Produkt gilt – desto nachhaltiger wird die Dokumentation. Der Grundsatz der "Just-in-Time Specification" kann hier auch im klassischen Umfeld nützlich sein – solange er nicht als Vorwand für Beliebigkeit missverstanden wird.

Fazit & Ausblick

Klassisches Requirements Engineering ist weder veraltet noch unflexibel. Es ist die Disziplin, die für viele Organisationen noch immer die grösste Wirksamkeit entfaltet – gerade dort, wo Klarheit, Nachvollziehbarkeit und Abstimmung entscheidend sind. Wer klassisch denkt, muss nicht starr arbeiten. Aber er oder sie braucht ein tiefes Verständnis dafür, wann was wie dokumentiert, abgestimmt und gepflegt werden muss – und warum.

Doch was passiert, wenn sich Anforderungen ständig ändern, Teams iterativ arbeiten und Dokumentation nur so viel sein soll, wie unbedingt nötig? Dann sind andere Ansätze gefragt.

Im zweiten Teil dieser Serie werfen wir einen Blick auf agiles Requirements Engineering: Was davon ist Mythos? Was funktioniert wirklich? Und wie lässt sich Agilität mit Anspruch auf Qualität vereinen?

Und im dritten Teil schauen wir dann auf generative KI im RE – nicht als Ersatz für Expertise, sondern als Unterstützung in einem klugen, kontrollierten Prozess.