Gute Anforderungen sind mehr als gute Sätze

Eine Anforderung kann sprachlich klar, eindeutig und formal korrekt formuliert sein – und trotzdem nur begrenzten Wert für die Entwicklung haben. Sie kann exakt beschreiben, was ein System leisten soll, ohne erkennen zu lassen, warum diese Eigenschaft benötigt wird, aus welchem übergeordneten Bedarf sie entstanden ist, welche anderen Anforderungen davon abhängen oder wie später nachgewiesen werden soll, dass sie tatsächlich erfüllt wurde.

Genau darin liegt eine der Schwierigkeiten des Requirements Engineering. Gute Anforderungen entstehen nicht allein durch gute Formulierungen. Ihr eigentlicher Wert zeigt sich erst dann, wenn sie in einen nachvollziehbaren Zusammenhang eingebettet sind, der Stakeholder-Bedarf, technische Entscheidungen, Architektur, Umsetzung und Verifikation miteinander verbindet.

ISO/IEC/IEEE 29148:2018 betrachtet Requirements Engineering entsprechend als lebenszyklusübergreifenden Prozess und nicht lediglich als Tätigkeit zur Erstellung einer Spezifikation. Die Norm beschreibt Anforderungen und die damit verbundenen Informationsobjekte über den Lebenszyklus von Systemen und Software hinweg.

Damit verändert sich auch die Frage, woran sich die Qualität einer Anforderung messen lässt. Entscheidend ist nicht nur, ob ein Satz gut geschrieben ist, sondern ob die Anforderung im Entwicklungsprozess verstanden, begründet, verfolgt, verändert und überprüft werden kann.

Der gute Satz ist nur der Anfang

Die sprachliche Qualität einer Anforderung bleibt wichtig. Unklare Begriffe, mehrere Aussagen in einem Satz, subjektive Formulierungen oder nicht messbare Eigenschaften erzeugen Interpretationsspielraum und damit technisches Risiko. Es ist deshalb sinnvoll, Anforderungen nach Regeln zu formulieren und systematisch auf Verständlichkeit, Eindeutigkeit und Verifizierbarkeit zu prüfen.

INCOSE widmet diesem Thema mit dem Guide to Writing Requirements ein eigenes etabliertes Werk. Die aktuelle Version behandelt unter anderem die Eigenschaften gut formulierter Needs und Requirements, Regeln für deren Formulierung sowie Attribute, die zusammen mit dem eigentlichen Requirement Statement eine vollständige Requirement Expression bilden können.

Gerade dieser letzte Punkt ist entscheidend. Eine Anforderung besteht im Engineering-Kontext nicht zwangsläufig nur aus ihrem sichtbaren Satz. Zu ihr können weitere Informationen gehören, beispielsweise Quelle, Begründung, Priorität, Status, Verantwortlichkeit, Beziehungen zu anderen Anforderungen oder die vorgesehene Art der Verifikation.

Der Satz ist damit der Kern der Anforderung, aber nicht ihre gesamte Bedeutung.

Eine formal perfekte Formulierung kann beispielsweise lauten, dass ein System innerhalb einer bestimmten Zeit reagieren muss. Ohne weiteren Kontext bleibt jedoch offen, warum genau dieser Wert erforderlich ist. Stammt er aus einem übergeordneten Systemverhalten, einer externen Schnittstelle, einer Sicherheitsbetrachtung oder lediglich aus einer frühen Designannahme? Solange diese Herkunft nicht nachvollziehbar ist, lässt sich auch schwer beurteilen, was geschieht, wenn der Wert später geändert werden soll.

Gute Formulierung reduziert Mehrdeutigkeit. Gute Requirements Engineering schafft zusätzlich Zusammenhang.

Vom Bedarf zur technischen Anforderung

Anforderungen entstehen nicht im luftleeren Raum. Am Anfang steht üblicherweise ein Bedarf, eine Erwartung, ein Ziel, eine Einschränkung oder ein Problem, das gelöst werden soll. Im Laufe der Entwicklung werden daraus zunehmend konkrete technische Aussagen, die auf verschiedene Systemebenen, Funktionen und Komponenten verteilt werden.

Diese Transformation ist keine reine Übersetzungsaufgabe. Sie erfordert Interpretation und technische Entscheidungen.

Ein Stakeholder kann beispielsweise erwarten, dass ein System in einer bestimmten Situation schnell reagiert. Damit ist zunächst ein gewünschtes Verhalten beschrieben, aber noch nicht zwangsläufig festgelegt, welche Komponente welche Reaktionszeit einhalten muss. Erst durch Architektur, funktionale Zerlegung und technische Analyse entstehen daraus konkrete Anforderungen an einzelne Systemelemente.

NASA beschreibt Technical Requirements Definition entsprechend als iterativen und rekursiven Prozess, bei dem Stakeholder-Erwartungen schrittweise in validierte technische Anforderungen überführt und auf nachgelagerte Produkt- und Komponentenebenen weiterentwickelt werden. Dabei sollen nicht nur Funktionen und Performance beschrieben werden, sondern auch Beziehungen, Schnittstellen, Randbedingungen und relevante Interaktionen mit anderen Systemen und Menschen.

Damit erhält jede technische Anforderung eine Vorgeschichte. Sie wurde aus etwas abgeleitet, zugeordnet oder aufgrund einer technischen Entscheidung zusätzlich notwendig.

Diese Vorgeschichte zu kennen ist wichtig, weil sie erklärt, welche Rolle die Anforderung im Gesamtsystem spielt. Ohne sie kann eine Spezifikation zwar viele technisch plausible Aussagen enthalten, aber dennoch unklar lassen, ob diese Aussagen gemeinsam tatsächlich den ursprünglichen Bedarf abdecken.

Requirements Engineering muss deshalb beide Richtungen beherrschen: vom Bedarf in die technische Konkretisierung und von einer konkreten technischen Anforderung wieder zurück zu der Frage, warum sie überhaupt existiert.

Eine Anforderung braucht Kontext

Ein Requirement Statement wird häufig bewusst kurz und präzise gehalten. Das ist sinnvoll, weil Anforderung und Erklärung unterschiedliche Aufgaben erfüllen. Die Forderung selbst sollte eindeutig festlegen, was erwartet wird; ihre Begründung darf dagegen erklären, weshalb diese Erwartung besteht.

Gerade deshalb ist es problematisch, die Begründung einfach wegzulassen.

NASA empfiehlt beim Definieren technischer Anforderungen ausdrücklich, die Rationale festzuhalten. Dazu können der Grund für die Anforderung, zugrunde liegende Annahmen, Beziehungen zum Nutzungskonzept sowie Design Constraints gehören. Wenn eine Anforderung beispielsweise eine konkrete Implementierungsmethode vorschreibt, sollte nachvollziehbar sein, warum die Lösungsfreiheit an dieser Stelle bewusst eingeschränkt wurde.

Diese Kontextinformation wird besonders dann wertvoll, wenn sich das Projekt verändert. Während der ursprünglichen Erstellung wissen die Beteiligten meist noch, warum eine bestimmte Entscheidung getroffen wurde. Monate oder Jahre später ist dieses Wissen möglicherweise nicht mehr verfügbar, weil Teammitglieder gewechselt haben, sich Architekturentscheidungen verändert haben oder die ursprüngliche Diskussion nicht mehr präsent ist.

Dann steht nur noch der Satz im Tool.

Ohne dokumentierte Entscheidungslogik kann eine Anforderung dadurch einen scheinbar unumstößlichen Charakter erhalten, obwohl sie möglicherweise lediglich aus einer längst überholten Annahme entstanden ist. Umgekehrt kann eine scheinbar unkritische Anforderung geändert werden, obwohl sie eine wichtige Systementscheidung absichert, deren Zusammenhang inzwischen nicht mehr sichtbar ist.

Rationale bedeutet deshalb nicht, jeden technischen Gedankengang ausführlich zu dokumentieren. Sie bedeutet, genügend Kontext zu erhalten, damit spätere Entscheidungen weiterhin auf dem ursprünglichen technischen Verständnis aufbauen können.

Traceability ist mehr als eine Sammlung von Links

Traceability wird in Projekten schnell auf eine formale Forderung reduziert: Anforderungen müssen miteinander verlinkt werden. Daraus entstehen Parent-Child-Beziehungen, Referenzen zwischen System- und Softwareanforderungen oder Verknüpfungen zu Testfällen.

Allein die Existenz solcher Links garantiert jedoch noch keine sinnvolle Nachvollziehbarkeit.

NASA definiert Traceability grundsätzlich als erkennbare Beziehung zwischen logischen Objekten wie Anforderungen, Systemelementen, Verifikationen oder Aufgaben und bezeichnet bidirektionale Traceability als die Möglichkeit, eine Anforderung sowohl zu ihren übergeordneten Ursprüngen als auch zu ihren abgeleiteten Anforderungen zurückzuverfolgen. Im Requirements Management wird diese Nachvollziehbarkeit über Stakeholder-Erwartungen, technische Anforderungen, Komponentenanforderungen, Designdokumente sowie Testpläne und -prozeduren hinweg erhalten.

Der technische Nutzen liegt damit nicht im Link selbst, sondern in der Frage, die sich mit ihm beantworten lässt.

Bei einer abgeleiteten Anforderung sollte nachvollziehbar sein, welchen Anteil eines übergeordneten Bedarfs sie erfüllt. Bei einer Systemanforderung sollte erkennbar sein, welche nachgelagerten Elemente sie realisieren. Bei einer Änderung sollte sichtbar werden, welche weiteren Anforderungen, Architekturelemente oder Verifikationsaktivitäten möglicherweise betroffen sind.

Traceability wird dadurch zu einem Modell der Abhängigkeiten innerhalb des Entwicklungsprozesses.

Eine große Matrix mit Tausenden von Links kann trotzdem wenig Nutzen erzeugen, wenn die Bedeutung dieser Beziehungen unklar ist. Umgekehrt kann eine vergleichsweise einfache Trace-Struktur sehr wertvoll sein, wenn eindeutig definiert ist, welche Information eine Beziehung ausdrückt und wofür sie genutzt wird.

Die relevante Qualitätsfrage lautet deshalb nicht: Sind die Anforderungen verlinkt?

Sie lautet vielmehr: Können wir aus diesen Beziehungen technische Fragen zuverlässig beantworten?

Ohne Begründung wird Veränderung teuer

Anforderungen verändern sich. Stakeholder präzisieren ihre Erwartungen, Architekturentscheidungen werden angepasst, technische Randbedingungen ändern sich, Tests liefern neue Erkenntnisse und bisher unbekannte Abhängigkeiten werden sichtbar.

Requirements Management muss deshalb nicht verhindern, dass Anforderungen verändert werden. Es muss dafür sorgen, dass Änderungen kontrolliert und ihre Auswirkungen verstanden werden können.

Genau an dieser Stelle treffen Traceability und Rationale aufeinander.

Wenn eine Anforderung geändert werden soll, müssen zunächst zwei unterschiedliche Fragen beantwortet werden. Die erste lautet, woher die Anforderung stammt und warum sie existiert. Die zweite lautet, welche anderen Elemente von der Veränderung betroffen sein könnten.

Die Rationale beantwortet den ersten Teil, die Traceability unterstützt den zweiten.

Fehlt eines von beiden, wird Impact Analysis schnell zu einer manuellen Suchaufgabe. Teams müssen dann aus Dokumenten, Versionshistorien, Architekturwissen und persönlichen Erinnerungen rekonstruieren, weshalb ein Wert ursprünglich festgelegt wurde und welche Konsequenzen eine Änderung haben könnte.

NASA betrachtet Requirements Management deshalb ausdrücklich als lebenszyklusübergreifenden Prozess, in dem Änderungen an Requirements-Baselines bewertet und genehmigte Änderungen kontrolliert umgesetzt werden. Gleichzeitig soll die Konsistenz zwischen Requirements, Concept of Operations sowie Architektur beziehungsweise Design erhalten bleiben.

Eine gut strukturierte Requirement-Landschaft reduziert damit nicht nur Fehler beim ursprünglichen Schreiben. Sie reduziert ebenso die Kosten zukünftiger Entscheidungen, weil Zusammenhänge nicht jedes Mal neu rekonstruiert werden müssen.

Verifikation beginnt beim Schreiben

Die Verifikation einer Anforderung findet zeitlich häufig viel später statt als ihre Definition. Methodisch sollten beide Aktivitäten jedoch eng miteinander verbunden sein.

Bereits beim Schreiben einer Anforderung sollte die Frage gestellt werden, wie später objektiv festgestellt werden kann, ob sie erfüllt wurde. Wenn darauf keine belastbare Antwort möglich ist, ist häufig auch die Anforderung selbst noch nicht ausreichend verstanden.

NASA zählt die individuelle Verifizierbarkeit zu den Eigenschaften validierter Requirements und verlangt bei der Requirements-Definition ausreichend Information, damit nach der Realisierung des Produkts geprüft werden kann, ob die Forderung erfüllt wurde. Das NASA Systems Engineering Handbook enthält deshalb nicht nur eine Checkliste zum Schreiben guter Requirements, sondern auch eine Requirements Verification Matrix als eigenes unterstützendes Konzept.

Diese frühe Verbindung verändert die Qualität der Diskussion.

Eine Aussage wie „Das System muss schnell reagieren“ erscheint bereits sprachlich problematisch. Spätestens bei der Frage nach der Verifikation wird jedoch unmittelbar sichtbar, was fehlt: Welche Reaktionszeit ist zulässig, zwischen welchen Ereignissen wird gemessen, unter welchen Randbedingungen gilt der Wert und welches Ergebnis wird als erfüllt betrachtet?

Verifikation wirkt damit rückwärts auf die Requirement-Qualität.

Sie zwingt dazu, die Forderung aus der Perspektive des späteren Nachweises zu betrachten und verhindert, dass unklare Erwartungen erst am Ende des Entwicklungsprozesses zu einem Testproblem werden.

Gute Requirements Engineering betrachtet einen Testfall deshalb nicht lediglich als nachgelagertes Artefakt. Die grundsätzliche Verifikationslogik sollte bereits bei der Definition der Anforderung mitgedacht werden.

Verifikation und Validierung beantworten unterschiedliche Fragen

Die Begriffe Verifikation und Validierung werden im Engineering häufig verkürzt gegenübergestellt. Gerade im Requirements Engineering lohnt sich jedoch eine genauere Unterscheidung, weil beide Begriffe sowohl auf Anforderungen selbst als auch später auf das realisierte System angewendet werden können.

Auf Ebene der Anforderungen spricht ISO/IEC/IEEE 29148 von Requirements Verification, wenn geprüft wird, ob einzelne Anforderungen und das Requirement-Set gut geformt sind. Dazu gehören Eigenschaften wie Eindeutigkeit, Konsistenz, geeignete Struktur und grundsätzliche Verifizierbarkeit. Requirements Validation betrachtet dagegen, ob diese Anforderungen tatsächlich das richtige System beschreiben – also ob sie den beabsichtigten Bedarf und die Erwartungen der Stakeholder angemessen abbilden.

Damit können Anforderungen formal sehr gut formuliert und trotzdem inhaltlich ungeeignet sein. Ein Requirement kann eindeutig, messbar und technisch widerspruchsfrei sein, aber dennoch auf einer falschen Interpretation des Stakeholder-Bedarfs beruhen. Umgekehrt kann eine fachlich richtige Erwartung so unklar beschrieben sein, dass sie sich weder zuverlässig umsetzen noch später objektiv nachweisen lässt. Requirements Verification und Requirements Validation adressieren deshalb unterschiedliche Qualitätsdimensionen desselben Informationsbestands.

Nach der Realisierung verschiebt sich die Perspektive auf das Produkt beziehungsweise System. Verification liefert dann den objektiven Nachweis, dass die spezifizierten Anforderungen erfüllt wurden. Validation betrachtet, ob das realisierte Ergebnis im vorgesehenen Einsatz tatsächlich seinen Zweck erfüllt und den Erwartungen der Nutzer und Stakeholder entspricht. NASA fasst diesen Unterschied mit den bekannten Fragen zusammen, ob das Produkt richtig gebaut wurde und ob das richtige Produkt gebaut wurde.

Diese beiden Ebenen sollten nicht miteinander vermischt werden. Eine Anforderung kann zunächst verifiziert und validiert werden, bevor später das auf ihrer Grundlage entwickelte System wiederum gegen seine Spezifikation verifiziert und gegen seinen vorgesehenen Zweck validiert wird. Gerade diese Trennung macht deutlich, warum Requirements Engineering weit über die Formulierung einzelner Sätze hinausgeht: Die Qualität der Anforderungen muss bereits vor der Umsetzung geprüft werden, während ihre technische Erfüllung und die Eignung des resultierenden Systems erst im weiteren Entwicklungsverlauf nachgewiesen werden können.

Die Qualität einzelner Anforderungen reicht nicht aus

Ein weiterer typischer Fehler besteht darin, Requirements-Qualität ausschließlich auf Ebene einzelner Aussagen zu bewerten. Jede Anforderung kann für sich klar, eindeutig und verifizierbar sein, während die Gesamtheit der Anforderungen trotzdem unvollständig oder widersprüchlich bleibt.

Ein System wird nicht durch eine einzelne Anforderung spezifiziert, sondern durch ein Netz von Anforderungen, Randbedingungen und Beziehungen.

Deshalb muss auch die Qualität des Requirement-Sets betrachtet werden. Sind alle relevanten Funktionen erfasst? Sind Performance-Eigenschaften vollständig beschrieben? Widersprechen sich Anforderungen auf unterschiedlichen Ebenen? Wurde ein übergeordneter Bedarf vollständig aufgeteilt oder ist ein Teil davon bei der Zerlegung verloren gegangen? Existieren Anforderungen ohne nachvollziehbaren Ursprung oder übergeordnete Ziele, die auf keiner unteren Ebene umgesetzt werden?

NASA beschreibt beispielsweise, dass bei der Traceability geprüft werden sollte, ob übergeordnete Anforderungen vollständig auf niedrigere Ebenen verteilt wurden. Anforderungen ohne nachvollziehbaren Parent sollten entweder bewusst als selbst abgeleitete technische Anforderungen begründet sein oder kritisch darauf geprüft werden, ob sie überhaupt notwendig sind.

Damit bekommt der Begriff Vollständigkeit eine systemische Bedeutung. Es genügt nicht, dass jede einzelne Zeile einer Spezifikation formal gut aussieht. Entscheidend ist, ob die Menge der Anforderungen gemeinsam eine konsistente Beschreibung des zu lösenden Problems ergibt.

Ein gutes Review sollte deshalb sowohl horizontal als auch vertikal denken: horizontal über Anforderungen derselben Ebene hinweg und vertikal entlang ihrer Ableitung durch die Systemhierarchie.

Änderungen machen die Qualität der Struktur sichtbar

Solange ein Projekt stabil ist, kann selbst eine schwach strukturierte Requirement-Landschaft funktionieren. Die Beteiligten kennen den Kontext, viele Zusammenhänge befinden sich im impliziten Wissen des Teams und Entscheidungen werden informell weitergegeben.

Erst bei Änderungen zeigt sich, wie belastbar diese Struktur wirklich ist.

Wenn eine Stakeholder-Erwartung geändert wird, sollte nachvollziehbar sein, welche Systemanforderungen davon betroffen sind. Werden Systemanforderungen angepasst, muss erkennbar sein, welche Komponenten, Schnittstellen und Verifikationsaktivitäten überprüft werden müssen. Ändert sich eine Architekturentscheidung, können daraus wiederum neue oder veränderte Anforderungen entstehen.

Damit ist Requirements Engineering kein linearer Prozess, der mit einer fertigen Spezifikation endet. Die Beziehung zwischen Bedarf, Requirement, Architektur und Nachweis entwickelt sich während des gesamten Lebenszyklus weiter.

ISO/IEC/IEEE 29148 legt Requirements Engineering deshalb ausdrücklich als Lifecycle-Prozess aus und verbindet Requirements-Definition mit deren Management und den zugehörigen Informationsobjekten über den gesamten Lebenszyklus.

Eine gute Requirement-Struktur muss deshalb nicht nur den heutigen Stand dokumentieren. Sie muss zukünftige Veränderungen überleben.

Der eigentliche Test ihrer Qualität ist häufig nicht, wie übersichtlich sie unmittelbar nach ihrer Erstellung aussieht, sondern wie zuverlässig sich sechs Monate später erklären lässt, welche Auswirkungen eine konkrete Änderung hat und weshalb die betroffenen Anforderungen ursprünglich so definiert wurden.

Requirements verbinden Disziplinen

Requirements werden häufig einem Requirements Engineer oder einer bestimmten Prozessphase zugeordnet. In komplexen technischen Systemen sind sie jedoch vielmehr ein gemeinsames Arbeitsobjekt unterschiedlicher Disziplinen.

Stakeholder bringen Erwartungen und Randbedingungen ein. Systems Engineering strukturiert sie und entwickelt daraus technische Requirements. Architektur und Fachdisziplinen konkretisieren und allokieren diese Anforderungen weiter. Software, Elektrik, Mechanik oder andere Engineering-Disziplinen setzen sie um. Test und Verification benötigen dieselben Anforderungen wiederum als Referenz für den Nachweis.

Damit liegen Requirements genau an den Übergängen zwischen verschiedenen Perspektiven.

Das erklärt, warum reine Dokumentqualität nicht ausreicht. Eine Anforderung muss gleichzeitig für mehrere Zwecke funktionieren: Sie muss technisch präzise genug für die Umsetzung sein, genügend Kontext für Reviews und Änderungen enthalten, in der Systemstruktur verortet werden können und einen belastbaren Bezug zur späteren Verifikation besitzen.

Die INCOSE Requirements Working Group beschreibt Needs and Requirements deshalb ausdrücklich in Verbindung mit Definition, Management, Verification und Validation über den gesamten Lifecycle und verfolgt gleichzeitig das Ziel, Systems Engineering stärker von dokumentzentrierten zu datenzentrierten Arbeitsweisen weiterzuentwickeln.

Genau darin liegt ein entscheidender Unterschied zwischen einem Requirement als Satz und einem Requirement als Engineering-Objekt. Der Satz kommuniziert eine Forderung. Das Engineering-Objekt verbindet verschiedene Disziplinen und Phasen miteinander.

Je besser diese Verbindung funktioniert, desto weniger gehen Informationen an den Übergängen zwischen Definition, Architektur, Umsetzung und Verifikation verloren.

Werkzeuge ersetzen keine Entscheidungslogik

Moderne Requirements-Management-Werkzeuge können große Mengen strukturierter Informationen verwalten. Sie ermöglichen Attribute, Baselines, Versionen, Traceability, Reviews, Statusmodelle und Verknüpfungen zu anderen Entwicklungsartefakten.

Dadurch können sie einen erheblichen Beitrag zur Beherrschung komplexer Systeme leisten.

Sie lösen jedoch nicht automatisch das eigentliche Requirements-Problem.

Ein Tool kann einen Link zwischen zwei Anforderungen speichern, aber nicht entscheiden, ob die Beziehung fachlich sinnvoll ist. Es kann ein Rationale-Feld bereitstellen, aber nicht sicherstellen, dass dort eine hilfreiche Begründung steht. Es kann den Status „verified“ verwalten, ohne beurteilen zu können, ob der zugrunde liegende Nachweis tatsächlich geeignet ist.

Schlechte Requirements werden durch ein besseres Werkzeug deshalb zunächst nur strukturierter gespeichert.

Das gilt auch für die häufige Diskussion zwischen dokumentzentrierten und daten- beziehungsweise modellzentrierten Ansätzen. Strukturierte Daten eröffnen neue Möglichkeiten für Analysen, Konsistenzprüfungen, automatisierte Reports und Impact Analysis. Ihr Nutzen hängt jedoch davon ab, ob die zugrunde liegenden Beziehungen und Attribute fachlich sinnvoll definiert wurden.

Die zentrale Frage sollte deshalb nicht lauten, welches Tool möglichst viele Funktionen besitzt. Entscheidend ist, welche Informationen im eigenen Entwicklungsprozess benötigt werden, welche Beziehungen zwischen ihnen relevant sind und welche Entscheidungen damit unterstützt werden sollen.

Erst wenn diese Logik klar ist, kann ein Werkzeug sie wirksam abbilden.

Ein pragmatisches Qualitätsmodell

Requirements Engineering kann schnell komplex wirken, insbesondere wenn Standards, Tools, Traceability-Modelle und unterschiedliche Systemebenen gleichzeitig betrachtet werden. In der Praxis lässt sich die Qualität einer Anforderung jedoch auf einige miteinander verbundene Fragen zurückführen.

Zunächst muss die Forderung selbst verständlich sein. Es muss klar sein, welches Verhalten, welche Eigenschaft oder welche Einschränkung erwartet wird und unter welchen Bedingungen sie gilt. Gleichzeitig sollte nachvollziehbar sein, woher diese Forderung stammt und warum sie benötigt wird. Dadurch lässt sich beurteilen, ob sie tatsächlich notwendig ist und welche übergeordnete Erwartung sie unterstützt.

Danach muss ihre Position im System verständlich sein. Welche anderen Requirements leitet sie ab, welche Systemelemente sind betroffen und welche nachgelagerten Anforderungen entstehen daraus? Diese Beziehungen bilden die Grundlage für Traceability und spätere Impact Analysis.

Ebenso früh sollte geklärt werden, wie die Erfüllung der Anforderung nachgewiesen werden kann. Dabei geht es zunächst weniger um einen vollständig ausgearbeiteten Testfall als um die grundsätzliche Frage, ob objektive Akzeptanzkriterien und ein geeigneter Verifikationsansatz existieren.

Schließlich muss die Anforderung veränderbar bleiben. Änderungen brauchen eine nachvollziehbare Bewertung, bei der sowohl die ursprüngliche Rationale als auch die Auswirkungen auf verbundene Anforderungen, Architektur und Verifikation berücksichtigt werden können.

Aus diesen Fragen entsteht ein vergleichsweise einfaches Modell:

Was wird gefordert? Warum wird es gefordert? Woher kommt es? Womit hängt es zusammen? Wie wird es nachgewiesen? Was passiert, wenn es sich ändert?

Wenn diese Fragen beantwortet werden können, besitzt eine Anforderung wesentlich mehr Wert als ein isolierter, gut formulierter Satz.

Gute Anforderungen schaffen Entscheidungsfähigkeit

Requirements Engineering wird häufig als Mittel verstanden, um Missverständnisse zwischen Auftraggeber und Entwicklung zu vermeiden. Das ist ein wichtiger Zweck, greift aber zu kurz.

Eine gute Requirement-Struktur schafft vor allem Entscheidungsfähigkeit.

Sie ermöglicht einem Team zu verstehen, warum eine technische Forderung existiert, welche Konsequenzen eine Änderung haben könnte und welche Nachweise erforderlich sind, bevor eine Entscheidung getroffen wird. Sie macht sichtbar, wo Erwartungen noch nicht ausreichend konkretisiert wurden, welche Annahmen einer Architektur zugrunde liegen und an welchen Stellen Änderungen Auswirkungen auf andere Systemelemente haben.

Damit werden Requirements zu einem Teil des technischen Gedächtnisses eines Projekts.

Sie konservieren nicht jede Diskussion und ersetzen weder Fachwissen noch direkte Kommunikation. Sie erhalten jedoch genau jene Informationen, die notwendig sind, damit technische Entscheidungen auch dann nachvollziehbar bleiben, wenn sich Systeme, Teams und Randbedingungen verändern.

Gute Requirements sind deshalb mehr als sprachlich saubere Aussagen darüber, was ein System leisten soll. Sie verbinden Bedarf mit technischer Konkretisierung, technische Entscheidungen mit ihrer Begründung, Architektur mit Umsetzung und Anforderungen mit ihrer Verifikation.

Ein guter Satz bleibt wichtig. Aber erst durch seine Beziehungen erhält er seinen vollständigen Wert für das Engineering.

Die Qualität einer Anforderung zeigt sich nicht nur daran, wie eindeutig sie formuliert ist, sondern daran, wie zuverlässig sie Entscheidungen über den gesamten Entwicklungsprozess hinweg unterstützt.