Im letzten Beitrag haben wir Ihnen hier bereits zwei Szenarien vorgestellt, die funktionale Anforderungen an technischen Schnittstellen und die Probleme in solchen Situationen aufzeigen. Hier stellen wir Ihnen 3 weitere Szenarien vor, die Sie beachten müssen.
Szenario 3 – Empfangen eines Signals innerhalb eines Ablaufs
Etwas komplexer ist die Entscheidung für einen FunktionsMASTeR bei Einzelschritten eines Ablaufs (siehe Abbildung 4).
Abbildung 4: Empfangenes Signal innerhalb eines Ablaufs
Unser drittes Beispiel baut auf den vorherigen Beispielen auf: auf eine Signal-Sende-Aktion folgt das Empfangen eines Signals. Es findet also das Empfangen des Signals „Selbstdiagnose durchführen“ statt, dies aber ausschließlich nachdem die Anfrage zur Durchführung der Selbstdiagnose vorher gesendet wurde. Dies bedeutet, dass wir zunächst eine Typ 1 Anforderung brauchen:
Das Smart-Home-System muss die Anfrage „Selbstdiagnose durchführen“ an das zentrale Steuersystem senden.
Sobald dies geschehen ist, wartet unser Smart-Home-System auf die Antwort des zentralen Steuersystems. Dafür benötigen wir eine Typ 3 Anforderung mit Bedingung:
Sobald das Smart-Home-System die Anfrage „Selbstdiagnose durchführen“ gesendet hat, muss das Smart-Home-System fähig sein, das Signal „Selbstdiagnose durchführen“ vom zentralen Steuersystem zu empfangen.
Mit Hilfe dieser beiden Anforderungen können wir also die Abarbeitung einer synchronen Kommunikation beschreiben.
Szenario 4 – Lösungsneutrale Kommunikation
Manchmal ist es nötig, dass man die Kommunikation an einer technischen Schnittstelle lösungsneutral beschreiben muss. D.h. man möchte noch nicht im Detail festlegen, wie etwas „ausgetauscht“ wird (siehe Abbildung 5).
Abbildung 5: Lösungsneutrale Kommunikation
In diesen Fällen verwenden Sie einfach eine Typ 1 Anforderungen, da noch nicht klar ist, ob Ihr System aktiv oder passiv ist:
Das Smart-Home-System muss Selbstdiagnosedaten mit dem zentralen Steuersystem austauschen.
Wenn, wie im dargestellten Beispiel aus Abbildung 5, eine Anforderung mit „austauschen“ formuliert wird, können hier z.B. die Elemente aus den Szenarien 1 und 2 enthalten sein. Auf dem betrachteten Spezifikationslevel wird dies noch nicht festgelegt. Zu einem späteren Zeitpunkt und auf einem detaillierteren Spezifikationslevel kann dann der genaue Ablauf an der Schnittstelle mittels Typ1 und/oder Typ 3 beschrieben werden.
Szenario 5 – Unterbrechendes Empfangen
Stellen Sie sich vor, Sie wollen beschreiben, dass Ihr System eine Funktion ausführt und während dieser Ausführung können 3 Fälle eintreten:
- Mein System empfängt ein externes Signal über eine technische Schnittstelle und muss darauf reagieren.
- Ein Benutzer löst ein Signal in meinem System aus und mein System muss darauf reagieren.
- Innerhalb meines Systems wird ein anderer Ablauf parallel ausgeführt und dieser zweite, interne Ablauf generiert ein Signal, auf welches das System nun im beschriebenen Ablauf reagieren muss.
Alle drei Fälle sind in Abbildung 6 dargestellt.
Abbildung 6: Unterbrechendes Empfangen
Um die drei oben und in Abbildung 6 beschriebenen Fälle mittels FunktionsMASTeR auszudrücken, brauchen wir zunächst eine Typ 1 Anforderung:
Das Smart-Home-System muss die Umgebung beobachten.
Damit haben wir den Ausgangszustand unseres Systems beschrieben. Nun können unsere 3 Fälle auftreten:
Fall 1: Empfang eines externen Signals
Um diesen Fall abzudecken benötigen wir, wie bereits gelernt, eine Typ 3 und eine Typ 1 Anforderung:
Solange das Smart-Home-System die Umgebung beobachtet, muss das Smart-Home-System fähig sein, das Signal „Selbstdiagnose durchführen“ vom zentralen Steuersystem zu empfangen.
Sobald das Smart-Home-System das Signal „Selbstdiagnose durchführen“ empfangen hat, muss das Smart-Home-System das Selbstdiagnoseprogramm starten.
Fall 2: Reaktion auf Benutzer
Für den nächsten Fall brauchen wir eine Kombination aus Typ 2 und Typ 1 Anforderung.
Solange das Smart-Home-System die Umgebung beobachtet, muss das Smart-Home-System dem Hausbewohnenden die Möglichkeit bieten, die Funktion „Umgebung beobachten“ abzubrechen.
Sobald der Hausbewohnende die Funktion „Umgebung beobachten“ abgebrochen hat, muss das Smart-Home-System das Kamerasystem abschalten.
Fall 3: Eintreten einer systeminternen Bedingung innerhalb eines zweiten parallel ausgeführten Prozesses. Hier reicht uns EINE Anforderung vom Typ 1.
Solange das System die Umgebung überwacht UND
falls der Prozess „Feuer melden“ ein Feuer festgestellt hat,
muss das Smart-Home-System alle Raffstores entriegeln.
Sie sehen also, ganz so einfach ist dieses abschließende Szenario nicht. Je komplexer die Szenarien werden, desto vielfältiger sind die Kombinationsmöglichkeiten aus Anforderungen unterschiedlicher Typen.
Fazit
Aus den verschiedenen möglichen Konstellationen, die nun beschrieben wurden, wird deutlich ersichtlich, dass zur Beschreibung einer Funktionalität an einer Schnittstelle nicht immer nur eine Typ 3 Anforderung ausreicht, obgleich ihr Name „Schnittstellenanforderung“ es vermuten lässt. Jedoch hoffen wir, dass wir Ihnen eine Hilfestellung an die Hand gegeben haben, welche Kombinationen verschiedener funktionaler Anforderungstypen an einer Schnittstelle verschiedene Szenarien beschreiben können.