Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

5.1.4.5. Subsystem-Struktur/Whitebox-Sicht
Gemeinsam war den in den vorherigen Kapiteln vorgestellten Sichten eine Blackbox-Perspektive
auf das SuB, das als monolithischer Block ohne Angaben zu dessen innerer Struktur betrachtet
wurde. In diesem Abschnitt wird nun die Sicht auf die Interna der Blackbox beschrieben. Diese
interne Sicht auf die einzelnen Komponenten des SuB dient gleichzeitig als Schnittstelle zur
Modellierung der nächst tieferen Detaillierungsebene entsprechend dem in Abschnitt 5.1.3.1
beschriebenen Gliederungskonzept. Die Subsystemsicht ist daher zur Umsetzung des Ebenenkonzepts
zwingend nötig.
5.1.4.5.1. Begriffsdefinitionen
Folgt man den Grundsätzen einer rein funktionalen Spezifikation, ist eine ausschließliche Blackbox-Darstellung
der Systemanforderungen ausreichend, da die Whitebox-Spezifikation eine Aufgabe
des Herstellers ist. Prinzipiell ist dieser Gedanke nachvollziehbar, weil so die Menge der
möglichen Lösungen für das in der Anforderungsspezifikation beschriebene Problem nicht unnötig
eingeschränkt wird. Auch hat jeder Hersteller damit die Freiheit, eine an seine Produkt- und
Entwicklungsstrategie angepasste Systemarchitektur zu entwickeln - der nicht spezifizierte Leerraum
kann mit eigenen Ideen und Konzepten ausgefüllt werden. Wenn dieses Paradigma auch
bei der Software-Entwicklung durchaus sinnvoll ist, ist es bei der Anforderungsspezifikation von
komplexen Systemen aus nachfolgend aufgeführten Gründen nicht immer zielführend.
Bei der Entwicklung von Software ist aus Auftraggeber-Sicht die Funktionalität die wesentliche
Eigenschaft. Die Bedeutung der Architektur der Software tritt hinter die funktionalen Eigenschaften
zurück, da an die einzelnen, internen Software-Komponenten meist keine Kundenanforderungen
gestellt werden. Zudem benötigt Software im Gegensatz zu Hardware per se keine
physische Struktur, verschleißt nicht und bedarf keiner regelmäßigen Wartung zur Erhaltung der
Verfügbarkeit 4 . Anders ist dies bei heterogenen Systemen. Insbesondere wenn mechanische, verschleißbehaftete
Bauteile wie Relais, Schalter, Motoren, Leuchtmittel oder ähnliches eingesetzt
werden, kann es sinnvoll sein, auch die Systemarchitektur in der Anforderungsspezifikation zu
beschreiben. Hat sich beispielsweise eine bestimmte Aufteilung der logischen Systemfunktionen
auf eine physische Systemstruktur bewährt, kann es sinnvoll für den Kunden sein, diese bei Neuanschaffungen
in der Systemanforderungsspezifikation vorzugeben 5 . Ähnliches gilt auch für die
Bevorratung von Ersatzteilen und die gesamte Instandhaltungslogistik. Hier liegt das Einsparpotenzial
in der Verwendung von bestimmten Komponenten, die schon in großer Stückzahl an
anderer Stelle beim Betreiber verwendet werden. Das Anforderungsmodell muss somit auch eine
Möglichkeit zur Spezifikation der internen Architektur des SuB vorsehen. Diese Whitebox-Sicht
auf das SuB muss dabei die folgenden Anforderungen erfüllen:
• Definition von Subsystemkomponenten innerhalb des SuB
• Darstellung der Subsystemarchitektur innerhalb des SuB
Die Subsysteme bilden weiterhin die Menge an Artefakten, auf die das in der Blackbox-Sicht
modellierte Verhalten zugeteilt werden kann. Dieser Vorgang wird in Abschnitt 5.1.4.4.6 beschrieben.
4 Davon ausgenommen sind Änderungen an der Software zur Beseitigung von Fehlern und von Sicherheitslücken
5 Für eine Grubenbahn in stark staubiger Umgebung kann es beispielsweise sinnvoll sein, möglichst viele Komponenten
der Leit- und Sicherungstechnik an einer zentralen, abgeschotteten Stelle zu konzentrieren, um übermäßiger
Verschmutzung vorzubeugen. In anderen Fällen mag hingegen eine möglichst verteilte Systemarchitektur
sinnvoll sein.
71