Anforderungsanalyse und Anforderungsdefinition für ...

Institut für Informatik
Arbeitsgruppe Softwaretechnik
Warburger Str. 100
33098 Paderborn
Anforderungsanalyse und
Anforderungsdefinition für sicherheitskritische
Systeme (inkl. formale Methoden)
Ausarbeitung im Rahmen des Seminars
Analyse, Entwurf und Implementierung zuverlässiger Software
von
Christian Löper
betreut durch
Prof. Dr. Wilhelm Schäfer
Paderborn, Februar 2004

Inhalt
1. Einleitung .............................................................................................................................. 03
2. Anforderungen an sicherheitskritische Systeme ................................................ 04
2.1. Funktionale Anforderungen .................................................................. 04
2.2. Allgemeine nicht funktionale Anforderungen ........................................ 04
2.3. Systemanforderungen ........................................................................... 04
2.4. Sicherheitsanforderungen ..................................................................... 06
2.5. Gesetzliche Anforderungen ................................................................... 07
2.6. Konflikte zwischen Anforderungen ....................................................... 07
3. Anforderungsspezifikation ........................................................................................... 08
3.1. Inhalt der Anforderungsspezifikation .................................................... 08
3.2. Eigenschaften einer guten Anforderungsspezifikation ........................... 09
3.3. Analyse der Anforderungsspezifikation ................................................. 11
4. Formale Methoden zur Anforderungsspezifikation ........................................... 12
4.1. Vorteile und Nachteile formaler Methoden ............................................ 12
4.1.1. Allgemein ..................................................................................... 12
4.1.2. Validierung der Spezifikation ........................................................ 13
4.1.3. Verifikation der weiteren Entwicklungsstufen .............................. 14
4.1.4. Automatische Entwicklungen aus der Anforderungsspezifikation . 14
4.2. Auswahl der geeigneten formalen Methode ........................................... 15
4.3. Die Z-Notation ...................................................................................... 16
4.4. Praxisbeispiel: Traffic Alert and Collision Avoidance System (TCAS) ...... 20
5. Fazit ......................................................................................................................................... 22
6. Anhang ................................................................................................................................... 23
6.1. Literaturverzeichnis .............................................................................. 23
6.2. Abbildungsverzeichnis ......................................................................... 23
Inhalt
2

1. Einleitung
Die Anforderungsspezifikation steht am Anfang des Entwicklungsprozesses. Sie bildet
die nötige Grundlage für die Entwicklung eines technischen Systems und ist von großer
Bedeutung für den Erfolg dieser Entwicklung. Im folgenden Schaubild des V – Modells
ist dieses dargestellt.
Abbildung 1: V – Lifecycle aus Storey [Sto95]
Einleitung
Fehler in der Anforderungsspezifikation einer Software sind für den größten Teil der
Unfälle verantwortlich, die durch Fehlverhalten von Software verursacht werden. Daher
sind korrekte, vollständige, konsistente und eindeutige Anforderungen von großer
Bedeutung im Entwicklungsprozess.
Im Folgenden werden die Anforderungen vorgestellt, die an ein sicherheitskritisches
System gestellt werden. Daraufhin wird die mit diesen Anforderungen zu entwickelnde
Anforderungsspezifikation dargelegt. Im weiteren werden formale Methoden erläutert,
die den Vorgang unterstützen.
3

2. Anforderungen an sicherheitskritische Systeme
Den Startpunkt für die Entwicklung eines neuen technischen Produktes bildet ein
Bedürfnis. Dieses ist beschreibbar durch eine Menge von Anforderungen. Für die
Entwicklung des Systems müssen diese geordnet und vervollständigt werden, mit dem
Ziel eine Anforderungsspezifikation zu entwickeln. Diese dient dann als Grundlage für
den Entwicklungsprozess. Der Softwareentwickler ist hierbei meistens in der Rolle des
Auftragnehmers, der die Anforderungen des Auftraggebers analysieren muss.
Folgende Aspekte müssen bei der Anforderungsanalyse für sicherheitskritische
Systeme berücksichtigt werden:
2.1 Funktionale Anforderungen
Funktionale Anforderungen sind die Funktionen, die das System erfüllen muss.
Beispielsweise bei einer Airbag Steuerung die Auslösung des Airbags bei bestimmten
Bedingungen.
2.2 Allgemeine Nicht-Funktionale Anforderungen
Hierzu gehören allgemeine Randbedingungen des Systems. Sie werden aufgeteilt in
Produkt Anforderungen, Prozess Anforderungen und externen Anforderungen.
Produkt Anforderungen: Produkt Anforderungen beschreiben direkt das zu
entwickelnde Produkt, sie sind unmittelbar aus den Benutzerwünschen abgeleitet (z.B.
Baugröße, Portabilität, Nutzbarkeit).
Prozess Anforderungen: Diese Anforderungen beschäftigen sich mit dem
Entwicklungsprozess. Beispiele sind: Entwicklungszeit, Programmiersprache,
Entwurfsmethode.
Externe Anforderungen: Diese Kategorie umfasst die nichtfunktionalen
Anforderungen, welche die beiden anderen Kategorien nicht erfassen, z.B. Kosten.
2.3 Systemanforderungen
Systemanforderungen sind Anforderungen, die von besonderer Bedeutung für
sicherheitskritische Systeme sind. Sie bestehen aus funktionalen, nicht funktionalen
und internen Anforderungen.
Funktionale Systemanforderungen
- Safety (Sicherheit)
- Correctness (Korrektheit)
- Trustability (Vertrauenswürdigkeit)
Anforderungen an sicherheitskritische Systeme
4

Nicht Funktionale Systemanforderungen
- Reliability (Funktionsfähigkeit)
- Availability (Verfügbarkeit)
- Performance (Leistung)
- Effizienz
- Speicherplatz
Interne Systemanforderungen
- Entwicklung
o Understandability (Verständlichkeit)
o Testability (Testbarkeit)
o Verifiability (Verifizierbarkeit)
- Wartung
o Recoverability (Wiederherstellbarkeit)
o Maintainability (Wartbarkeit)
o Extendability (Erweiterbarkeit)
o Portierbarkeit
- Wiederverwendbarkeit
Anforderungen an sicherheitskritische Systeme
Im Folgenden werden einige besonders wichtige Systemanforderungen beschrieben:
Reliability (Funktionsfähigkeit)
Die Reliability beschreibt die Fähigkeit des Systems über ein bestimmtes Zeitintervall
unter bestimmten Betriebsbedingungen, wie in der Spezifikation beschrieben, zu
arbeiten.
Availability (Verfügbarkeit)
Die Availability beschreibt die Wahrscheinlichkeit, dass das System zu jedem Zeitpunkt
korrekt funktioniert. Quantitativ beschreibbar ist so die Zeit korrekten Arbeitens
(übereinstimmend mit der Spezifikation) in einem bestimmten Zeitraum.
Availability = Betriebszeit / (Betriebszeit + Reparaturzeit)
Failsafe Operation:
Wenn ein Zustand des Systems als sicher gekennzeichnet werden kann und das System
unter allen Betriebsumständen diesen erreichen kann, geht das System in diesen
Zustand über, falls ein Fehler auftritt und dieser nicht behoben werden kann.
System Integrity
Die System Integrity ist die Fähigkeit des Systems, das es selbst auftretende Fehler
entdeckt und daraufhin weitere Operationen einleitet bzw. den Benutzer informiert.
Data Integrity
Dieses System erkennt wenn seine Datenbasis nicht korrekt ist und leitet dann
Operationen ein, um sie zu reparieren oder den Benutzer zu informieren.
5

System Recovery
Wenn das System ausfällt, kann es sich selbst wieder herstellen bzw. neu starten und
seinen Betrieb fortsetzen.
Maintanability (Wartbarkeit)
Die Wartbarkeit ist die Fähigkeit des Systems wartbar zu sein. Quantitativ wird diese
Anforderung durch die Mean Time to Repair (MTTR) dargestellt. Dieses ist die Zeit, die
benötigt wird, um das System nach einem Fehler wieder herzustellen. In diesem
Zusammenhang ist ebenfalls zu berücksichtigen, ob eine Wartung bei laufendem
Betrieb erfolgen kann, oder ob das System dafür abgeschaltet werden muss. Außerdem
muss bedacht werden, dass durch die Wartung möglicherweise Fehler in das System
gebracht werden.
Dependability (Zuverlässigkeit)
Diese Anforderung fasst die vorherigen zusammen. Sie beschreibt das Vertrauen, das
dem System entgegengebracht wird.
2.4 Sicherheitsanforderungen
Anforderungen an sicherheitskritische Systeme
Zusätzlich zu den Systemanforderungen muss ein sicherheitskritisches System
systemspezifische Sicherheitsanforderungen erfüllen.
Die mit dem System verbundenen Gefahren müssen identifiziert werden. Bei
sicherheitskritischen Systemen handelt es sich meistens um funktionale Gefahren, d.h.
Gefahren durch das durch die Software kontrollierte System. Die Identifizierung erfolgt
durch eine Gefahrenanalyse.
Die gefundenen Gefahren werden nun ihrer „Schwere“ nach klassifiziert. Dann werden
Methoden entwickelt, um diese Gefahren zu mindern bzw. ganz auszuschließen. Nun
folgt die Zuordnung geeigneter Reliability und Availability Anforderungen zu diesen
Methoden.
Schließlich muss ein angemessener Safety Integrity Level und dazu passende
Entwicklungsmethoden ausgewählt werden. Je höher der Safety Integrity Level, desto
strenger die Anforderungen an das Niveau der Entwicklungsmethoden. Der Safety
Integrity Level ist ein Maß dafür, wie stark die Integrität der Software zu der gesamten
Sicherheit des Systems beiträgt.
Aus diesen Überlegungen folgen funktionale und nichtfunktionale Anforderungen.
Es können bei dieser Analyse Gefahren gefunden werden, die nicht vollständig durch
eine Softwarelösung abgewendet werden können. Es muss dann entschieden werden
ob es andere Techniken zum Schutz des Systems gibt oder ob das verbleibende Risiko
akzeptiert werden kann.
6

2.5 Gesetzliche Anforderungen
Bei der Anforderungsanalyse ist ebenfalls auf Einhaltung gesetzlicher Standards zu
achten. Diese betreffen die Anforderungen selbst, sowie die benutzten
Entwicklungsmethoden. Die später nötige Zertifizierung des Produkts ist abhängig von
der Einhaltung dieser Standards. Mittlerweile wird in vielen Entwicklungsstandards die
Nutzung formaler Methoden vorgeschrieben. Die Britische Regierung fordert die
Nutzung formaler Methoden bei für sie entwickelten sicherheitskritischen Systemen.
Außerdem existieren nicht gesetzliche Entwicklungsstandards zur Unterstützung bei
der Entwicklung. Diese gibt es für viele verschiedene Industriebereiche.
2.6 Konflikte zwischen Anforderungen
Anforderungen an sicherheitskritische Systeme
Viele der Anforderungen stehen in Abhängigkeiten zueinander, was Konflikte ergibt. Es
tritt beispielsweise in fast allen technischen Systemen ein Konflikt zwischen hoher
Leistung und geringen Kosten auf.
Bei sicherheitskritischen Systemen mit einem Failsafe State existiert ein Konflikt
zwischen Realiability, Availability und Safety. Die Safety ist im sicheren Zustand am
größten. Da das System in diesem Zustand aber keine bzw. nicht die gewünschte
Funktionalität bietet, ist hier die Availability und die Realiability gleich null. Das
bedeutet, die Safety muss reduziert werden um ein funktionierendes System zu
erhalten.
Bei einem Notabschaltsystem für Atomkraftwerke kommt es zum Beispiel zum Konflikt
zwischen Safety und Performance. Aus Sicherheitsgründen sollte das Kraftwerk in einer
unklaren Situation immer abschalten, dieses ist aber natürlich aus Leistungs- und
Kostengründen nicht erwünscht.
Um diese Konflikte zu lösen, muss abgewogen werden, welche Anforderung wichtiger
ist. Dementsprechend müssen Prioritäten zugeordnet werden. Die nötigen Level von
Safety und Reliability müssen durch die Gefahrenanalyse bestimmt werden. Die
Anforderungsspezifikation muss alle Anforderungen im nötigen Maße berücksichtigen.
7

3. Anforderungsspezifikation
3.1 Inhalt der Anforderungsspezifikation
Anforderungsspezifikation
Mit Hilfe der oben genannten Überlegungen wird die Anforderungsspezifikation
entwickelt.
Sie beschreibt die Anforderungen an ein System hinsichtlich der Funktionen und der
Bedingungen, unter denen sie erfüllt werden müssen. Es wird dargestellt, was das
System leisten soll, nicht wie es realisiert werden soll.
Außerdem ist eine Beschreibung der Umwelt sinnvoll, in der die Software bzw. das
System eingesetzt werden soll. Damit wird verhindert, dass Fehler durch falschen
Einsatz des Systems entstehen. Eine spätere Portierung in eine andere Umgebung wird
hierdurch erleichtert, da die Anforderungen an sie klar definiert sind.
Die Anforderungsspezifikation dient auch als Vertragsdokument mit dem
Auftraggeber, da hier eindeutig die Systemeigenschaften bestimmt sind. Der
Softwareentwickler muss nach der Fertigstellung des Systems zeigen, dass die
Implementierung der Anforderungsspezifikation in allen Punkten gerecht wird. Daher
sollte die Spezifikation so geschrieben sein, dass objektiv feststellbar ist, ob dies
zutrifft.
Die Spezifikationssprache sollte eine eindeutige und streng definierte Semantik
besitzen. Sie sollte verständlich sein für die Softwareentwickler, ebenso für die
Ingenieure und Auftraggeber. Dieses trägt zum Vertrauen in das System bei und der
Auftraggeber kann herausfinden, ob die Spezifikation seinen Anforderungen
entspricht.
Die Spezifikation kann in handlichere Module aufgeteilt werden, um das Verständnis zu
erhöhen. Dann beinhaltet sie die Beschreibung der Struktur, die Beschreibung der
Schnittstellen sowie die Spezifikation der einzelnen Module mit den jeweiligen nicht
funktionalen Anforderungen. Den Schnittstellen werden, um Ungenauigkeiten bzw.
Doppeldeutigkeiten zu vermeiden Datentypen, zugeordnet.
Die Anforderungsspezifikation entspricht dem Top-Level-Design des Systems, sie ist
der Eingang für den Design Vorgang, der dann einer Serie von Verfeinerungen
entspricht.
Zur Verfassung der Bedienungsanleitung des Systems liefert die
Anforderungsspezifikation die Grundlage.
8

Wie aus dem folgenden Schaubild deutlich wird, steigen die Kosten für eine
Fehlerkorrektur. Je später ein Fehler im Entwicklungsprozess korrigiert werden muss,
desto teurer ist die Korrektur.
Abbildung 2: Kosten der Fehlerkorrektur aus Ebert [Ebe04]
Schwächen innerhalb der Anforderungsspezifikation werden häufig erst sichtbar, wenn
das System vollständig implementiert ist. Die Verbesserung solcher Schwächen erst zu
diesem Zeitpunkt ist, wie oben dargestellt, sehr aufwendig und demzufolge teuer.
Daher ist eine gute Anforderungsspezifikation von großer Wichtigkeit im Entwicklungsprozess.
Diese wird im Weiteren definiert.
3.2 Eigenschaften einer guten Anforderungsspezifikation
Anforderungsspezifikation
Korrektheit
Jede Aussage in der Anforderungsspezifikation muss korrekt eine Anforderung
wiedergeben. Wenn z.B. die Software eine Antwort innerhalb von 5 Sekunden liefern
soll, aber in der Anforderungsspezifikation eine Zeit von 10 Sekunden aufgenommen
ist, ist die Spezifikation nicht korrekt.
Eindeutigkeit
Jede Aussage hat nur eine mögliche Interpretation, es ist also nur eine
Implementierung möglich, die zu dieser Anforderungsspezifikation passt. Das
gewünschte Verhalten der Software muss so spezifiziert sein, dass es sich von dem
Verhalten jeder unerwünschten Implementierung eindeutig unterscheidet. Die
Anforderungsspezifikation kann hinreichend eindeutig sein. Sie lässt dann mehrere
Implementierungen zu, die im Verhalten gleich sind.
Vollständigkeit
Alles, was die Software leisten soll, ist in der Anforderungsspezifikation aufgenommen.
Außerdem sagt die Spezifikation für jeden möglichen Zustand, wie sich das System
verhalten soll. Hierbei sind auch ungewöhnliche Zustände zu beachten. Viele Systeme
fallen aus, weil die Spezifikation für eine bestimmte Situation nicht sagt, wie es sich
9

verhalten soll. Daher ist ein genaues Wissen über die Umwelt erforderlich, in der das
System eingesetzt werden soll. Da dieses nicht immer vollständig sein kann sind
entsprechende Annahmen zu treffen. Eine Anforderungsspezifikation kann hinreichend
vollständig bezüglich der Sicherheit sein. Sie ist dann nicht absolut vollständig,
garantiert aber unter allen Umständen sicheres Verhalten.
Verifizierbarkeit
Zu jeder Anforderung ist überprüfbar, ob sie in der Implementierung erfüllt worden ist.
Konsistenz
Die Konsistenz besagt, dass verschiedene Anforderungen in der Spezifikation nicht
Aussagen über den gleichen Bereich des Systems treffen dürfen, die im Konflikt
zueinander stehen.
Verständlichkeit
Die Dokumente sollen auch für Personen ohne Kenntnisse im Bereich der
Softwareentwicklung verständlich sein. Dieses ist sehr wichtig um Auftraggebern bzw.
Benutzern die Möglichkeit zu geben, die Anforderungsspezifikation auf Vollständigkeit
zu überprüfen. Außerdem erhöht das Verständnis der Anforderungen das Vertrauen in
das System.
Verfolgbarkeit
Die Herkunft jeder Anforderung sollte klar zu erkennen sein.
Kommentare
Zum besseren Verständnis sollten Kommentare eingefügt sein, dies gilt besonders bei
formalen Sprachen.
Modifizierbarkeit
Redundante Beschreibungen dürfen nicht vorkommen.
Anforderungsspezifikation
Besonders wichtig sind die Eigenschaften der Eindeutigkeit, Vollständigkeit, Konsistenz
und Korrektheit.
Mit einer natürlichen Sprache als Anforderungsspezifikationssprache ist die Erreichung
dieser Eigenschaften nur schwer möglich, daher ist der Einsatz formaler Methoden sehr
hilfreich.
10

3.3 Analyse der Anforderungsspezifikation
Anforderungsspezifikation
Da die fertiggestellte Anforderungsspezifikation die Grundlage für die weitere
Entwicklung ist, muss sie genauestens nach den oben genannten Gesichtspunkten
überprüft werden.
Die Eigenschaften der Konsistenz und Eindeutigkeit lassen sich bei dem Einsatz
formaler Methoden zur Anforderungsspezifikation automatisch prüfen.
Es sollte sichergestellt werden, dass die Spezifikation keine Möglichkeit bietet, die zu
einem katastrophalen Fehler in der beabsichtigten Umwelt führt.
Die Vollständigkeit und Korrektheit können nicht automatisch geprüft werden. Diese
sind von den Anforderungen bzw. Bedürfnissen des Auftraggebers abhängig. Die
Prüfung, ob die Anforderungen des Auftraggebers vollständig und korrekt spezifiziert
sind, heißt Validierung („Are we building the right thing?“ [McD93]). Dabei ist es
vorteilhaft, wenn der Auftraggeber die Anforderungsspezifikation selbst lesen kann. So
kann er direkt selbst herausfinden, ob sie seinen Bedürfnissen gerecht wird. Wenn die
Spezifikation validiert ist, ist sie eine eindeutige Repräsentation der Anforderungen an
das System. Auf diese Anforderungsspezifikation kann dann die weitere Entwicklung
aufbauen.
Die Ergebnisse der weiteren Entwicklungsschritte müssen auf ihre funktionale
Äquivalenz mit der Anforderungsspezifikation überprüft werden. Besonders für das
fertiggestellte System muss gezeigt werden, dass es der Anforderungsspezifikation in
allen Punkten gerecht wird.
11

4. Formale Methoden zur Anforderungsspezifikation
Die Verwendung formaler Methoden bedeutet die Nutzung formaler Sprachen zur
Anforderungsspezifikation. Diese basieren auf der Nutzung mathematischer Kalküle.
Sie bieten ein präzises Vokabular, eine genau definierte Syntax und eine eindeutige
Semantik. Das System wird exakt beschrieben, nicht der Entwurf. So werden nur sehr
wenige Einschränkungen für die Implementierung festgelegt. Es werden präzise die
Eigenschaften des System beschrieben ohne einzuschränken wie diese erreicht werden
sollen (was das System leisten muss, nicht wie es etwas leistet).
Heute wird vielfach der Einsatz formaler Methoden in gesetzlichen
Entwurfsvorschriften vorgeschrieben.
4.1 Vorteile und Nachteile formaler Methoden
4.1.1 Allgemein
Formale Methoden zur Anforderungsspezifikation
Spezifikationsdokumente in natürlichen Sprachen sind anfällig für Missverständnisse,
es ist nahezu unmöglich sie so zu verfassen, dass sie nicht missinterpretierbar sind. Es
ist sehr schwierig zu zeigen, dass die Spezifikation korrekt, vollständig und konsistent
ist, da die Prüfung vollständig auf Basis des Verständnisses des Ingenieurs für die
Anforderungen geschehen muss. Der Einsatz formaler Methoden bietet für viele dieser
Probleme gute Lösungen.
Eindeutigkeit
Die streng definierte Semantik und Syntax formaler Sprachen ermöglicht eine
eindeutige Interpretation der Spezifikation. Die Eindeutigkeit ist somit gegeben.
Dadurch ist die Spezifikation einfacher nachzuprüfen und zu ändern.
Werkzeugeinsatz
Ein weiterer Vorteil formaler Methoden ist, das es möglich ist mit Hilfe von
Testverfahren und automatischen Werkzeugen verschiedenste Eigenschaften und
Fehler festzustellen. Die Spezifikation kann so auf Konsistenz, Fehler in der
Orthographie und Richtigkeit der Struktur und ihrer internen Schnittstellen geprüft
werden. Die Ableitung von neuen Eigenschaften des Systems ist durch Beweis möglich.
Hierdurch kann gezeigt werden, dass keine mögliche Folge von Systemoperationen zu
einem unsicheren Zustand führen kann. Es lassen sich auch unnötige Anforderungen
erkennen, um diese dann entfernen zu lassen.
Reuseability (Wiederverwendbarkeit)
Eine formale Anforderungsspezifikation ist sehr hilfreich, wenn der Code in einem
neuen System wieder benutzt werden soll. Durch die genaue Beschreibung der
Eigenschaften und der Anforderungen an die Umwelt ist eine präzise Bewertung
möglich, ob der Code einsetzbar ist.
12

Maintainability (Wartbarkeit)
Durch das erhöhte Verständnis des Systems und der internen Wechselwirkungen wird
die Wartung erleichtert.
Entwicklungszeit / Kosten
Durch die relativ komplizierte Anwendung der formalen Sprachen und besonders auch
durch die ihnen zugrunde liegenden mathematischen Techniken, ist die Einarbeitung
nicht so einfach. Daher ist eine Schulung der Softwareentwickler notwendig. Dadurch
wird sich die Entwicklungszeit bei dem ersten mit formalen Methoden durchgeführten
Projekt verlängern. Diese Problematik verschwindet, wenn in nachfolgenden Projekten
mit den gleichen Methoden gearbeitet wird. Daher sind die Kosten bei dem ersten
Projekt mit formalen Methoden höher als gewöhnlich. Bei folgenden Entwicklungen
sind sie dann gleich groß, wie bei konventioneller Spezifikationsentwicklung.
Einschränkungen in der Wahl der Entwicklungsmethoden
Formale Methoden müssen auf jeder Entwicklungsstufe eingesetzt werden, um ihre
Vorteile vollständig zu entfalten. Dadurch werden die nutzbaren Entwicklungsmethoden
eingeschränkt.
Insgesamt ist die Nutzung formaler Methoden oft einschränkend. Sie bedeutet
meistens einen erhöhten Arbeitsaufwand. Daher ist zu überlegen, ob formale
Methoden nicht nur für sicherheitskritische Elemente des Systems verwendet werden,
da hier die Beweismöglichkeit der Eigenschaften sehr wichtig ist.
4.1.2 Validierung der Spezifikation
Die Nutzung einer formalen Sprache zur Spezifikation garantiert nicht ihre Korrektheit
und Vollständigkeit. Die Spezifikation basiert auf den informal ausgedrückten
Bedürfnissen bzw. Anforderungen des Auftraggebers, daher sind Missverständnisse
möglich. Diese führen dazu, dass die Anforderungsspezifikation unvollständig oder
unkorrekt sein kann. Durch eine Validierung kann die Vollständigkeit und Richtigkeit
gezeigt werden, es ist jedoch kein automatischer Beweis dieser Eigenschaften möglich.
Die direkte Validierung der Spezifikation wird durch formale Methoden erschwert. Das
Verständnis solch einer Spezifikation ist schwieriger als bei der Nutzung einer
normalen Sprache. Sie ist meistens für den Auftraggeber nicht verständlich. Daher gibt
es die Möglichkeit, eine formale Spezifikation in eine nicht formale automatisch
übersetzen zu lassen.
Eine andere Lösung dieses Problems ist die Animation der Spezifikation bzw. das
Prototyping. Hierbei wird das Verhalten der Software simuliert. So kann der
Auftraggeber anschaulich sehen, ob das spezifizierte System seinen Anforderungen
genügt. Die Animation ist auch von Vorteil um die Vollständigkeit zu überprüfen, d.h.
zu erkennen, ob es nicht spezifizierte Zustände gibt. Bei dem Einsatz einer
ausführbaren formalen Spezifikationssprache (z.B. OBJ) kann die Animation direkt
erfolgen. Bei Verwendung einer nicht ausführbaren formalen Sprache muss
automatisch oder halbautomatisch eine ausführbare Variante der Spezifikation erstellt
13

Formale Methoden zur Anforderungsspezifikation
werden. Bei einer nicht formalen Spezifikation müsste für die Animation ein eigenes
Programm entwickelt werden.
4.1.3 Verifikation der nachfolgenden Entwicklungsstufen
Um die Äquivalenz der nachfolgenden Entwicklungsstufen mit der Spezifikation
feststellen zu können, erfolgt eine Verifikation („Are we building the thing right?“
[McD93]). Bei nicht formaler Beschreibungsweise würde dieser Vorgang alleine auf den
Kenntnissen und Fähigkeiten des Ingenieurs beruhen. Durch eine Beschreibung des
Systems auf allen Ebenen mit dem Einsatz formaler Methoden wird es möglich, die
funktionale Äquivalenz zu beweisen. Dadurch wird ein erhöhtes Vertrauen in die
Ergebnisse der Verifikation erreicht.
Dies ist besonders wichtig, um am Ende der Entwicklung beweisen zu können, dass
das implementierte System den Anforderungen entspricht. Dieser Prozess ist allerdings
noch nicht vollständig automatisiert, so dass die Erfahrungen und das Können der
Softwareentwickler für die Verifikation unersetzlich sind.
Der formale Beweis die Anforderungen erreicht zu haben, ist für die Zertifizierung
eines Produkts sehr hilfreich, bzw. in den betreffenden Standards gefordert. Bei nicht
formaler Beschreibung ist kein Beweis möglich. Es sind nur Tests möglich, die aber nie
alle erdenklichen Fälle berücksichtigen können.
Zur Vereinfachung der Verifikation wird in einigen Ansätzen nur Wert auf die
Sicherheitsanforderungen gelegt. Dies macht den Beweis einfacher und vor allem
schneller.
4.1.4 Automatische Entwicklungen aus der Anforderungsspezifikation
Ein weiteres Argument für die Benutzung formaler Beschreibungen für die
Entwicklungsphasen ist die Möglichkeit einige Transformationen zwischen diesen zu
automatisieren. Beispielsweise könnte so direkt aus der Anforderungsspezifikation der
Softwareentwurf bzw. die Implementierung erzeugt werden. Ein weiterer Schritt wäre
dann die automatisierte Entwicklung der vollständigen Hardware und Software aus der
Anforderungsspezifikation. Allerdings wird es bis dahin noch eine längere Zeit der
Entwicklung benötigen. Zur Zeit stehen Werkzeuge zur Verfügung, die den
Softwareentwickler bei den Transformationen unterstützen, dies aber nicht vollständig
selbstständig zu seiner Zufriedenheit erledigen können. Besonders in der Effizienz und
der Codegröße sind vollständig automatisch erzeugte Implementierungen oftmals
unvorteilhaft. Auf diese Eigenschaften kommt es bei sicherheitskritischen Systemen
meistens besonders an, da sie häufig auch eingebettete Systeme sind, die in der
Massenproduktion hergestellt werden.
Die gleiche Codegröße, wie bei manueller Implementierung, kann nur erreicht werden,
wenn der Compiler speziell für die vorliegende Prozessorarchitektur entwickelt wurde.
Dieses trifft aber aufgrund der Vielzahl von Prozessorarchitekturen und des relativ
hohen Aufwandes in der Entwicklung eines solchen Compilers bisher nur selten zu. Es
werden zur Zeit immer mehr passende und auch bessere Compiler entwickelt. Die
14

automatische Codegenerierung wird daher in Zukunft immer häufiger eingesetzt
werden können.
In der folgenden Übersicht ist der Unterschied der Codegröße von automatisch
generiertem Code und der manuell erstellten Implementierung aufgezeigt. Der Code
wurde aus einer Statechart Darstellung erzeugt. Die automatische Generierung erfolgte
mit dem Statemate Codegenerator STARC [Kle03].
Abbildung 3: Vergleich Codegröße automatisch / manuell erzeugter Code
aus Kleinjohann [Kle03]
4.2 Auswahl der geeigneten Methode
Formale Methoden zur Anforderungsspezifikation
Da sich die meisten formalen Methoden auf ein Fachgebiet beschränken, ist es wichtig
die geeignete Methode auszuwählen.
Die oben beschriebenen automatischen Hilfsmittel sind nicht für alle formalen
Methoden verfügbar, daher ist bei der Auswahl ebenfalls darauf zu achten, dass die
gewünschten Werkzeuge verfügbar sind.
Es existieren fünf verschiedene Typen, die im Folgenden kurz charakterisiert werden:
1. Modellbasierte Ansätze
Diese bieten eine explizite und abstrakte Definition von Systemzuständen und
Transitionen zwischen diesen. So wird ein Modell des Systems, basierend auf
mathematischen Entities geschaffen. Es ist keine Darstellung von
Nebenläufigkeit möglich (z.B. Z und VDM).
2. Algebraische Ansätze
Es wird eine implizite Definition der Operationen durch Verbindung von
verschiedenen Operationen gegeben. Es erfolgt keine Definition von Zuständen
und keine Darstellung von Nebenläufigkeit. Die Beziehungen zwischen Objekten
werden mathematisch formuliert (z.B. OBJ und PLUSS).
15

3. Prozessalgebras
Diese bieten ein explizites Modell für nebenläufige Prozesse. Sie stellen das
Verhalten durch Bedingungen über die zulässige Kommunikation zwischen den
Prozessen dar (z.B. CSP und CCS).
4. Logikbasiserte Ansätze
Viele Ansätze nutzen Logiken um die Eigenschaften eines Systems zu
beschreiben (z.B. Temporale Logik, Intervall Logiken, Propositionale Logik und
Prädikatenlogik).
5. Netzbasierte Ansätze
Hier wird das Verhalten durch ein Netzwerk dargestellt, das Nebenläufigkeit
erlaubt. Es existieren Bedingungen unter denen die Daten von einem Knoten
zum anderen fließen können (z.B. Petrinetze und Prädikat Transitions Netze).
In der Praxis werden häufig Mischungen aus einigen Ansätzen verwendet, sogenannte
Hybride Sprachen. So können die Vorteile mehrerer Ansätze genutzt werden.
Vorteile bei der Validierung bieten ausführbare Spezifikationen (OBJ). So kann direkt
eine Simulation durchgeführt werden. Solch einen Spezifikation ist allerdings größer
und so schwieriger zu prüfen als eine, die in einer nicht ausführbaren Sprache (Z)
entwickelt wurde. Ein Ansatz, um dieses zu lösen, ist es, die Spezifikation in einer
nicht ausführbaren modellbasierten Sprache zu schreiben und sie dann anschließend in
eine ausführbare konvertieren zu lassen.
In der Industrie werden für sequentielle Systeme meistens VDM oder Z verwendet, für
nebenläufige meistens LOTOS und CCS.
4.3 Z-Notation
Formale Methoden zur Anforderungsspezifikation
Die Z-Notation basiert auf der typed set theory (Mengenlehre) und der Prädikatenlogik
1. Stufe. Sie ist eine modellbasierte Sprache.
Mathematische Datentypen können genutzt werden, um die Daten im System zu
modellieren. Die Darstellung des Verhaltens erfolgt durch die zugehörigen
mathematischen Gesetze. Durch die Prädikatenlogik ist es möglich, Effekte von
Aktionen zu beschreiben.
Eine Spezifikation in Z besteht aus Modulen, den Schemata. Hierbei wird zwischen
statischen und dynamischen Schemata unterschieden.
Statische Schemata beschreiben die Zustände, die ein System annehmen kann und die
Invarianten, die bei Zustandsänderungen eingehalten werden müssen.
Dynamische Schemata dienen der funktionalen Beschreibung des Systems. Sie
enthalten die möglichen Operationen, die Beziehungen zwischen den Ein- und
Ausgängen dieser Operationen und die Zustandsänderungen, die auftreten können.
Jedem Schema können zum besseren Verständnis Kommentare zugeordnet werden.
Zur Strukturierung können Hierarchien angelegt werden.
Ein Schema enthält zwei Teile: Die Signatur und die Prädikate. Die Signatur (oberhalb
der Trennlinie) deklariert Variablen, die Prädikate (unterhalb der Trennlinie)
beschreiben die Beziehungen zwischen diesen.
16

Die Z-Notation ist ein genormter ISO – Standard. 2002 wurde dieser fertiggestellt:
Information Technology - Z Formal Specification Notation - Syntax, Type System and
Semantics, ISO/IEC 13568:2002.
Der Einsatz der Z-Notation ist für Entwicklungen sicherheitskritischer Systeme für die
Britische und Australische Regierung vorgeschrieben.
Im Folgenden werden die grundlegenden Konzepte an einem einfachen Beispiel
erläutert (entnommen aus Spivey [Spi92]), dem BirthdayBook. Ein System, das
Geburtstage mit den zugehörigen Namen speichern soll.
Zuerst wird der Zustandsraum des Systems durch ein statisches Schema beschrieben:
BirthdayBook
known : P NAME
birthday : NAME →→ DATE
known = dom birthday
Die Variable known wird als Menge von Namen deklariert. Birthday ist eine Funktion
die aus gegebenem Namen das zugehörige Datum bestimmt. Die Aussage „known =
dom birthday“ ist eine Beziehung, die in jedem Zustand des Systems wahr sein muss
und von jeder Operation aufrechterhalten werden muss, eine Invariante des Systems.
Hier wird ausgedrückt, dass die Menge known gleich der Definitionsmenge der
Funktion birthday sein muss. Known kann durch die Invariante aus der Funktion
birthday abgeleitet werden.
Ein möglicher Zustand des Systems, der die Invariante erfüllt:
known = {John, Mike, Susan}
birthday = { John → 25.März,
Mike → 20.Dezember,
Susan → 20.Dezember}
Formale Methoden zur Anforderungsspezifikation
17

Nach der Beschreibung des Zustandsraumes können darauf mögliche Operationen
beschrieben werden. Hier eine Operation, die es ermöglicht Geburtstage hinzuzufügen:
AddBirthday
∆BirthdayBook
name? : NAME
date? : DATE
Durch die Deklaration ∆BirthdayBook wird ein Schema eingeleitet, das eine
Zustandsänderung auf dem durch BirthdayBook beschriebenen Zustandsraum bewirkt.
Dadurch werden vier Variablen eingeführt. Known und birthday als Zustände vor der
Zustandsänderung, known’ und birthday’ als solche nach der Änderung. Jedes
Variablenpaar muss die Invariante erfüllen. Als nächstes erfolgt die Deklaration der
Eingänge in die Operation: name? und date?. Die Fragezeichen zeigen, dass die
betreffende Variable eine Eingangsvariable ist. Eine Ausgangsvariable würde durch ein
Ausrufezeichen gekennzeichnet werden.
Durch „name? ∉ known” wird sichergestellt, dass der eingegangene Name noch nicht
in der Menge known vorhanden ist. Es wird keine Aussage getroffen, was passiert
wenn dies nicht so ist. Schließlich wird die Funktion birthday um den neuen Namen
und das neue Datum erweitert.
Nun kann erwartet werden, dass in der Menge known der neue Name auch vorhanden
ist:
known’ = known ∪ {name?}
name? ∉ known
birthday’ = birthday ∪ {name? → date?}
Dieses Theorem kann mit Hilfe der Invariante bewiesen werden:
known’ = dom birthday’ Invariante nach Operation AddBirthday
= dom (birthday ∪ {name? → date?}) Spezifikation AddBirthday
= dom birthday ∪ dom {name? → date?} Regel zum Operator dom
= dom birthday ∪ {name?} Regel zum Operator dom
= known ∪ {name?} Invariante vor Operation AddBirthday
Somit ist das Theorem bewiesen.
Formale Methoden zur Anforderungsspezifikation
Dieser Vorgang heißt Theorem Prooving. Als Eingang in den Vorgang dienen eine
Menge von Axiomen, eine zu prüfende Bedingung und eine Menge von Beweisregeln.
Die Bedingung und die Axiommenge muss in der gleichen formalen Sprache vorliegen.
Dann kann die zu prüfende Bedingung formal bewiesen werden bzw. es kann bewiesen
werden, dass sie nicht zutrifft.
18

Hierdurch kann die Fehlerfreiheit (die Konsistenz und Eindeutigkeit) einer Spezifikation
bewiesen werden. Außerdem können neue Eigenschaften abgeleitet werden. Das
Theorem Prooving ist somit für die Verifikation von großer Bedeutung.
Es gibt Werkzeuge, die dieses automatisch durchführen können. Diese sind aber in
ihrer Leistungsfähigkeit begrenzt. Da in der Praxis die Theoreme sehr viel länger sind
als in diesem Beispiel, sind auch sehr viele Permutationen der einzelnen Variablen des
Theorems möglich. Der Theorem Proover benötigt dann sehr viel Zeit, um alle diese
durchzugehen und den Beweis zu versuchen.
19

Formale Methoden zur Anforderungsspezifikation
4.4 Praxisbeispiel: Traffic alert and Collision Avoidance System (TCAS)
In der Luftfahrt wurden formale Methoden bei der Entwicklung des Traffic Alert and
Collision Avoidance system (TCAS) eingesetzt. Dieses System soll Zusammenstöße
zwischen zwei Flugzeugen in der Luft verhindern. Es gibt den Piloten in gefährlichen
Situationen Anweisungen zur Änderung der Höhe, um einen Zusammenstoß zu
vermeiden.
Die FAA (Federal Aviation Authority, Luftfahrtbehörde der USA) akzeptierte 1990 die
Anforderungsspezifikation des TCAS nicht als Basis für eine Zertifizierung. Die
Spezifikation bestand aus Englisch und Pseudocode, war also nicht formal. Um dieses
Problem zu lösen wurde aus dieser nicht formalen eine formale Spezifikation
entwickelt. Als formale Methode wurde dabei RSML (Requirements State Machine
Language), eine Weiterentwicklung der Statecharts, eingesetzt. Der Umfang der
Spezifikation blieb dabei gleich. Im folgenden ist das Statechart der höchsten Ebene
der TCAS Spezifikation abgebildet (Abbildung 4). Zusätzlich zu den Statecharts werden
die Transitionsbedingungen durch Tabellen dargestellt.
Abbildung 4: Höchste Ebene der TCAS Spezifikation aus Heimdahl [Hei02]
Nach der Fertigstellung der formalen Spezifikation, erfolgte eine Verifikation und
Validierung um die Pseudocode Spezifikation mit der RSML Spezifikation zu
vergleichen. Durch Modell Checking wurde die RSML Spezifikation auf Konsistenz und
Korrektheit überprüft. Beim Modell Checking wird überprüft, ob eine Bedingung in
allen möglichen Zuständen des Statechart gültig ist.
20

Beispiel für eine geprüfte Bedingung:
Verhinderung von fehlerhaften Ausweichmanövern:
Formale Methoden zur Anforderungsspezifikation
(Radio-Altimeter-Status = Valid & Own-Alt-Radio ≤1450) → ! Increase-Descend)
Dies bedeutet: Die Sinkrate nicht erhöhen, wenn die Höhe unter 1450 Fuß und der
Höhenmesser funktionsfähig ist.
Hierbei wurden viele Unstimmigkeiten entdeckt. Diese waren alle auf die fehlerhafte
Pseudocode Spezifikation zurückzuführen, aus der die RSML Spezifikation entwickelt
worden war.
Ergebnis der Betrachtung war, dass formale Methoden helfen die Anforderungen
fehlerfrei zu erfassen und eine kürzere Zeit zur Zertifizierung nötig wird.
21

5. Fazit
Fazit
Die Anforderungsspezifikation ist die Grundlage des Entwicklungsprozesses. Daher ist
die Erfüllung der an sie gestellten Forderungen (Vollständigkeit, Korrektheit,...) für den
Erfolg der Entwicklung von größter Bedeutung.
Formale Methoden sind sehr hilfreich um diese Eigenschaften zu erreichen, da sie die
Möglichkeit bieten einige Eigenschaften zu beweisen und bei anderen die Prüfung
erheblich erleichtern. Sie erhöhen das Vertrauen in ein System, da bewiesen werden
kann, das die Implementierung die Anforderungen in der Anforderungsspezifikation
erfüllt. Besonders im sicherheitskritischen Bereich wird der Einsatz formaler Methoden
aufgrund dieser Eigenschaften unverzichtbar.
Der einzige Nachteil beim Einsatz formaler Methoden ist die relativ komplizierte
Anwendung. Nach einer Einarbeitungszeit fällt dieser Nachteil aber weg.
Insgesamt überwiegen, meiner Meinung nach, die Vorteile beim Einsatz formaler
Methoden.
Außerdem sind formale Methoden sehr nützlich, um eine Zertifizierung zu erlangen
bzw. sie sind sogar dafür gefordert.
In Zukunft werden formale Methoden immer häufiger zur Entwicklung von
sicherheitskritischen Systemen eingesetzt. Dadurch werden viele Ausfallmöglichkeiten
schon in der Entwicklung ausgeschlossen und die entwickelten Systeme werden
zuverlässiger.
22

6. Anhang
6.1 Literaturverzeichnis
[Ebe04] Ebert, C.: Folien zur Vorlesung Software Engineering for Real-Time Systems.
Universität Stuttgart, WS 03/04
[Ger94] Gerhart, S.; Craigen, D.; Ralston,T.: Experience with Formal Methods in
Critical Systems. In: IEEE Software, Januar 1994, S. 21-39
[Gie04] Giese, H.: Folien zur Vorlesung Software Engineering for Safety Critical
Computer Systems. Universität Paderborn, WS 03/04
[Hei02] Heimdahl, M.; Leveson, N.; Reese, J. D.: Experiences form specifying the
TCAS II reguirements using RSML. 2002
[Kle03] Kleinjohann, B.: Folien zur Vorlesung Eingebettete Systeme. Universität
Paderborn, WS 02/03
[Lap92] Laprie, J. C. (Hrsg.): Dependability: Basic Concepts and Terminology in
English, French, German Italian and Japanese. Wien, Springer Verlag, 1992
[Lev95] Leveson, N.: Safeware: System Safety and Computers. Addison-Wesley, 1995
[McD93] McDermid, J.A.: Formal Methods: Use and Relevance for the Development of
Safety Critical Systems. In: Safety Aspects of Computer Control (Hrsg.:
Bennett,P.), Oxford, Butterworth-Heinemann, 1993, S. 96-153
[Som01] Sommerville, I.: Software Engineering. Addison-Wesley, 2001
[Spi92] Spivey, J.M.: The Z-Notation: A Reference Manual. second edition, Hemel
Hempstead, Prentice Hall, 1992
[Sto96] Storey, N.: Safety-Critical Computer Systems. Addison-Wesley, 1996
6.2 Abbildungsverzeichnis
Abbildung 1: V-Lifecycle aus Storey [Sto96]
Abbildung 2: Kosten der Fehlerkorrektur aus Ebert [Ebe04]
Abbildung 3: Vergleich Codegröße automatisch / manuell erzeugter Code aus
Kleinjohann [Kle03]
Abbildung 4: Höchste Ebene der TCAS Spezifikation aus Heimdahl [Hei02]
Anhang
23