Seit vielen Jahren zählen unsere Schablonen für funktionale und nicht-funktionale Anforderungen, welche wir unter dem Begriff MASTeR zusammenfassen, zu häufig eingesetzten Methoden bei unseren Kunden. Deshalb sollte man meinen, dass alles dazu gesagt wurde und die Verwendung keine Probleme bereitet.
Doch leider kommt es an einer bestimmten Stelle öfter zu Irritationen: der Beschreibung von funktionalen Anforderungen an eine technische Schnittstelle – unser Typ 3.
Wo liegt denn das Problem?
Wirft man einen Blick auf unseren FunktionsMASTeR (siehe Abbildung 1), so erkennt man den folgenden – evtl. bekannten – Aufbau:
Abbildung 1: Der FunktionsMASTeR ohne Bedingung
Wir erkennen dort den Betrachtungsgegenstand (= System), die juristische Verbindlichkeit (= muss│sollte│wird), die Funktion selbst (= Prozesswort), Ergänzungen zur Funktion (= Objekt) und zum Schluss in der Schablonenmitte: die Art der Funktionalität.
Und genau mit diesem letzten Teil – der Art der Funktionalität – wollen wir uns in diesem Artikel genauer beschäftigen. Allerdings nicht komplett, sondern nur mit dem „fähig sein“-Teil.
Zur Wiederholung: der FunktionsMASTeR unterscheidet 3 unterschiedliche Funktionsarten:
- Typ 1: Selbsttätige Systemaktivität, d.h. das System startet den Prozess und führt ihn selbsttätig durch.
- Typ 2: Benutzungsinteraktion, d.h. das System stellt einem Benutzer eine Funktion zur Verfügung, die dieser über eine Benutzungsschnittstelle startet.
- Typ 3: Technische Schnittstellenanforderung, d.h. das System ist passiv, wartet auf eine externes Ereignis und führt nur in Abhängigkeit von einem Dritten (nicht der Benutzer) die Funktion aus.
Alles klar – oder nicht? Besonders der Typ 3 wirft manchmal Fragen auf: Was heißt mein System ist passiv und reagiert auf ein Ereignis? Über eine technische Schnittstelle kann mein System doch auch aktiv etwas übermitteln?
Um diesen Fragen auf den Grund zu gehen, werden wir Ihnen Szenarien beschreiben, die an einer technischen Schnittstelle passieren können und Ihnen dann zeigen, wie Sie diese mit dem FunktionsMASTeR beschreiben.
Szenario 1 – Das einfache Senden
Wenn an einer Schnittstelle das Senden von Informationen oder Signalen betrachtet wird, so könnte das in einem Aktivitätsdiagramm wie folgt aussehen (siehe Abbildung 2):
Abbildung 2: Einfaches Senden als Aktivitätsdiagramm
Doch was bedeutet das im Detail? Im konkreten Fall liegt die Tätigkeit „Tür verriegeln“ vor, die dazu führt, dass das System das Signal „Tür verriegelt“ über eine Schnittstelle sendet. Wie würde man dies also entsprechend der MASTeR-Schablonen für funktionale Anforderungen formulieren? Eine ausreichend detaillierte Beschreibung mit nur einer Anforderung wäre unter Umständen möglich, jedoch wohl recht kompliziert und schwer zu formulieren. Wir beschreiben also zunächst die Systemtätigkeit, die dazu führt, dass gesendet wird mit einer Anforderung vom Typ 1:
Das Smart-Home-System muss die Tür verriegeln.
Dies lässt sich natürlich nach Bedarf um Bedingungen erweitern. Aufbauend darauf wird nun keine Typ 3 Anforderung, sondern eine Typ 1 Anforderung benötigt:
Nachdem das Smart-Home-System die Tür verriegelt hat, muss das SHS das Signal „Tür verriegelt“ an das zentrale Steuersystem senden.
Doch warum eine Typ 1 Anforderung? Die Ursache liegt darin, wie Typ 3 definiert ist: das System ist passiv und reagiert auf ein Ereignis. In dem in Abbildung 2 beschriebenen Szenario ist unser System aber nicht passiv, sondern führt das „Senden“ aktiv und damit selbsttätig aus auch wenn das Signal an einer Schnittstelle übertragen wird.
Szenario 2 – Empfangenes Signal startet einen Ablauf
Falls nun jedoch an einer Schnittstelle ein Signal empfangen wird, welches dadurch im System einen Ablauf startet, so sieht das wie folgt aus (siehe Abbildung 3).
Abbildung 3.: Empfangenes Signal startet Ablauf
In unserem zweiten Beispiel ist der Empfang des Signals „Tür entriegeln“ der Auslöser für die Aktion „Tür entriegeln“. Es wird also durch unser System die rein passive Rolle des Signalempfangs eingenommen. Auch hier handelt es sich um eine Schnittstellenanforderung, die jedoch nach MASTeR-Schablone etwas anders aussehen würde. Die Passivität des Systems lässt sich in einem ersten Schritt problemlos durch eine Typ 3 Anforderung darstellen:
Das Smart-Home-System muss fähig sein, das Signal „Tür entriegeln“ vom zentralen Steuersystem zu empfangen.
Nachdem diese Typ 3 Anforderung die Funktion gestartet hat, beschreibt eine Typ 1 Anforderung mit Bedingung, welche Funktion das System nun ausführt:
Nachdem das Smart-Home-System das Signal „Tür entriegeln“ empfangen hat, muss das Smart-Home-System die Tür entriegeln.
Die Erklärung ergibt sich hier im Prinzip analog zum ersten Beispiel. Die Typ 3 Anforderung beschreibt ausschließlich die passive Fähigkeit des Systems. Zur Ergänzung der darauffolgenden Aktivität ist dann jedoch eine Typ 1 Anforderung notwendig.
Am kommenden Mittwoch werden wir Ihnen 3 weitere Szenarien vorstellen, in denen Sie sehen, wie man funktionale Anforderungen an technischen Schnittstellen nutzen kann.