Durchblick im Schablonendschungel – Teil 1

Ging es Ihnen auch schon einmal so, dass Sie eine Anforderung aufschreiben wollten, und einfach nicht wussten, wie Sie sie am besten formulieren? Damit Ihnen das in Zukunft nicht noch einmal passiert, möchten wir Ihnen hier verschiedene Werkzeuge vorstellen, die Sie beim Schreiben von Anforderungen verwenden können.

Es existieren verschiedene Ansätze, das Schreiben von Anforderungen durch Schablonen zu vereinheitlichen und zu vereinfachen. Wir haben den Markt durchsucht und dabei über 30 Vorlagen gefunden. Das Spektrum reichte von Modellen über das Vorgehen, bspw. der NFR-Methode (Non Functional Requirements) von Jörg Dörr (1) bis hin zu simplen Sammlungen von Anforderungen wie der Referenz-Beispiel-Datenbank aus IVENA, die einen Katalog von Anforderungen enthalten, aus denen Sie sich Ihre zusammensuchen können. Aus diesen 30 Templates haben wir die 5 ausgewählt, die als echte Satzschablonen die Struktur eines Anforderungssatzes vorgeben, und diese miteinander verglichen.

Nachfolgend stellen wir Ihnen diese 5 Schablonen vor: EARS+, NoFun, eine von M. W. Esser und P. Struss, eine der IAG Consulting sowie eine von Jörg Holtmann. Wir erläutern, in welchem Kontext sie am besten geeignet sind, und zeigen Vorteile und Nachteile der einzelnen Schablonen auf. Ausgangspunkt dieses Vergleichs war die Satzschablone der SOPHISTen, die wir als 6. Schablone hier präsentieren.

Zum Schreiben von funktionalen Anforderungen entwickelten auch die SOPHISTen vor über einem Jahrzehnt eine Satzschablone. Funktionale Anforderungen sind nach der Definition des IREB (International Requirements Engineering Board) Anforderungen bezüglich eines Ergebnisses oder eines Verhaltens, das von einer Funktion eines Systems bereitgestellt werden soll.

Mit der SOPHIST-Schablone lassen sich die meisten funktionalen Anforderungen formulieren. Gleichzeitig werden sprachliche Mängel wie Tilgung oder Generalisierung vermieden. So wird zum Beispiel durch die Vorgabe des Aktivs der Anwender gezwungen, denjenigen zu beschreiben, der die Funktion ausführen soll.

Um Ihnen die Anwendung der Schablonen nahe zu bringen, gießen wir bei jeder Schablone den frei formulierten Satz „Wenn sich der Inhalt einer Datei ändert, geht der Zustand der Datei nach „geändert“ über.“ in die durch die Schablone vorgegebene Form.

Nach SOPHIST-Schablone geschrieben lautet diese Anforderung: „Falls sich eine Datei im Zustand „gesichert“ befindet und sobald sich der Inhalt der Datei ändert, muss das Dateisystem den Zustand der Datei in den Zustand „geändert“ ändern.“

Die erste Schablone, die wir Ihnen vorstellen möchten, wurde von M. W. Esser und P. Struss entworfen, um automatisch Testfälle aus natürlich-sprachlichen Dokumentationen der Steuerungssoftware von Fahrzeugen abzuleiten.

In ihrem Essay präsentieren sie die Schablone mit dem Beispiel: “If button B4 has not been down during the last 5 seconds, then lamp L3 must be lit immediately.”

Für unsere Beispielanforderung geschrieben nach dieser Schablone ergibt sich: “If the content of a file has been changed, then the state of the file must be set to „changed“.

Eine ganz große Stärke dieser Schablone ist ihre Simplizität. Sie lässt sich ganz einfach auswendig lernen und anwenden. Wir wetten, Sie schaffen es, diese Schablone anzusagen, ohne nach oben zu schauen.

Eine weitere Stärke ist, dass sich aus den Anforderungen ziemlich leicht Testfälle ableiten lassen, was ja das Ziel der Entwicklung dieser Schablone war. So müsste in unserem Beispiel der Tester den Inhalt der Datei ändern und anschließend den Zustand der Datei überprüfen. Ist der Zustand gleich „geändert“, ist der Test bestanden, ist der Zustand nicht „geändert“, ist der Test nicht bestanden.

Ein Nachteil dieser Schablone ist ihre Ungenauigkeit. So bleibt bspw. ungeklärt, wer die Aktion, die Änderung des Zustands, ausführt. Gerade bei der Formulierung von Anforderungen ist die Angabe des Akteurs aber entscheidend, da für den Entwickler wichtig ist, ob die Aktivität vom System, vom Nachbarsystem oder vom Benutzer durchgeführt wird. Für den Test auf Funktionalität ist diese Information insofern nebensächlich, dass der Tester überprüft, ob die Funktion korrekt ausgeführt wird. Die Implementierung interessiert ihn nur sekundär.

Das soll es fürs Erste gewesen sein. In den nächsten Teilen der Blogserie werden wir weitere Templates für funktionale Anforderungen vorstellen, bspw. EARS+ oder ein Ansatz von Jörg Holtmann, sowie ein Template für nichtfunktionale Anforderungen mit dem Namen NoFun. Seien Sie gespannt, der Name ist Programm.

Bis bald.

Ihre SOPHISTen

Hier finden Sie den 2. Teil der Blogserie.
———————————————————————
(1) Jörg Dörr. Elicitation of a Complete Set of Non-Functional Requirements. PhD Thesis, Technische Universität Kaiserslautern, Kaiserslautern, 2010.
(2) mqm.in.tum.de/publications/2007/Esser%20Struss%20Models%20for%20TG%20from%20Natural-language-like%20Specifications%20DX07.pdf

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert