Modellbasierte Anforderungsspezifikation sicherheitskritischer ...
Modellbasierte Anforderungsspezifikation sicherheitskritischer ...
Modellbasierte Anforderungsspezifikation sicherheitskritischer ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
• die Folgen von Gefährdungen zu analysieren<br />
• sicherzustellen, dass das sich ergebende Risiko tolerabel ist und<br />
• die tolerierbaren Gefährdungsraten (THR) abzuleiten.”<br />
Besonders relevant für diese Arbeit sind dabei die ersten beiden Punkte „Festlegung der Funktionsanforderungen”<br />
und „Identifikation der Gefährdungen”: Für die Festlegung der Funktionsanforderungen<br />
(erster Punkt) ist eine Systemfunktionssicht direkt hilfreich, aus der die benötigten<br />
Informationen unmittelbar entnommen werden können. Ebenso ist eine saubere Funktionsdefinition<br />
des Systems wichtige Grundlage für die Identifikation der relevanten Gefährdungen<br />
(zweiter Punkt). Dies geschieht üblicherweise in einem zweistufigen Prozess, der aus einer empirischen<br />
und einer kreativen Arbeitsphase besteht [BRA05, S. 32]. Während in der empirischen<br />
Phase beispielsweise Unfallanalysedaten ausgewertet werden, werden in der kreativen Phase<br />
mögliche Gefährdungen durch strukturierte Analysen herausgearbeitet. Ein gängiges Werkzeug<br />
für eine solche Analyse sind Fehlerzustandsart- und Fehlerauswirkungsanalysen (failure mode<br />
and effects analyses, FMEA). Der zugehörigen Norm IEC60812 lässt sich entnehmen, dass ein<br />
wichtiger Arbeitsschritt in einer FMEA die Ableitung einer funktionalen Struktur des Systems ist<br />
[IEC60812, S. 20]. Diese Aufgabe wird deutlich erleichtert, wenn bereits im Anforderungsmodell<br />
eine nachvollziehbare, logische Strukturierung der Systemfunktionen vorgenommen wurde.<br />
Es zeigt sich somit, dass eine dedizierte Aufnahme einer Systemfunktionssicht in das Anforderungsmodell<br />
nicht nur diesem selbst zugute kommt, sondern auch verschiedene, umgebende<br />
Prozesse unterstützen kann.<br />
5.1.4.2.2. Begriffsdefinitionen<br />
Bevor nun die Einzelheiten der Systemfunktionssicht vorgestellt werden, sollen zunächst die<br />
verwendeten Begriffe - Funktion, Szenario und Anwendungsfall - für die weitere Verwendung in<br />
dieser Arbeit definiert werden. Dies ist erforderlich, da für eben diese Begriffe in verschiedenen<br />
Kontexten voneinander abweichende Bedeutungen existieren. Die für diese Arbeit relevanten<br />
Begriffsdefinitionen werden ausgehend von der SysML/UML-Spezifikation und den CENELEC-<br />
Normen entwickelt. Grundlage ist der Funktionsbegriff in der DIN EN 50129. Dort wird der<br />
Begriff Funktion beschrieben als „Art von Aktion oder Tätigkeit, durch die ein Produkt seinen<br />
beabsichtigten Zweck erfüllt [EN50129, S. 11]”. Diese Definition ist weitgehend deckungsgleich<br />
mit der der use cases (Anwendungsfalls) im Sinne der UML/SysML. In der entsprechenden Spezifikation<br />
wird ein Anwendungsfall beschrieben als<br />
„A use case is the specification of a set of actions performed by a system, which<br />
yields an observable result that is, typically, of value for one or more actors or other<br />
stakeholders of the system. [. . . ] Each use case specifies a unit of useful functionality<br />
that the subject provides to its users.” [OMG07-2, S. 590]<br />
Insbesondere der letzte zitierte Satz entspricht inhaltlich weitgehend der Definition aus der DIN<br />
EN 50129. Auf Grund der Ähnlichkeit dieser Definitionen werden die Begriffe Funktion und<br />
Anwendungsfall (use case) im Folgenden synonym verwendet.<br />
In der UML-Spezifikation heißt es weiterhin<br />
„A use case can include possible variations of its basic behavior, including exceptional<br />
behavior and error handling.” [OMG07-2, S. 590]<br />
Daraus lässt sich die Existenz einer weiteren Gliederungsebene unterhalb der Anwendungsfälle<br />
herleiten: Jeder Anwendungsfall enthält verschiedene Variationen des durch ihn repräsentierten<br />
Verhaltens. Dieses Konzept wird für den Rahmen dieser Arbeit insofern übernommen, als dass<br />
43