EARS-Syntax im Anforderungsmanagement

EARS-Syntax im Anforderungsmanagement: Präzision statt schwammiger Vorgaben

In der Entwicklung folgen Quellcode, Platine und Logikbausteine strengen Regeln. Das vorausgehende Anforderungsmanagement wird dagegen erstaunlich oft in freier Prosa verfasst. Natürliche Sprache ist jedoch von Natur aus mehrdeutig. Wenn Spezifikationen voller vager Begriffe stecken, müssen Ingenieure Vermutungen anstellen. Die EARS-Syntax schafft hier Abhilfe, indem sie unstrukturierte Wünsche in standardisierte Satzmuster übersetzt. Das setzt von Beginn an klare Leitplanken für das gesamte Projekt.

Missverständnisse am Prüfstand

Später Nachmittag im Testlabor. Das Team steht um den Prüfstand eines Steuergeräts und analysiert die Messdaten am Oszilloskop. Ein Sensorsignal war ausgefallen, doch die Reaktion erfolgte eine halbe Sekunde zu spät. Im Lastenheft stand lediglich ein Satz: „Das System muss bei einem Sensorausfall schnell reagieren.“

Der Softwareentwickler hielt eine halbe Sekunde für völlig ausreichend. Für reine Desktop-Software mag das stimmen, für ein physisches Fahrzeug im Fahrbetrieb ist es unbrauchbar. Johannes Meyer kennt solche Fälle aus seiner Zeit als Head of Technical Project Management bei Fernride und Program Manager bei ZF Mobility Solutions. Heute löst er diese Themen gemeinsam mit Florian Obermeier bei der Honest Guys Consulting GmbH. Es lag kein Programmierfehler vor, sondern eine Spezifikation, die nicht sauber durchdacht war. Man kann das abstellen, wenn Anforderungen vor dem ersten Entwicklungs-Sprint nach festen Regeln formuliert werden.

Wie die EARS-Syntax unstrukturierte Sätze zerlegt

Die EARS-Syntax (Easy Approach to Requirements Syntax) stammt ursprünglich aus der Luftfahrt, wo sprachliche Unklarheiten direkte Ausfälle nach sich ziehen können. Das System basiert auf fünf klaren Satzmustern, die Auslöser, Systemzustände und die geforderte Systemreaktion eindeutig miteinander verknüpfen.

Der wichtigste Grundsatz lautet: Das System ist immer das aktive Subjekt im Satz. Passivkonstruktionen wie „Die Daten müssen gespeichert werden“ sind unzulässig, weil sie offenlassen, welche Komponente die Aktion ausführt.

Ein Beispiel aus der Praxis bei Smart Meter Gateways veranschaulicht den Unterschied:

• Vorher (Unstrukturiert): „Die Datenübertragung zwischen Gateway und Server muss jederzeit sicher sein.“
• Nach EARS-Syntax: „Solange die Datenübertragung aktiv ist, muss das Gateway die Nutzdaten nach AES-256 verschlüsseln.“

Die Entwickler wissen sofort, welches Modul gefordert ist, welcher Algorithmus greift und in welchem Zustand die Vorgabe gilt.

Jedes Satzmuster deckt ein bestimmtes Systemverhalten ab:

1. Universell (Ubiquitous): Beschreibt Eigenschaften, die das System immer und ohne Bedingung aufweisen muss.
   • Formel: Das [System] muss [Systemantwort].
   • Beispiel: „Das Sensorgehäuse muss gemäß Schutzklasse IP67 gegen Staub und Wasser geschützt sein.“
2. Ereignisgesteuert (Event-Driven): Tritt ein bestimmter Auslöser ein, reagiert das System.
   • Formel: Wenn [Trigger], muss das [System] [Systemantwort].
   • Beispiel: „Wenn der Bediener die Not-Aus-Taste drückt, muss das Steuerungsmodul die Stromzufuhr innerhalb von 10 Millisekunden unterbrechen.“
3. Zustandsbasiert (State-Driven): Verhalten während eines bestimmten Operationszustands.
   • Formel: Solange [Zustand], muss das [System] [Systemantwort].
   • Beispiel: „Solange sich das Fahrzeug im autonomen Fahrbetrieb befindet, muss die Warnleuchte durchgehend gelb blinken.“
4. Fehlerfall (Unwanted Behavior): Bestimmt das Verhalten bei einer Störung oder Abweichung.
   • Formel: Falls [Fehler], dann muss das [System] [Systemantwort].
   • Beispiel: „Falls die Verbindung zum Backend für mehr als 5 Sekunden unterbricht, dann muss das Gateway die Messdaten im lokalen Speicher puffern.“
5. Optionale Funktion (Optional Feature): Für Varianten oder spezifische Zusatzausstattungen.
   • Formel: Sofern [Bedingung], muss das [System] [Systemantwort].
   • Beispiel: „Sofern das Modul mit der Kamera-Option ausgestattet ist, muss das System den Videostream vor der Übertragung komprimieren.“

Die Adjektiv-Falle konsequent umgehen

Begriffe wie „benutzerfreundlich“, „performant“, „nahtlos“ oder „skalierbar“ erzeugen in Meetings eine trügerische Einigkeit. Jeder nickt, aber jeder stellt sich etwas anderes darunter vor. Im Anforderungsmanagement sind solche Wörter keine Parameter, sondern versteckte Missverständnisse.

Die Lösung besteht darin, jedes Adjektiv in prüfbare Metriken zu übersetzen:

• Aus „performante Datenbank“ wird: „Das Datenbanksystem muss 10.000 Schreibzugriffe pro Sekunde mit einer Latenz von unter 50 Millisekunden verarbeiten.“
• Aus „intuitives Bedienkonzept“ wird: „Ein geschulter Operator muss die Systemkalibrierung ohne externe Dokumentation in unter drei Minuten fehlerfrei durchführen können.“

Eine Anforderung ist erst dann bereit für das Engineering-Backlog, wenn der zugehörige Testfall binär mit Pass oder Fail bewertet werden kann.

Die Auswirkungen von Scope Creep transparent machen

Unklare Anforderungen führen im Projektverlauf fast immer zu nachträglichen Sonderwünschen. Wenn Zwischenergebnisse nicht den vagen Erwartungen entsprechen, wird nachgebessert. Wer dann planlos auf jeden Zuruf anspringen will, bringt den Zeitplan der Entwickler ins Wanken.

Die Aufgabe der Projektleitung besteht darin, die Auswirkungen transparent zu machen. Wenn mitten im Projekt eine neue Funktion gefordert wird, muss sofort feststehen, welcher andere Gehalt dafür entfällt oder wie sich der Fertigstellungstermin verschiebt. Ein gutes „Nein“ zum richtigen Zeitpunkt schützt das Projekt vor unkontrolliertem Scope Creep und hält den Fokus auf den wesentlichen Funktionen.

Klare Spielregeln für die Entwicklung

Präzision in der Spezifikation ist kein bürokratischer Selbstzweck, sondern der direkte Weg zu verlässlichen Projektergebnissen. Wer die EARS-Syntax nutzt und unstrukturierte Adjektive konsequent streicht, schafft eine verlässliche Brücke zwischen Business-Vision und technischer Umsetzung. Es braucht keine komplexen Software-Landschaften, sondern einfach nur klare Spielregeln für die Satzstruktur.