Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

Weitere Magazine

Empfehlungen

Info

dd [Paket] Konsistenzen [ Allokation auf Subsysteme ] Senden von Objekten 1 Senden von Signalen 1 1 1 1 Allokation 1 1 Subsystemverwendung Empfangen von Signalen 1 1 Sonstiges Aktivitaetskonstrukt 1 Abbildung 5.27.: Allokation auf Subsystem-Artefakte 83
5.2. Nichtfunktionale Anforderungen und externe Dokumente Nachdem im vorherigen Abschnitt das funktionale Modell detailliert vorgestellt wurde, wird im Folgenden - als zweite wesentliche Komponente der <strong>Anforderungsspezifikation</strong> - die Abbildung der nicht-funktionalen Anforderungen und die Verknüpfung mit Inhalten externer Dokumente beschrieben. Bezogen auf das Gesamtkonzept betrifft dies die in Abbildung 5.28 grau hervorgehobenen Bereiche. Abbildung 5.28.: Einordnung der nicht-funktionalen Anforderungen in den BMW-Kontext 5.2.1. Nicht funktionale Anforderungen Neben den funktionalen Anforderungen, die im funktionalen Modell abgebildet werden, umfasst eine <strong>Anforderungsspezifikation</strong> üblicherweise auch zahlreiche nicht-funktionale Anforderungen. Diese legen fest, wie und unter welchen Bedingungen die spezifizierten Funktionen ausgeführt werden sollen. Je nach System, Einsatzumgebung und Anwendungsfall kann die Art der abzubildenden nicht-funktionalen Anforderungen deutlich unterschiedlich ausfallen. Dennoch lassen sich bestimmte Gruppen nicht-funktionaler Anforderungen für bahntechnische Systeme aus mehreren Quellen und Überlegungen ableiten: • Die CENELEC-Norm 50126 [EN50126] legt mit dem RAMS-Konzept für „Reliability, Availability, Maintainability und Saftey” (Zuverlässigkeit, Verfügbarkeit, Wartbarkeit und Sicherheit) wesentliche Kategorien für nicht-funktionale Systemanforderungen fest. Dies sind beispielsweise tolerierte Gefährdungsraten (tolerable hazard rates, THR) oder die mittlere geforderte Betriebsdauer zwischen Ausfällen (mean time between failure, MTBF). • Die DIN EN 50121 [EN50121] beschreibt Anforderungen an die elektromagnetische Verträglichkeit von Systemen im Bahnbereich. Auch aus dieser Norm lassen sich entsprechende nicht-funktionale Anforderungen an ein System ableiten, wie beispielsweise die maximalen Werte für elektromagnetische Abstrahlung. • Gleiches gilt für die Spezifikation der Umweltbedingungen, in denen ein System operieren soll. Diese werden für bahntechnische Systeme in der DIN EN 50125 [EN50125] definiert und umfassen beispielsweise zulässige Temperaturbereiche und zu ertragende mechanische Belastungen. • Weiterhin gehören auch projektspezifische Randbedingungen, wie beispielsweise Reaktionszeiten, Symboliken für Bedien- und Meldeeinrichtungen und Leistungsfähigkeitsanforderungen zu den nicht-funktionalen Anforderungen. 84
Seite 1:
Modellbasierte Anforderungsspezifik
Seite 4 und 5:
5.1.5.2. Konsistenz der Akteure . .
Seite 6 und 7:
1. Abstract In common with other te
Seite 8 und 9:
2. Einleitung Wie in anderen techni
Seite 10 und 11:
5 % der späteren Fehler aufgedeckt
Seite 12 und 13:
3. Bestandsaufnahme und Identifikat
Seite 14 und 15:
dest |−> q, adr |−> msg.adr] :
Seite 16 und 17:
Abbildung 3.1.: Das Verhältnis von
Seite 18 und 19:
und Testmodell und erweitert somit
Seite 20 und 21:
für LST-Modulverträge für die De
Seite 22 und 23:
Im Kontext des BMW-Prinzips lässt
Seite 24 und 25:
• Die zweite Unterklasse umfasst
Seite 26 und 27:
Abbildung 4.1.: Herunterbrechen der
Seite 28 und 29:
Insgesamt ergibt sich somit die in
Seite 30 und 31:
Abbildung 5.1.: Einordnung des funk
Seite 32 und 33:
5.1.1.3. Objektorientierung im Eise
Seite 34 und 35:
• Eignung für das Systems Engine
Seite 36 und 37:
5.1.2. Metamodell und Subset der Sy
Seite 38 und 39: Für die Anzahl der Ebenen gibt es
Seite 40 und 41: Modell_Ebene_Teilmodell_Sichten pac
Seite 42 und 43: (a) Das funktionale Konzept betrach
Seite 44 und 45: bdd [Modell] Data[ Kontexktkommunik
Seite 46 und 47: dd [Modell] Data[ Systemabgrenzungs
Seite 48 und 49: • die Folgen von Gefährdungen zu
Seite 50 und 51: uc [view] Systemfunktionssicht [ Te
Seite 52 und 53: dd [Modell] Data[ Systemfunktionssi
Seite 54 und 55: Im Rahmen des Anforderungsmodells k
Seite 56 und 57: Inhaltselement SysML-Sprachelement
Seite 58 und 59: 5.1.4.4. Systemverhaltenssicht Mit
Seite 60 und 61: hat beispielsweise Arabestani in [A
Seite 62 und 63: Abbildung 5.11.: Einordnung des Sys
Seite 64 und 65: wird - sofern möglich - eben diese
Seite 66 und 67: act [Aktivitaet] Druckluft erzeugen
Seite 68 und 69: • Kontinuierliche Übertragung vo
Seite 70 und 71: in einer Aktionssprache an den Kont
Seite 72 und 73: der Subsystemarchitektur (siehe 5.1
Seite 74 und 75: Verhaltensmuster Senden von Signale
Seite 76 und 77: 5.1.4.5. Subsystem-Struktur/Whitebo
Seite 78 und 79: enthalten ist. So verfügt die beis
Seite 80 und 81: Inhaltselement Diagrammart SuB Port
Seite 82 und 83: 77 Abbildung 5.22.: Beispielhafte E
Seite 84 und 85: 5.1.5. Konsistenzregeln Für die in
Seite 86 und 87: 5.1.5.2. Konsistenz der Akteure Die
Seite 90 und 91: Diese Aufstellung zeigt, dass es si
Seite 92 und 93: 87 Abbildung 5.29.: Prinzip der Ver
Seite 94 und 95: 6. Inkrementell-iterativer Erstellu
Seite 96 und 97: zen, wenn die Arbeitsschritte durch
Seite 98 und 99: 6.1.3. Einordnung in den Gesamtlebe
Seite 100 und 101: Von Nach Ausgetauschte Information
Seite 102 und 103: Ein solches Anforderungsprofil best
Seite 104 und 105: den könnte. Vielmehr soll diese ja
Seite 106 und 107: Letztendlich lässt sich keine eind
Seite 108 und 109: 103 Abbildung 6.7.: Rekursive Anwen
Seite 110 und 111: NoMagic in der Version 14.0 zum Ein
Seite 112 und 113: Ideenskizzen, implizite Vorstellung
Seite 116 und 117: 111 Abbildung 6.12.: Detaillierung
Seite 118 und 119: vom BÜ die Anzeige des Befahrbarke
Seite 122 und 123: act [Aktivitaet] P2 Spezifikation S
Seite 124 und 125: Entwicklungsziel angestrebt werden,
Seite 126 und 127: Als Ergebnis liefert der Subprozess
Seite 128 und 129: diagramm dargestellte Soll-Kommunik
Seite 130 und 131: Testfallgenerierung ein bei der man
Seite 132 und 133: act [Aktivitaet] P3 Spezifikation S
Seite 134 und 135: Weiterhin wird im Beispielmodell an
Seite 136 und 137: 6.4.2. S2 - Systemfunktionssicht be
Seite 138 und 139:
schriebene Vorgehen an: • Zunäch
Seite 140 und 141:
die Szenariensicht ist: Letztere ze
Seite 142 und 143:
act [Aktivitaet] S5 Systemverhalten
Seite 144 und 145:
Abbildung 6.24.: Automatisierter Ve
Seite 146 und 147:
act [Aktivitaet] S7 Subsystemsicht
Seite 148 und 149:
nicht auszugehen. Die zusätzliche,
Seite 150 und 151:
7. Zusammenfassung, Ergebnisse und
Seite 152 und 153:
de ein iterativ-inkrementelles Vorg
Seite 154 und 155:
Literaturverzeichnis [ALE02] ALEXAN
Seite 156 und 157:
[ISO19005] Norm ISO 19005-1. Docume
Seite 158 und 159:
[WES00] WEISSTEIN, Eric W.: Determi
Seite 160 und 161:
dd [Modell] Data[ Systemabgrenzungs
Seite 162 und 163:
dd [Modell] Data[ Szenariensicht ]
Seite 164 und 165:
dd [Modell] Data[ Subsystemsicht ]
Seite 166 und 167:
B. Metamodell-Aktivitätsdiagramme
Seite 168 und 169:
act [Aktivitaet] P1 Spezifikation S
Seite 170 und 171:
act [Aktivitaet] P3 Spezifikation S
Seite 172 und 173:
act [Aktivitaet] S1 Systemabgrenzun
Seite 174 und 175:
act [Aktivitaet] S3 Szenariensicht
Seite 176 und 177:
act [Aktivitaet] S5 Systemverhalten
Seite 178:
act [Aktivitaet] S8 Nicht-funktiona
Alle anzeigen

Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?