Im letzten Teil dieser Blogserie haben wir Ihnen die SOPHIST-Schablone und ein Template von Esser und Struss als erste Möglichkeiten vorgestellt, die Ihnen bei der Formulierung von Anforderungen helfen sollen. Als durchgängiges Beispiel hatten wir Ihnen den Satz: „Wenn sich der Inhalt einer Datei ändert, geht der Zustand der Datei nach „geändert“ über.“ vorgegeben. Heute präsentieren wir Ihnen weitere Vorlagen zum Schreiben von Anforderungen.

Von Alistair Mavin stammt EARS+, die nächste Schablone, die wir Ihnen hier darstellen. Er entwickelte sie bei Rolls Royce plc., um Anforderungen an Flugzeugturbinen korrekt zu spezifizieren. Daneben hat aber auch bspw. Intel EARS+ im Einsatz. Ausgesprochen bedeutet die Abkürzung „Easy Approach to Requirements Syntax Plus“.

Im Folgenden sehen Sie die Schablone. Obligatorische Bestandteile sind fett dargestellt, optionale Bestandteile nicht fett. Die Zahlen dienen der Zuordnung der einzelnen Elemente im Beispiel zu den Bestandteilen der Schablone.

Diese Schablone ist schon viel detaillierter und damit leider auch etwas unübersichtlicher, als die beiden das letzte Mal vorgestellten. Doch keine Angst, A. Mavin liefert auch gleich ein Beispiel mit:

While <a transaction is in progress>², when <Customer>³ <selects>⁴ <option>⁵ <equals>⁶ <cancel>⁷, the <ATM>⁸ shall <return>⁹ <card>¹⁰ <to>¹³ <Customer>¹⁴ and <display>⁹ <message>¹⁰ <equals>¹¹ <“please take your card”>¹² <to>¹³ Customer>¹⁴.

Unser Beispiel, geschrieben nach EARS+ würde wie folgt lauten:

While <a file>¹ <is in state “backed up“>², when <the content of the file>⁵ <is changed>⁷, the <file system>⁸ shall <set>⁹ <the state of the file>¹⁰ <to “changed”>¹² <automatically>¹⁵.

Da viele Dinge nur optional sind, lässt sich das Detaillierungsniveau der Anforderungen sehr variabel gestalten. Sie können selbst entscheiden, auf welchem Spezifikationslevel Sie Ihre Anforderungen schreiben – eher abstrakt oder eher detailliert. EARS+ bietet beides und hilft Ihnen extra noch, keine Informationen im Anforderungssatz zu vergessen.

Wir SOPHISTen sehen neben der Komplexität der Schablone vor allem einen Nachteil darin, dass durch den <QoS>-Anteil nichtfunktionale Aspekte mit der funktionalen Anforderung vermischt werden. Nach Regel 9 unseres REgelwerks sollten Sie eigene Anforderungen für nichtfunktionale Aspekte formulieren, wenn:

• der nichtfunktionale Anteil eigenständig testbar ist, oder

• der nichtfunktionale Aspekt übergreifend als ein nichtfunktionales Constraint für mehrere Funktionalitäten gefordert wird.

Die nächste vorzustellende Schablone wurde von der Information Architecture Group (IAG) für Anforderungen entwickelt, die bei der Automatisierung von Geschäftsabläufen erhoben werden. Damit sollen Business Use Cases in eine einheitliche Form gebracht werden¹. Die Schablone lautet:

Auch zu dieser Schablone liefern die Entwickler ein Beispiel, in welchem aber leider die Geschäftsregeln außen vor gelassen werden:

„The system must
allow the Reservation Clerk
to select one instance from a list of potential Guests
when the Reservation Clerk has determined the appropriate occurance.”

Unser Beispiel, formuliert nach dieser Schablone, wäre wie folgt:
“The file system must
set
the state of a file to “changed”
when the content of the file is changed
if the file was in state “backed up”.”

Eine Besonderheit dieser Schablone ist, dass sie mehr den allgemeinen Inhalt vorgibt. Damit ist sie mehr eine Semantik- und weniger eine Syntax-Schablone als die anderen hier vorgestellten.
Ansonsten würden wir die Schablone als nicht zu ungenau, nicht zu detailliert, nicht zu komplex, nicht allzu formal einordnen.

Das letzte in diesem Teil vorgestellte Template wurde von Jörg Holtmann im Rahmen des Projekts „Software Platform Embedded System 2020 (SPES 2020)“ zur modellbasierten Entwicklung von eingebetteten Systemen im Automotive-Bereich, entwickelt. Er erarbeitete mehrere Templates, um automatisiert Modelle aus textuellen Anforderungen abzuleiten. Dazu implementierte er auch einen auf Eclipse basierenden Editor, der beim Dokumentieren von Anforderungen und Umwandeln in Diagramme hilft. Seine Schablone lautet:

Sein Beispiel dazu lautet: „Sobald im Zustand Startup des Systems „Innenlichtsteuerung“ die Zeit abgelaufen ist, geht es in den Zustand „Ready“ über.“

Daneben auch unser Beispiel: Sobald im „backed up“ des Systems „Datei“ das Ereignis „Inhalt der Datei geändert“ eintritt, geht es in den Zustand „geändert“ über.

Diese Schablone gibt einen sehr formalen Rahmen vor. Sie eignet sich damit perfekt, falls neben der natürlich-sprachlichen Anforderungsermittlung auch gleichzeitig ein Zustandsautomat modelliert wird. Dieser hohe Grad an Formalität wirkt sich positiv auf die Vollständigkeit der Anforderungen aus, so wird beispielsweise beachtet, ob alle Zustände und deren Übergänge spezifiziert sind. Weiterhin verhindert dies einige Ungenauigkeiten, so sind z.B. die nach Holtmann formulierten Anforderungen testbar, eine wichtige Eigenschaft von Anforderungen.

Jörg Holtmann geht davon aus, dass neben der natürlich-sprachlichen Dokumentation auch eine modellbasierte verwendet wird. Ist das bei Ihnen nicht der Fall, ist fraglich, ob dieser hohe Grad an Formalität unbedingt notwendig ist. So lassen sich mit der SOPHIST-Schablone Anforderungen viel freier und einfacher dokumentieren, die aber deswegen nicht zwangsweise von minderer Qualität sind.

Nachdem die Schablonen für funktionale Anforderungen abgeschlossen sind, kommen wir nun zu den Schablonen für nichtfunktionale Anforderungen – aber leider erst im dritten Teil unserer Blogserie. Da stellen wir Ihnen NoFun vor. Seien Sie gespannt – der Name ist Programm! :-)

________________________________________________________________________
¹IAG Consulting – 7 Secrets to Defining Requirements for Package Software Selection