Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

nicht auszugehen. Die zusätzliche, projektspezifische Anschaffung eines weiteren Werkzeugs
scheitert üblicherweise an den sehr hohen Kosten sowohl für die Software an sich,
als auch für die dann zusätzlich erforderliche Ausbildung von Mitarbeitern.
(c) Ein nach dem in dieser Arbeit beschriebenen Vorgehen erstelltes Anforderungsmodell kann
mehr Informationen enthalten, als für eine konkrete Spezifikationsaufgabe benötigt wird.
Dies ist beispielsweise dann der Fall, wenn sich das Modell auf ein umfangreiches System
bezieht, das (entsprechend dem Ebenenkonzept) aus mehreren Subsystemen zusammengesetzt
ist. Bei der Ausschreibung eines Teilsystems wäre es dann nicht sinnvoll, alle
Modellbestandteile weiterzugeben. Vielmehr muss eine qualifizierte Auswahl der für eine
konkrete Anforderungsspezifikation erforderlichen Diagramme erfolgen.
Um diese Problembereiche zu umgehen, soll im Folgenden ein Dokumentationskonzept beschrieben
werden. Mit diesem lässt sich als Endprodukt des Prozesses eine dauerhafte, mit gängigen
Office-Programmen lesbare und ausdruckbare Dokumentation aller relevanten Inhalts des
funktionalen Modells erstellen.
Grundlegender Gedanke ist dabei, dass funktionale Modell als Arbeitsmittel für Analyse und Erstellung,
nicht aber für die dauerhafte Archivierung aufzufassen. Die intensiven Arbeitsphasen
am Modell (also im Wesentlichen die Phasen P0 - P3) finden meist in einem zeitlichen Rahmen
statt, in dem eine durchgängige Werkzeugverfügbarkeit sichergestellt ist. Diese Phasen können
und sollen daher weitgehend innerhalb des Modellierungswerkzeugs durchgeführt werden. Für
die anschließende Dokumentation muss hingegen ein Weg gefunden werden, die Arbeitsergebnisse
in eine archivierbare Form zu übertragen.
Dazu bietet es sich an, für eine spezifische Aufgabe - z.B. für ein konkretes Lastenheft - ein
Dokument in einem Anforderungsmanagement-Werkzeug wie IBM/telelogic DOORS oder einer
Office-Textverarbeitung zu erstellen. Der Aufbau dieses Dokumentes kann sich dabei frei
von den Gliederungsstrukturen im Modell an den üblichen Vorgaben der jeweiligen Organisationseinheit
orientieren. An bestimmten Positionen innerhalb dieses Dokuments werden dann
inhaltlich passende Diagramme aus dem Modell eingefügt. Dadurch ergibt sich ein Spezifikationsdokument,
dessen äußere Struktur ähnlich zu bestehenden, textbasierten Dokumentationen
ist. Gleichzeitig enthält es die relevanten - und nur die relevanten - Elemente aus dem Modell.
Der Hub an Spezifikationsqualität gegenüber klassischer textbasierter Spezifikation wird dabei
dadurch erzielt, dass die in den Diagrammen dargestellten Sachverhalte auf den konsistenten,
verifizierten und validierten Inhalten des funktionalen Modells basieren. Zusätzlich lassen sich
so einzelne Elemente des Modells durch eine eindeutige Kennziffer identifizieren 5 . Damit erhält
man eine eindeutige Referenz, mit der sich die Diagramme aus dem Modell, z.B. bei Reviews
und Prüfungen, gezielt ansprechen lassen.
Im Spezifikationsdokument werden üblicherweise neben den Diagrammen aus dem Modell noch
ergänzende Texte erforderlich sein. Diese können im ungünstigen Fall Widersprüche zu den im
den Diagrammen dargestellten Sachverhalte enthalten. Um diese Widersprüche auszuschließen
bietet es sich an, die Verbindlichkeit einzelner Bestandteile des Spezifikationsdokuments durch
zusätzliche Attribute zu steuern. Sinnvoll wäre beispielsweise, alle Diagramme mit einer „muss”-
Verbindlichkeit auszuzeichnen und alle erklärenden Texte mit einem „Info”-Attribut. Dadurch
würde festgelegt, dass nur die aus dem funktionalen Modell stammenden Diagramme verbindlicher
Spezifikationsbestandteile und in Zweifelsfällen Aussagen in den ergänzenden textlichen
Passagen vorzuziehen sind. Die Abbildung 6.27 verdeutlicht dieses Konzept.
5 DOORS vergibt beispielsweise für jede neue Zeile in einem Spezifikations-Modul eine lebenslang eindeutige Kennzahl,
die im gleichen Modul auch nach Löschung niemals neu vergeben wird.
143