Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

Letztendlich lässt sich keine eindeutig kausale Begründung für die Bevorzugung einer der beiden
Möglichkeiten anführen. Zudem erlaubt der iterativ-inkrementelle Ansatz bei der Wahl kleiner
Iterationen und einer kurzen ersten Phase eine quasi-parallele Abarbeitung beider Aufgaben. Für
den hier vorgestellten Prozess wurde entschieden, mit der Spezifikation des Systemkontextes zu
beginnen.
Die folgende grafische Darstellung (Bild 6.6 auf der nächsten Seite) zeigt den sich aus der Aufgabenorientierung
ergebenden prinzipiellen Prozessablauf in Analogie zum Schaubild für das
allgemeine iterativ-inkrementelle Vorgehensmodell (siehe Bild 6.2 auf Seite 92). Zu erkennen
sind die Subprozesse als Kapselung der einzelnen Aktivitäten, die Phasen als zeitliches Gliederungselement
und der iterative Prozessdurchlauf, wobei der Iterationsumfang bedingt durch die
Aufgabenorientierung von Phase zu Phase anwächst. Dunkelgrau sind diejenigen Subprozesse
markiert, die innerhalb einer Phase zwingend durchgeführt werden müssen. Die Ausführung der
hellgrau markierten Subprozesse ist davon abhängig, ob diese zur Sicherstellung der Konsistenz
im Modell erforderlich sind. Als eingängige Kurzformel lässt sich festhalten: „Neues” entsteht in
den dunkelgrau markierten Subprozessen, in hellgrau markierten Subprozessen wird der Rest
des Modells „nachgezogen”.
6.2.4. rekursive Prozessanwendung
Zur Strukturierung des funktionalen Modells wurde in Kapitel 5.1.3.1 die Ebene eingeführt.
Ebenen gliedern das Modell entlang eines zunehmenden Detaillierungsgrades und umfassen ein
bis mehrere Teilmodelle. Zur Erstellung jedes Teilmodells wird der in diesem Kapitel beschriebene
Prozess einmal durchlaufen. Ein Ergebnis der Prozessanwendung ist die Subsystem-Architektur,
die Ausgangspunkt für die Anwendung des Prozesses auf der nächst tieferen Ebene ist: jede
Subsystemkomponente der übergeordneten Ebene kann zum SuB der tieferen Ebene werden.
Die Grafik in Bild 6.7 illustriert dieses prinzipielle Vorgehen.
In der Ebene 0 wird der Prozess auf das zu spezifizierende Gesamtsystem angewendet. Es entsteht
das schwarz umrandete Teilmodell, das - neben anderen Sichten - auch die Systemabgrenzungssicht
und die Subsystem-Architektur enthält.
Diese definiert die einzelnen Komponenten, aus denen sich das SuB in der nächst detaillierteren
Betrachtungsebene zusammensetzt. Im dargestellten Beispielfall besteht das SuB der Ebene 0
aus den drei Subsystem-Komponenten Subsystem1 (blau), Subsystem2 (grün) und Subsystem3
(rot), die zu einer Subsystemarchitektur verbunden sind. Sollen nun die einzelnen Subsysteme
weiter spezifiziert werden, kann der Prozess rekursiv angewendet werden.
Dazu wird zunächst festgelegt, für welche der drei Subsysteme eine genauere Spezifikation nötig
ist. Handelt es sich bei einem der Subsysteme beispielsweise um eine fertig zugekaufte Komponente
eines Drittherstellers, so kann sie möglicherweise entfallen. Im gezeigten Beispiel wird
jedoch jede der drei Subsystemkomponenten ausspezifiziert. Dazu wird für jedes Subsystem ein
eigenes Teilmodell angelegt. SuB des jeweiligen Teilmodells ist dabei die entsprechende Subsystemkomponente
aus Ebene 0. Diese Verbindung wird beispielhaft am Subsystem3 dargestellt:
Diese Subsystemkomponente aus Ebene 0 wird zum SuB in Ebene 1. Die anderen Subsystemkomponenten
- Subsystem1 und Subsystem2 - werden zu Akteuren in deren Systemumfeld.
Auf jedes dieser Teilmodelle wird nun wieder der hier beschriebene Prozess angewendet. Dieser
erzeugt je nach Erfordernis wiederum eine Subsystemarchitektur, die als Ausgangspunkt
für eine noch detailliertere Spezifikation in Ebene 2 dienen kann. Das Gesamtmodell setzt sich
letztendlich aus einer baumartigen Hierarchie einzelner Teilmodelle auf verschiedenen Ebenen
101