Die neue SOPHIST-Satzschablone für Bedingungen in funktionalen und nicht-funktionalen Anforderungen

Im Rahmen unseres Innovationsprojekts MASTeR (Mustergültige Anforderungen – die SOPHIST Templates für Requirements) konnten wir uns der Herausforderung stellen, eine bzw. wie Sie gleich sehen werden drei Satzschablonen für Bedingungen zu entwickeln.

Nötig war dies, da frei formulierte Bedingungen als Teil einer funktionalen oder nicht-funktionalen Anforderung oft mehrdeutig waren. Dieses Problem verdeutlicht beispielhaft folgende nicht-funktionale Anforderung:

Wenn das Smartphone inaktiv ist, muss der Stromverbrauch des Smartphone kleiner als 50% sein.

Aufgrund der kleinen, aber mehrdeutigen Konjunktion wenn macht sich Mehrdeutigkeit breit! Folgende Interpretationen der obigen Anforderung durch drei Tester unterstreichen die Notwendigkeit für den BedingungsMASTeR:

Tester 1: „Ok cool, falls das Smartphone inaktiv ist, muss der Stromverbrauch auf Sparflamme laufen. Muss ich nichts weiter beachten, lass das Smartphone erst mal eine Weile liegen, hole mir einen Kaffee und teste das dann irgendwann mal.“

Tester 2: „Ach alles klar, sobald das Smartphone inaktiv ist, läuft sein Stromverbrauch auf Sparflamme. Ich teste das gleich nach der Zustandsänderung. Muss ich auch nicht ewig hier warten und das Smartphone erst noch acht Stunden inaktiv sein lassen. Da schaff ichs noch zum Fußball!“

Tester 3: „Ganz klarer Fall! Solange das Smartphone inaktiv ist, läuft sein Stromverbrauch auf Sparflamme. Ich teste das einfach mal für 24 Sekunden, Minuten und Stunden Inaktivität. Finde ich realistisch und wenn der Test 24 Stunden läuft, mach heut einfach mal zeitiger Feierabend.“

Drei Tester, drei richtige Interpretationen und eine Frage: Was wollte ihnen der Stakeholder mit dieser Anforderung eigentlich sagen?

Um diese Mehrdeutigkeit bzw. Interpretationsvielfalt in Anforderungsformulierungen zu vermeiden, stellen wir Ihnen in diesem Blogeintrag die SOPHIST-Satzschablone BedingungsMASTeR für Anforderungen mit einer Bedingung vor. Wir haben eingangs ein nicht-funktionales Beispiel gewählt. Wie aber bereits erwähnt, ist die Schablone auch für funktionale Anforderungen geeignet.

Machen Sie sich zunächst die unterschiedliche Bedeutung der Konjunktionen in Abbildung 1 bewusst.

Abbildung 1: BedingungsMASTeR

Es gibt demnach also drei Möglichkeiten, eine Bedingung einzuleiten: „Falls“, „sobald“ und „solange“. Eine Konjunktion allein macht aber noch keine Bedingung! Daher stellen wir Ihnen im Folgenden die drei Satzschablonen mit denen Sie drei unterschiedliche Arten von Bedingungen formulieren können im Detail vor.

LogikMASTER Abbildung 2: LogikMASTeR

Mit der Schablone in Abbildung 2 können Sie logische Bedingungen formulieren (z. B. Falls das Smartphone inaktiv ist, […]). Wann oder für wie lange sich der Zustand des Smartphone zu inaktiv geändert hat, ist für den LogikMASTeR nicht wichtig. Darum hat der oben angeführte Tester 1 auch recht, wenn er das Smartphone irgendwann für irgendeinen Zeitraum in den Zustand inaktiv versetzt und dann seinen Test durchführt. Denn ob der Stromverbrauch kleiner als 50% ist, ist immer testbar. Ein weiteres Beispiel für eine logische Bedingung ist:

Falls die verbleibende Akkulaufzeit kleiner gleich 10 min ist, muss das Smartphone sich ausschalten.

EreignisMASTeR

Schauen wir uns nun die Interpretation des 2. Testers an. Er bezieht die Bedingung auf das Verhalten des Smartphone direkt nach dessen Zustandsänderung. Zur Formulierung von Bedingungen, die sich auf ein Ereignis beziehen, das zu einem bestimmten Zeitpunkt in einem System eingeht, steht Ihnen der EreignisMASTeR zur Verfügung (Abbildung 3). Abbildung 3: EreignisMASTeR

Tester 2 testet den Stromverbrauch des Smartphone also direkt nachdem sich dessen Zustand von aktiv zu inaktiv verändert hat. Allein dieses Ereignis ist der Ausgangspunkt für seinen Test (Sobald das Smartphone inaktiv ist, […]). Eine weitere Anforderung, die der Tester bekommen könnte, ist:

Sobald das Ereignis Ladekabel anstecken eintritt, muss das Smartphone dem Kunden die Meldung „Smartphone wird geladen“ auf dem Display anzeigen.

ZeitraumMASTeR

Wo setzt Tester 3 an? Der Tester weiß, dass das Smartphone inaktiv ist. Für wie lange weiß er jedoch nicht. Er bestimmt nach bestem Wissen und Gewissen Testzeiträume und waltet seines Amtes. Mit dem in Abbildung 4 dargestellten ZeitraumMASTeR können Sie Anforderungen formulieren, die einen unbestimmten Zeitraum, in dem ein System in einem bestimmten Umstand ist, beschreiben.

Abbildung 4: ZeitraumMASTeR

Eine mit dem ZeitraumMASTeR formulierte Anforderung lautet:

Solange sich das Smartphone im Zustand Aktiv befindet, muss die Bildschirmhelligkeit gleich 100% sein.

Mit diesen drei Schablonen wirken Sie der Mehrdeutigkeit einer frei formulierten Bedingung in funktionalen und nicht-funktionalen Anforderungen entgegen. Doch vergessen Sie nicht, Ihre MASTeRhaft formulierte Bedingung mit einem ebenso MASTERhaften Hauptsatz zu beenden. Zum Glück waren wir im Innovationsprojekt MASTeR (fast) nicht mehr zu stoppen und überarbeiteten auch die bereits auf dem Markt verbreitete SOPHIST-Satzschablone für funktionale Anforderungen und erarbeiteten drei neue Satzschablonen für nicht-funktionale Anforderungen: den EigenschaftsMASTeR sowie den Umgebungs- und ProzessMASTeR.

Sie möchten mehr über MASTeR erfahren? Kommen Sie doch zu den SOPHIST Days am 5. und 6. November 2013 und sprechen Sie mit den Menschen hinter den Satzschablonen.
Natürlich sind wir aber auch außerhalb der SOPHIST Days offen für frei formuliertes Feedback und erste Erfahrungsberichte mit dem BedingungsMASTeR . Sie erreichen uns telefonisch unter 0911 – 40 900-0 und per Email unter heureka@sophist.de. Oder aber Sie testen die Kommentarfunktion unseres Blogs!