Bessere Anforderungen schreiben mit EARS

EARS steht für „Easy Approach to Requirements Syntax“ – Einfache Herangehensweise an die Formulierung von Anforderungen. Mit EARS sollen Mitarbeiter endlich ohne großen Lernaufwand gute Anforderungen schreiben. Also Anforderungen, die klar, präzise, testbar, nachvollziehbar und korrekt sind. Viele Ansätze vor EARS hatten dieses Versprechen und konnten es nicht halten.

Es gibt vergleichsweise wenig Informationen zu EARS auf Deutsch. Wie funktioniert EARS, und ist es wirklich besser als Textschablonen und Checklisten? Und vor allem: Wie können wir EARS für deutsche Anforderungen nutzen? Darum geht es heute.

In eigener Sache: Am 29./30.6. veranstalte ich ein Webinar zu Semiant, dem virtuellen Qualitätsassistenten für die Produktentwicklung. Gern teilnehmen und weitersagen. Danke!

Die Geschichte von EARS

EARS wurde 2009 von Alistair Maven und seinen Kollegen bei Rolls-Royce PLC entwickelt. Das Team benutzte EARS bei der Analyse der Vorschriften für das Steuerungssystem eines Strahltriebwerks. Die Vorschriften enthielten übergeordnete Ziele, eine Mischung aus impliziten und expliziten Anforderungen auf verschiedenen Ebenen, Listen, Richtlinien und unterstützende Informationen.

Bei der Extraktion und Vereinfachung der Anforderungen stellten sie fest, dass die Anforderungen alle eine ähnliche Struktur aufwiesen. Dieser Struktur zu folgen erhöhte auch die Lesbarkeit. EARS ist die Verfeinerung und Weiterentwicklung dieses Musters. EARS sind also Textschablonen.

Ich bin eigentlich kein großer Fan von Textschablonen. Doch EARS würde ich noch am ehesten empfehlen, da es sich um einen einfachen und gleichzeitig sehr wirkungsvollen Schablonensatz handelt, der Autoren wenig einengt.

EARS-Schablonen für Anforderungen auf Deutsch

Ich habe viele Quellen für die englischsprachigen Schablonen von EARS gefunden. Die ursprüngliche Quelle ist die Webseite von Alistair Maven, der übrigens auch EARS-Schulungen veranstaltet. Sehr hilfreich fand ich auch die Beschreibung von QRA, von denen die Idee des Spickzettels stammt (Titelbild, danke!). Das Folgende ist meine persönliche Übersetzung der EARS-Schablonen nach Deutsch.

EARS hat sich insbesondere für das Schreiben von englischen Anforderungen von Autoren bewährt, deren Muttersprache nicht Englisch ist.

Alistair Maven

Doch seien wir ehrlich, immer mehr Anforderungen werden auf Englisch geschrieben, immer weniger auf Deutsch. Englisch hat sich nun mal als die Lingua Franca unserer Welt etabliert. Doch das bedeutet, dass immer mehr Menschen Englisch nicht als Muttersprache gelernt haben. Gerade für diese Menschen ist EARS ein wertvolles Hilfsmittel, um Anforderungen auf Englisch zu formulieren.

Allgemeine EARS-Syntax

Die Klauseln einer in EARS geschriebenen Anforderung erscheinen immer in der gleichen Reihenfolge. Die Grundstruktur einer EARS-Anforderung ist:

Wenn <optionale Vorbedingung>, wenn <optionaler Auslöser>, dann muss <Systemname> <Systemantwort>

Der EARS-Regelsatz besagt, dass eine Anforderung Folgendes enthalten muss: Keine oder mehrere Vorbedingungen; Keine oder genau einen Auslöser; Genau einen Systemnamen; Eine oder mehrere Systemantwort.

Das ist eigentlich auch schon alles. Alles andere sind Variationen von dieser allgemeinen Struktur.

Variationen

Die Anwendung der EARS-Notation erzeugt eine kleine Anzahl von typischen Variationen, je nachdem, welche Klauseln wir verwenden. Dies sind die folgenden Muster:

Universelle Anforderungen

Universelle Anforderungen sind immer aktiv, daher gibt es kein EARS-Schlüsselwort:

Das <Systemname> muss <Systemantwort>

Beispiel: Das Mobiltelefon muss eine Masse von weniger als 120 Gramm haben.

Zustandsabhängige Anforderungen

Zustandsabhängige Anforderungen sind so lange aktiv, wie der angegebene Zustand wahr ist, und werden durch das Schlüsselwort „Solange“ gekennzeichnet.

Solange <Vorbedingung(en)> muss das <Systemname> <Systemantwort>

Beispiel: Solange sich keine Karte im Geldautomaten befindet, muss der Geldautomat die Meldung „Zum Starten Karte einlegen“ anzeigen.

Ereignisgesteuerte Anforderungen

Ereignisgesteuerte Anforderungen legen fest, wie ein System reagieren muss, wenn ein auslösendes Ereignis eintritt, und werden durch das Schlüsselwort „Sobald“ gekennzeichnet.

Sobald <Auslöser>, muss das <Systemname> <Systemantwort>

Beispiel: Sobald „Stummschaltung“ gewählt wird, muss der Laptop alle Audioausgaben unterdrücken.

Optionale Funktionsanforderungen

Die Anforderungen an optionale Merkmale gelten für Produkte oder Systeme, die das angegebene Merkmal enthalten, und werden durch das Schlüsselwort „Falls“ gekennzeichnet.

Falls <Merkmal ist enthalten>, muss <Systemname> <Systemantwort>

Beispiel: Wenn das Auto ein Schiebedach hat, muss das Auto ein Schiebedach-Bedienfeld an der Fahrertür haben.

Unerwünschte Verhaltensanforderungen

Unerwünschte Verhaltensanforderungen werden verwendet, um die erforderliche Systemreaktion auf unerwünschte Situationen zu spezifizieren, und werden durch die Schlüsselwörter „Wenn“ und „Dann“ gekennzeichnet.

Wenn <Auslöser>, dann muss das <Systemname> <Systemantwort>

Beispiel: Wenn eine ungültige Kreditkartennummer eingegeben wird, soll die Website die Meldung „Bitte geben Sie die Kreditkartendaten erneut ein“ anzeigen.

Komplexe Anforderungen

Die einfachen Bausteine der oben beschriebenen EARS-Muster können kombiniert werden, um Anforderungen für ein umfangreicheres Systemverhalten zu spezifizieren. Anforderungen, die mehr als ein EARS-Schlüsselwort enthalten, werden als Komplexe Anforderungen bezeichnet.

Solange <Vorbedingung(en)>, Sobald <Auslöser>, der <Systemname> muss <Systemantwort>

Beispiel: Solange das Flugzeug am Boden ist und sobald der Umkehrschub aktiviert wird, muss das Triebwerkssteuerungssystem den Umkehrschub aktivieren.

Komplexe Anforderungen für unerwünschtes Verhalten umfassen auch die Wenn-Dann-Schlüsselwörter.

Schlüsselwörter

Ich bin sicher, dass ich den einen oder anderen Kommentar bezüglich der vorgeschlagenen Schlüsselwörter bekommen werde. „Muss“ das System oder „Soll“ das System…? Was ist besser, „Solange“ oder „Während“? Haben wir eine „Systemantwort“ oder „Systemreaktion“?

Meine Persönliche Meinung: Es ist egal, solange ein Team konsistent die selben Konventionen anwendet.

Fazit

Am Ende handelt es sich bei EARS auch nur um Textschablonen für Anforderungen. Daher sind die Schablonen aus ISO/IEC/IEEE 29148:2018, IREB oder Master-Schablonen die offensichtlichen Alternativen. Interessanterweise erwähnen diese Quellen alle auch EARS, ohne jedoch tiefer darauf einzugehen.

Doch EARS hat meiner Meinung nach einen wichtigen Vorteil: EARS ist so einfach wie möglich, aber nicht einfacher. EARS kann auf einer Seite zusammengefasst werden. Das Masterschablonen-Buch ist 50 Seiten lang.

Titelbild inspiriert von QRA