Modellbasierte Formalisierung von Anforderungen für eingebettete Systeme im Automotive-Bereich
Doktorarbeit / Dissertation, 2008, 209 Seiten
Modellbasierte Formalisierung von Anforderungen
Seite 2
Modellbasierte Formalisierung von Anforderungen
Institut für Informatik
der Technischen Universität München
Modellbasierte Formalisierung von Anforderungen
für eingebettete Systeme im Automotive-Bereich
Andreas Fleischmann
Vollständiger Abdruck der von der Fakultät für Informatik der Technischen Universität München zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigten Dissertation.
Die Dissertation wurde am 30. Januar 2008 bei der Technischen Universität München eingereicht und durch die Fakultät für Informatik am 11. Juni 2008 angenommen.
Seite 3
Modellbasierte Formalisierung von Anforderungen
Seite 4
Modellbasierte Formalisierung von Anforderungen
Kurzfassung
Anforderungen sind ein zentrales Arbeitsprodukt im Entwicklungsprozess, mit dem Stakeholder mit sehr unterschiedlichen Bedürfnissen arbeiten müssen. Hierbei kann man vereinfachend un- terscheiden zwischen
• eher informell (also nicht mithilfe formaler Modelle) denkenden und arbeitenden Stake- holdern (beispielsweise Kunden, Marketing, Schulungspersonal), die Anforderungen meist natürlichsprachig formulieren, weil dies die einzige gemeinsame Sprache ist, die alle beteiligten Stakeholder gleichermaßen souverän verstehen und benutzen können,
• und eher formal geschulten und arbeitenden Stakeholdern (beispielsweise Designer, Tester), die Anforderungen gerne in einer formal modellierten Form bekommen wür- den, die sich möglichst nahtlos in ihre Design- oder Testmodelle übertragen lässt. In der Praxis ist es sehr schwer, eine Darstellungsform für Anforderungen zu finden, die den Bedürfnissen dieser beiden Gruppen gleichermaßen gerecht wird: Entweder werden Anforde- rungen informell notiert, sind dadurch inhärent missverständlich, eine systematische Qualitäts- sicherung ist schwierig und der Übergang zum Design fehleranfällig; oder aber die Anforderun- gen werden formal notiert, wodurch der Prozess der kreativen Anforderungserarbeitung gestört und eine Validierung durch viele Stakeholder unmöglich wird.
In dieser Arbeit wurde daher ein Ansatz zur Formalisierung von Anforderungen entwickelt, der sich dadurch auszeichnet, dass er einerseits informell formulierte Anforderungen schrittweise in eine formalere Form bringt (so dass Anforderungen präziser formuliert sind und Konsistenzsi- cherung und Vervollständigung leichter ausgeführt werden können) und dabei andererseits die Verständlichkeit der Anforderungen erhält (so dass die Anforderungen weiterhin von informell denkenden Stakeholder verstanden und validiert werden können).
Im Kern besteht der Ansatz dieser Arbeit darin,
• für eine geeignete Teilmenge der Anforderungen für in Fahrzeuge eingebettete Soft- waresysteme (nämlich funktionale Nutzeranforderungen) das zugrundeliegende Denk- modell zu identifizieren und formal zu definieren,
• dann eine für die im Requirements Engineering anfallenden Aufgaben (insbesondere Vervollständigung, Konsistenzsicherung, Validierung) geeignete semiformale Darstel- lungsform des Modells zu definieren
• und die Anforderungen entsprechend zu modellieren mit einer Formalisierungs- methodik, die informelle Anforderungen in ihre Bestandteile zerlegt, umformuliert, strukturiert und ergänzt.
Auf der Grundlage des formalen Modells und der für das Anforderungsmanagement zugeschnit- tenen semiformalen Darstellungsform konnte eine pragmatische und wirkungsvolle Formalisie- rungsmethodik für funktionale Nutzeranforderungen erarbeitet werden, die aus vier aufeinander aufbauenden Schritten besteht:
• Im ersten Schritt, der Klassifikation, werden die Anforderungen zunächst geeignet klas- sifiziert; dies ist nötig, da die Anforderungen für eingebettete Softwaresysteme in Fahr- zeugen sehr heterogen sind und sich entsprechend ihrer Klassifikation auf ganz unter-
Seite 5
Modellbasierte Formalisierung von Anforderungen
schiedliche Modelle beziehen – und dementsprechend auch unterschiedlich formalisiert werden müssen. In diesem Schritt wird also zunächst aus der gesamten Anforderungs- menge die Teilmenge der funktionalen Nutzeranforderungen herausgefiltert.
• Im zweiten Schritt, der Zerlegung und Formulierung, werden die wesentlichen Bestand- teile der klassifizierten Anforderungen identifiziert, und entsprechend dem zugrundelie- genden Modell zunächst einzeln modelliert und umformuliert. Danach werden die An- forderungen selbst modelliert, indem die vorher modellierten Bestandteile innerhalb der Anforderungen standardisiert angeordnet und die Beziehungen zwischen diesen Be- standteilen standardisiert formuliert werden.
• Nach der Umformulierung werden in einem dritten Schritt, der Strukturierung, die An- forderungen in eine Diensthierarchie eingeordnet. Da eine sinnvolle Durchgängigkeit zum Design höhere Ansprüche an die Vollständigkeit der Anforderungen stellt und die- se durch die Modellierung hergestellt wird, führt dies zu einer erheblich größeren An- forderungsmenge, wodurch diese Strukturierung notwendig wird, um diese große An- forderungsmenge noch übersichtlich darstellen und systematisch qualitätssichern zu können.
• Im vierten Formalisierungsschritt, der Übergabe, werden die modellierten und struktu- rierten Anforderungen, die aber noch in einer natürlichsprachigen Darstellungsform vorliegen, in eine dem Design angemessene Darstellungsform (in dieser Arbeit reprä- sentiert durch die Dienstbeschreibungssprache der CAR-DL) übersetzt. Da das zugrun- deliegende Modell gleich bleibt und nur die Darstellungsform geändert wird, ist der Übergang vom Anforderungsmanagement zum Design wohldefiniert und kann ohne großen Aufwand, ohne große Fehlermöglichkeiten und leicht vollzogen werden. Dieses Vorgehen wurde im Rahmen eines Forschungsprojektes zusammen mit führenden deut- schen Automobilherstellern und -zulieferern entwickelt und an einer Fallstudie aus dem Auto- mobilbereich erprobt. Die entwickelte Formalisierungsmethodik hat dabei folgende Vorteile gezeigt:
• Die auf diese Weise umformulierten Anforderungen haben eine höhere Qualität als in- formelle Anforderungen, da das der Umformulierung zugrundeliegende Modell be- stimmte Eigenschaften der Anforderungen (insbesondere Konsistenz, Vollständigkeit, Übersichtlichkeit, Verständlichkeit, Präzision) steigert und die entsprechenden kon- struktiven und analytischen qualitätssichernden Maßnahmen gezielt unterstützt.
• Gleichzeitig bleibt (im Gegensatz zu den meisten bislang existierenden Formalisie- rungsansätzen für Anforderungen) durch die gewählte Darstellungsform des Modells die Verständlichkeit der Anforderungen erhalten, so dass eine Bearbeitung und Validie- rung durch informell denkende Stakeholder weiterhin möglich ist.
• Da beim Übergang zum Design die Anforderungen nicht neu modelliert werden müs- sen, sondern lediglich die Darstellungsform des Modells gewechselt wird, ist der Über- gang besser nachvollziehbar, weniger fehleranfällig und weniger aufwändig als mit in- formellen Anforderungen.
Seite 6
Modellbasierte Formalisierung von Anforderungen
Danksagung
Bei Prof. Manfred Broy bedanke ich mich herzlich für seine Anleitung und Betreuung während der letzten Jahre und vor allem für die Möglichkeit, mich in mehreren Forschungsprojekten mit stets wachsender Verantwortung, zuletzt als Projektleiter im Forschungsverbund Mobilsoft, mit vielfältigen Problemstellungen des Requirements Engineering befassen zu können. Ich habe in den Jahren am Lehrstuhl sehr von der hier gelebten Professionalität profitiert, viele wichtige Erfahrungen machen können und die Balance aus Verantwortung und Raum für eigenes Enga- gement stets sehr geschätzt.
Auch meinem Zweitbetreuer, Prof. Helmuth Partsch, möchte ich danken, dass er bereitwillig meine Arbeit mitbetreut und mir gerade in der Schlussphase wertvolles Feedback gegeben hat. Bei meinen Kollegen aus dem Projekt Mobilsoft, Judith Hartmann, Christian Pfaller, Martin Rappl, Sabine Rittmann und Doris Wild, möchte ich mich ganz herzlich bedanken für die tolle Atmosphäre, die vielen Diskussionen, die gegenseitige Inspiration und Unterstützung und ganz generell für die sehr gute Zusammenarbeit.
2006 bin ich mit der Unterstützung von Herrn Professor Broy mit einer halben Stelle zu Pro- Lehre, dem hochschuldidaktischen Bereich der Carl von Linde-Akademie gewechselt. Dank gebührt hier besonders meiner Kollegin Katharina Spies, die mir als Leiterin von ProLehre stets genügend Raum für meine Promotion verschafft hat und mich immer ermutigt und angetrieben hat.
Meiner Bürokollegin Dagmar Koss möchte ich danken für ihre Geduld, wenn das Telefon mal wieder nicht aufhörte zu klingeln, oder das Whiteboard hin und wieder vollkommen von mir in Beschlag genommen war.
Ich danke allen Kollegen, mit denen ich zusammen in Projekten gearbeitet habe, und von denen ich vieles gelernt habe: Markus Pister, Jewgenij Botaschanjan, Heiko Loetzbeyer, Veronika Thurner, Alexander Wißpeintner, Eva Geisberger und Alexander Ziegler. Aus der Vielzahl der weiteren Kollegen, die hier am Lehrstuhl arbeiten, möchte ich besonders Gerd Beneken, Bern- hard Schätz, Leo Kof und Roland Leisibach, sowie meiner Diplomandin Kathrin Amann für die anregenden Diskussionen danken.
Ohne die moralische und kulinarische Unterstützung und Ermutigung meiner Freunde und Fa- milie wäre diese Arbeit nie zustande gekommen. Ich möchte an dieser Stelle besonders Lars Schuster und Lena Böttger danken, sowie Katharina Neumeyer, Claudia Morgenstern, Birgit Becker, Matthias Hofmann, Birgit Halbgewachs, Annette Spiekermann, Stephan Sack und Ulli Bals – und natürlich meiner Schwester Christina und meinen Eltern.
Andreas Fleischmann,
Seite 7
Modellbasierte Formalisierung von Anforderungen
Inhaltsverzeichnis
Kurzfassung 5
Danksagung 7
Inhaltsverzeichnis........................................................................................................................8
Teil I: Einführung
1. Motivation und Zielsetzung 13
1.1 Bedeutung der Anforderungen 13
1.2 Herausforderungen für die Dokumentation von Anforderungen 17
1.3 Zielsetzung und Nutzen der Arbeit 21
1.4 Aufbau der Arbeit 24
2. Grundlagen 26
2.1 Requirements Engineering 26
2.2 Modellbasierung 28
2.3 Formalisierung 29
2.4 Eingebettete Systeme im Automotive Bereich 30
2.4.1 Eingebettete Systeme 30
2.4.2 Automotive-Spezifika 31
3. Wissenschaftliche Vorgehensweise und Fallstudie 33
3.1 Vorarbeiten 33
3.2 Wissenschaftliche Vorgehensweise und Validierungsansatz 34
3.3 Fallstudien 35
3.3.1 Abstandsgeregelter Tempomat (A)CC 35
3.3.2 Türsteuergerät (TSG) 38
Teil II: Formalisierungskonzept
4. Auswahl der zu formalisierenden Anforderungen 42
4.1 Notwendigkeit einer formalisierungsspezifischen Klassifizierung 42
4.2 Kriterien für eine formalisierungsspezifische Klassifizierung 43
4.2.1 Durchgängigkeit zur Klassifikation im Design 44
4.2.2 Durchgängigkeit zur Klassifikation der Elicitation 45
4.2.3 Spezifische Eignung für die Formalisierung 45
4.3 Definition der formalisierungsspezifischen Klassifizierung 46
4.3.1 Prozessanforderung 47
4.3.2 Geschäftsanforderung 47
4.3.3 Nutzeranforderung 48
4.3.4 Systemanforderung 49
4.4 Konsequenzen dieser Klassifikation 50
4.4.1 Verzahnung von Anforderungsmanagement und Design 50
4.4.2 Atomarisierung von Anforderungen 50
4.4.3 Seiteneffekte einer Klassifikation 51
4.5 Auswahl der Klasse der funktionalen Nutzeranforderungen 51
5. Formale Definition des zugrundeliegenden Modells 53
5.1 Bedeutung des Modells für die Formalisierung 53
5.2 Informelle Beschreibung des Modells 54
5.2.1 Unterscheidung in Nutzer- und Systemsicht 54
5.2.2 Die Nutzersicht 55
5.2.2.1 Ereignisse Aktivitäten Zustände 56
Seite 8
Modellbasierte Formalisierung von Anforderungen
5.2.2.2 Parameter und Variablen 59
5.2.2.3 Reaktionsverhalten Situationsverhalten und Invarianten 60
5.2.3 Systemsicht und Übergang zum Designmodell 61
5.3 Formale Definition des Modells 61
5.3.1 Zeit 61
5.3.2 Variablen 62
5.3.3 Zustände 62
5.3.4 Zustandsraum 63
5.3.5 Ereignisse 63
5.3.6 Zustandsübergänge 64
5.3.7 Aktivitäten und ihre Parameter 64
5.4 Aussagen auf dem formalen Modell 65
5.4.1 Reaktionsverhalten 66
5.4.2 Situationsverhalten 68
5.4.3 Invarianten 69
5.5 Zusammenfassung des formalen Modells 69
6. Definition einer geeigneten Darstellungsform 72
6.1 Qualitätskriterien für die Darstellung von Anforderungen 72
6.2 Dimensionen der verwendeten Darstellungsform 74
6.3 Darstellung der Anforderungsbestandteile 75
6.3.1 Darstellung von Ereignissen und Zuständen 77
6.3.1.1 Verwaltung Strukturierung von Ereignissen und Zuständen 77
6.3.1.2 Formatierung und Formulierung von Ereignissen und Zuständen 79
6.3.2 Darstellung von Aktivitäten und ihren Parametern 80
6.3.2.1 Verwaltung Strukturierung von Aktivitäten und Parametern 80
6.3.2.2 Formulierung und Formatierung von Aktivitäten und Parametern 80
6.3.3 Darstellung von Variablen 81
6.4 Darstellung der Anforderungen 81
6.4.1 Schlüsselworte 82
6.4.2 Darstellung von Reaktionsverhalten 84
6.4.3 Darstellung von Situationsverhalten 85
6.4.4 Darstellung von Invarianten 86
6.5 Strukturierung von Anforderungen 87
6.5.1 Darstellung einzelner Dienste 89
6.5.2 Darstellung der Diensthierarchie 93
6.6 Mächtigkeit der Sprache 97
6.7 Zusammenfassung 99
Teil III: Formalisierungsmethodik
7. Klassifikation 101
7.1 Kurzbeschreibung 101
7.2 Datenelemente 101
7.2.1 Informelle Anforderung 103
7.2.2 Klassifizierte Anforderung 104
7.2.3 Prozessanforderung 105
7.2.4 Geschäftsanforderung 106
7.2.5 Nutzeranforderung 106
7.2.6 Systemanforderung 107
7.3 Aktivitäten 108
7.3.1 Anforderungen aus der Elicitation übernehmen 109
7.3.2 Anforderung klassifizieren 109
7.3.3 Anforderung atomarisieren 110
Seite 9
Modellbasierte Formalisierung von Anforderungen
7.3.4 Anforderung filtern 110
7.3.5 Formalisierungsziel festlegen 111
7.4 Demonstration und Diskussion anhand der Fallstudie 111
7.5 Zusammenfassung 113
7.6 Steckbrief Klassifikation 114
8. Formulierung 115
8.1 Kurzbeschreibung 115
8.2 Datenelemente 115
8.2.1 Logische Aktion 117
8.2.1.1 Ereignis 117
8.2.1.2 Zustand 118
8.2.1.3 Zustandsraum 118
8.2.1.4 Aktivität 119
8.2.1.5 Variable 119
8.2.1.6 Parameter 119
8.2.2 Katalog logischer Aktionen 120
8.2.3 Anforderungsmuster 120
8.2.3.1 Systemreaktion 121
8.2.3.2 Systemveränderung 121
8.2.3.3 Ereignisabhängiges Verbot 122
8.2.3.4 Situationsverhalten 122
8.2.3.5 Situationseinschränkung 122
8.2.3.6 Ereignisunabhängiges Verbot 123
8.2.3.7 Invariante 123
8.3 Aktivitäten 124
8.3.1 Extraktion der logischen Aktionen 124
8.3.2 Anwendung der Anforderungsmuster 125
8.4 Demonstration und Diskussion anhand der Fallstudie 125
8.4.1 Ausgangssituation 125
8.4.2 Demonstration des gesamten Ablaufs im Überblick 126
8.4.3 Extraktion von logischen Aktionen im Detail 128
8.4.4 Anwendung der Anforderungsmuster im Detail 131
8.5 Zusammenfassung 133
8.6 Steckbrief Formulierung 133
9. Strukturierung 135
9.1 Kurzbeschreibung 135
9.2 Datenelemente 135
9.2.1 Dienst 136
9.2.2 Diensttabelle 137
9.2.3 Lastenheft 137
9.3 Aktivitäten 139
9.3.1 Diensttabelle erstellen 139
9.3.2 Anforderungen den Diensten zuordnen 140
9.3.3 Dienste analysieren 140
9.3.4 Lastenheft generieren 141
9.4 Demonstration und Diskussion anhand der Fallstudie 141
9.5 Zusammenfassung 144
9.6 Steckbrief Strukturierung 145
10. Übergabe ans Design 146
10.1 Referenzmodell für das modellbasierte Design 146
10.2 Datenelemente 147
10.2.1 Design Aktion 148
10.2.2 Design Dienst 148
10.2.3 Design Invariante 148
Seite 10
Modellbasierte Formalisierung von Anforderungen
10.3 Übersetzung der Anforderungs- in Designelemente 149
10.3.1 Übersetzen von logischen Aktionen 149
10.3.2 Übersetzen von Verhaltensanforderungen 150
10.3.3 Übersetzen von Invarianten 151
10.4 Rückkopplung vom Design ins Anforderungsmanagement 152
10.5 Aktivitäten 153
10.5.1 Logische Aktionen und Invarianten ans Design übergeben 153
10.5.2 Anforderung ans Design übergeben 153
10.6 Zusammenfassung 154
10.7 Steckbrief Übergabe ans Design 154
Teil IV: Einbettung in den Entwicklungsprozess
11. Datenmodell 156
11.1 Datenmodell der Formalisierung 156
11.2 Einordnung in das Referenz-Datenmodell 159
12. Aktivitätenmodell 162
12.1 Aktivitätenmodell der Formalisierung 162
12.2 Einordnung in das Referenz-Aktivitätenmodell 163
12.3 Verzahnung von Anforderungserarbeitung und -dokumentation 165
13. Reifegradmodell 168
13.1 Referenzmodelle für die Reife einer Anforderung 168
13.2 Einordnung der Formalisierung in ein Reifegradmodell 171
13.2.1 Specification 171
13.2.2 Agreement 171
13.2.3 Representation 172
Teil V: Bewertung und Ausblick
14. Diskussion ähnlicher Arbeiten 174
14.1 Das Sophist Regelwerk 174
14.2 ATTEMPTO CONTROLLED ENGLISH 176
14.3 Sicherheitsfachsprache der Uni Cottbus 177
14.4 Modellbasierte Erfassung von Anforderungen mit UML 178
14.5 Formalisierungsansatz nach AUTORAID 178
14.6 Anforderungserfassung in OCTOPUS UML 179
14.7 Die Spezifikationssprache SALT 181
15. Zusammenfassung 183
16. Ausblick 185
16.1 Formalisierung von Zeiteigenschaften 185
16.2 Formalisierung von Systemanforderungen 186
16.3 Vorverlagerung der Modellbasierung 189
16.4 Werkzeugunterstützung 190
16.5 Verknüpfung zu einer umfassenden Methodik 191
Teil VI: Anhang
17. Glossar 194
18. Literaturverzeichnis 201
Seite 11
Modellbasierte Formalisierung von Anforderungen
Teil I
Einführung
Seite 12
Modellbasierte Formalisierung von Anforderungen
1. Motivation und Zielsetzung
Da Anforderungen eine zentrale Rolle im Entwicklungsprozess spielen und unterschied- lichste Stakeholder darauf zugreifen müssen, ist es nicht einfach, eine Darstellungsform für Anforderungen zu finden, die allen Stakeholdern gleichermaßen gerecht wird. Insbe- sondere besteht ein Interessenskonflikt zwischen dem Wunsch nach einer möglichst freien Notation (die eine kreative Anforderungserarbeitung fördert), einer möglichst strukturier- ten Darstellung (die eine systematische Anforderungserarbeitung, Vollständigkeit und Konsistenz fördert) und einer möglichst formalen Notation (die eine präzise Anforde- rungsdokumentation und einen leichten Übergang ins Design fördert). Hierfür liegt der Einsatz von Modellen nahe. Ziel dieser Arbeit ist es daher, die verschiedenen Bedürfnisse der Stakeholder in Hinblick auf die Anforderungsdokumentation zu identifizieren, zu bewerten und eine modellhafte Darstellungsform und Methodik zur Dokumentation von Anforderungen zu entwickeln, die den Interessenkonflikt zwischen Formalität, Verständ- lichkeit und Flexibilität so weit wie möglich auflöst.
1.1 Bedeutung der Anforderungen
Bevor damit begonnen werden kann, die Software für ein System zu entwickeln, muss definiert
werden, was das System eigentlich tun soll. Dies wird in der Regel 1 in Form von Anforderungen an das zu entwickelnde System beschrieben. Eine Anforderung (engl. Requirement) ist
„(1) eine Bedingung/Fähigkeit/Eigenschaft, die ein Stakeholder 2 für ein Produkt […] fordert, um ein Problem zu lösen oder ein Ziel zu erreichen; (2) eine Bedingung/Fähigkeit/Eigenschaft, die ein System erfüllen/haben muss, um einen Vertrag, einen Standard, eine Spezifikation oder andere formal vorgegebene Dokumente zu erfüllen; (3) eine dokumentierte Repräsentation ei- ner Bedingung/Fähigkeit/Eigenschaft wie in (1) oder (2) definiert“. [IEEE98, FK+07]
Kurz gesagt, Anforderungen beschreiben, welche Fähigkeiten und welche Eigenschaften ein
System haben soll 3 .
Daher nehmen nahezu alle Teilprozesse im weiteren Entwicklungsprozess die Anforderungen als Ausgangsbasis für ihre Aktivitäten (siehe Abbildung 1).
Die Anforderungen an das zu entwickelnde System sind also ein zentrales Artefakt im Entwicklungsprozess, auf das die unterschiedlichsten Teilprozesse (mit ganz unterschiedlichen Stakeholdern und Zielsetzungen) aufbauen, beispielsweise:
• Design und Implementierung: Aus den Anforderungen wird direkt die Funktionalität des Systems abgeleitet; die Architektur und Implementierung wird maßgeblich durch
1 Bei der Entwicklung von hinreichend kleinen Systemen, in hinreichend kleinen, professionellen und nichtverteilten
Teams wird zuweilen in sogenannten agilen Entwicklungsprozessen (am bekanntesten ist Extreme Programming) auf
Anforderungen weitgehend verzichtet, und stattdessen mit Storyboards und Prototypen gearbeitet. Für die Entwick-
lung sicherheitskritischer Systeme, wie sie in Fahrzeugen verbaut werden, sind solche Prozesse wenig geeignet und
werden daher in dieser Arbeit nicht weiter thematisiert.
2 Als Stakeholder werden Personengruppen bezeichnet, die in irgendeiner Form an der Entwicklung oder Benutzung
des Produkts beteiligt sind, am Beispiel eines Fahrzeugs: Autokäufer (Privatkäufer, Taxiunternehmen, Autovermie-
ter…), Autofahrer (Taxifahrer, Gelegenheitsfahrer, Pendler…), Marketing, Management, Schulungspersonal, TÜV,
Händler, Werkstattpersonal, Anforderungsingenieure, Programmierer, Designer, Tester u.v.m.
3 Eine Zusammenstellung verschiedener Definitionen des Begriffs „Anforderung“ finden sich beispielsweise in
[VH+03] auf den Seiten 2-4.
Seite 13
Modellbasierte Formalisierung von Anforderungen
die in den Anforderungen formulierten Constraints und nichtfunktionalen Eigenschaften beeinflusst. Falsche oder fehlende Anforderungen können die Funktionalität oder Archi- tektur des Systems massiv verschlechtern.
• Test: Die Testfälle werden in der Regel aus den Anforderungen gewonnen. Da das ferti- ge Produkt gegen diese Anforderungen getestet wird, können Fehler in den Anforde- rungen nicht durch Tests aufgedeckt werden.
• Risikomanagement: Das Risikomanagement beruht zu einem Großteil aus der Bewer- tung der Anforderungen. Falsche oder fehlende Anforderungen können zu einer fal- schen Risikoabschätzung führen.
• Projektmanagement: Ein wesentlicher Teil des Projektmanagements basiert auf der A- nalyse der Anforderungen. Falsche oder fehlende Anforderungen können zu Budget- überschreitungen und Verzögerungen im Zeitplan führen.
Abbildung 1: Prozessschnittstellen des Anforderungsmanagements [FB+06]
Somit sind Anforderungen die Grundlage für die gesamte Systementwicklung. Daher haben fehlende oder fehlerhafte Anforderungen dramatische Auswirkungen auf Nutzen und wirtschaft- lichen Erfolg des Produktes, ebenso auf die Entwicklungszeit und -kosten:
• Ein nicht unbeträchtlicher Anteil des von Fahrern als Fehler empfundenen Verhaltens des Fahrzeugs beruht nicht auf Programmierfehlern, sondern auf einer von Anfang an unzureichenden Spezifikation des Verhaltens. Je nach Studie sind 40% bis 60% aller schweren Fehler auf Fehler in der Anforderungsanalyse zurückzuführen.
• Fehler, die im Anforderungsmanagement gemacht werden, sind signifikant schwerer und zeitaufwändiger zu beheben als Fehler, die später im Entwicklungsprozess gemacht werden: je später ein Fehler entdeckt wird, desto teurer wird er. Wird ein Fehler bereits in der Anforderungssphäre entdeckt, ist er – beispielsweise laut Abschätzungen von [Rup02b] – deutlich billiger zu korrigieren als wenn er erst im fertigen Produkt entdeckt wird:
Seite 14
Modellbasierte Formalisierung von Anforderungen
Abbildung 2: Relative Fehlerbehebungskosten [Rup02b]
• In einem Fallbeispiel aus der Automobilindustrie [VH+03], das von der Firma Hood durchgeführt wurde, kommt man zu ähnlichen Abschätzungen für die Aufwände zur Fehlerbehebung:
Abbildung 3: Fehlerbehebungsaufwände an einer Fallstudie aus der Automobilindustrie [VH+03]
• Laut der Chaos-Studie von 1995 [Sta95] sind knapp 44% aller Gründe für das Scheitern von Softwareprojekten unmittelbar auf einen unzureichenden Umgang mit Anforderun- gen zurückzuführen. Der häufigste Einzelgrund für das Scheitern liegt dabei mit 13,1% in unvollständigen Anforderungen (siehe Abbildung 4).
Abbildung 4: Die wichtigsten 10 Einflussfaktoren, die den Projekterfolg gefährden [Sta95, IA02]
Seite 15
Modellbasierte Formalisierung von Anforderungen
• Und auch an den Wartungskosten haben Änderungen in den Anforderungen den größ- ten Anteil:
Abbildung 5: Quellen für Wartungskosten (in %), nach der Standish Group [VH+03]
Je komplexer ein System ist, je mehr Menschen an der Entwicklung des Systems beteiligt sind, je sicherheitskritischer ein System und je komplexer die Systemumgebung (die Art und Anzahl der Nachbarsysteme, mit denen das zu entwickelnde System kooperieren muss) ist, desto wich- tiger wird es, die Anforderungen möglichst präzise, vollständig und korrekt zu beschreiben. Um dies zu gewährleisten müssen Methoden eingesetzt werden, um systematisch Anforderungen hoher Qualität zu erarbeiten (konstruktive Qualitätssicherung), und die Qualität der erarbeiteten Anforderungen, also insbesondere ihre Korrektheit, Konsistenz und Vollständigkeit, zu evaluie- ren (analytische Qualitätssicherung), bevor die Anforderungen den anderen Teilprozessen zur Verfügung gestellt werden. Innerhalb des Entwicklungsprozesses ist für das Erarbeiten, Doku- mentieren, Validieren, Verwalten und Qualitätssichern der Anforderungen das Anforderungs- management zuständig.
Das Anforderungsmanagement hat in den letzten Jahren nicht zuletzt im Automobilbereich er- heblich an Bedeutung gewonnen [VH+03]: Da die in Fahrzeugen verwendeten Steuergeräte Teil einer immer komplexer werdenden Systemlandschaft sind und da diese Steuergeräte zum Teil extrem sicherheitskritisch sind [Rib03], wird in der Automobilindustrie immer größerer Wert auf die Erarbeitung qualitativ hochwertiger Anforderungen gelegt. Bei der Entwicklung sicher- heitskritischer Systeme wird heute zudem die Erfüllung von Standards, Gesetzen und Normen gefordert, wie beispielsweise SPICE [SP07a, SP07b] und CMMI [CMMI], die beide ein syste- matisches Anforderungsmanagement verlangen.
Je mehr Aufwand aber in die Erarbeitung und Qualitätssicherung von Anforderungen investiert wird, desto mehr wächst auch das Bedürfnis, diese Investition optimal auszuwerten:
• Dies wird zum einen durch eine systematische Wiederverwendung bereits qualitätsgesi- cherter Anforderungen in späteren Projekten (bis hin zur Entwicklung und Pflege von Produktlinien [PB+05]) angestrebt.
Seite 16
Modellbasierte Formalisierung von Anforderungen
• Ebenso wird eine hohe Durchgängigkeit zu Nachbarprozessen angestrebt, vor allem ei- ne möglichst nahtlose Übernahme der Anforderungen ins Design (sodass die Überset- zung von Anforderungen in Designelemente mit möglichst wenig Aufwand verbunden und nicht fehleranfällig ist) oder auch ins Testmanagement (sodass aus Anforderungen möglichst leicht und soweit wie möglich automatisch Testfälle generiert werden kön- nen).
Entsprechend der großen Bedeutung der Anforderungen für den Verlauf des Entwicklungspro- zesses und für das zu entwickelnde Produkt wird ein effektives Anforderungsmanagement im- mer wichtiger. Daher beschäftigen sich sowohl in der Forschung als auch in der Praxis Wissen- schaftler und Praktiker damit, das Anforderungsmanagement zu verbessern.
Das Anforderungsmanagement kann dabei in verschiedene Aufgaben zerlegt werden 4 : Die An- forderungserarbeitung (Elicitation) beispielsweise beschäftigt sich damit, woher die Anforde- rungen an ein System kommen (zum Beispiel welche Stakeholder einbezogen werden müssen, oder welche weitere Quellen ausgewertet werden können) und wie die Anforderungen am bes- ten erarbeitet werden können (zum Beispiel durch Einzelinterviews, Marktstudien, Workshops, Fallstudien). Die Qualitätssicherung beschäftigt sich beispielsweise damit, welche Qualitätskri- terien im Anforderungsmanagement relevant sind (zum Beispiel Konsistenz, Vollständigkeit, Korrektheit), wie diese Qualitätseigenschaften konstruktiv sichergestellt werden und analytisch
überprüft werden können. 5 Bei diesen Aufgaben im Anforderungsmanagement spielt die Art und Weise, wie Anforderungen repräsentiert werden, eine große Rolle. Eine sehr wichtige Auf- gabe des Anforderungsmanagements ist es daher, Methoden und Datenstrukturen zur Dokumen- tation der Anforderungen zu entwickeln, die den wachsenden Ansprüchen gerecht werden – Ansprüche, die sowohl aus dem Anforderungsmanagement selbst (zum Beispiel Elicitation, oder Qualitätssicherung) als auch aus den benachbarten Prozessen (zum Beispiel Testfallgene- rierung, Übergang von den dokumentierten Anforderungen zum Design) kommen.
Und genau hier, bei der Dokumentation der Anforderungen, setzt die vorliegende Arbeit an. Daher werden im folgenden Abschnitt 1.2 die Herausforderungen für die Anforderungsdoku- mentation detaillierter beschrieben.
1.2 Herausforderungen für die Dokumentation von Anforderungen
Da die Spezifikation ein zentrales Artefakt im Entwicklungsprozess ist, auf das viele unter- schiedliche Stakeholder zugreifen müssen, ist die Wahl einer geeigneten Dokumentationsform ein ebenso schwieriges wie wichtiges Unterfangen. Um dieses zu bewältigen muss zunächst betrachtet werden, welche Stakeholder auf die Spezifikation zugreifen müssen und welche An- forderungen sich daraus an die Dokumentation ergeben.
Zwar sind sehr unterschiedliche Personengruppen an der Erstellung und Nutzung der Anforde- rungen beteiligt (beispielsweise können neben Ingenieuren und Entwicklern in der Regel auch zukünftige Kunden und Nutzer, Marketingabteilungen, Schulungspersonal, Werkstattpersonal, Rechtsanwälte und Hotlinemitarbeiter miteinbezogen werden), die sich in ihrem fachlichen
4 Hier nur einführend und exemplarisch, eine vollständigere Auflistung findet sich im Grundlagenkapitel 2.1.
5 Weitere wichtige Aufgaben in diesem Zusammenhang, die aber nicht Thema dieser Arbeit sind, sind beispielsweise
die Erarbeitung von Anforderungen, insbesondere in einem interdisziplinärem Kontext (siehe dazu die Arbeiten von
Eva Geisberger) oder die systematische Wiederverwendung bereits qualitätsgesicherter Anforderungen aus Vorgän-
gerprodukten, bis hin zu Produktlinienansätzen (siehe dazu die Arbeiten von Anna Ioschpe).
Seite 17
Modellbasierte Formalisierung von Anforderungen
Hintergrund, in ihrer Sprache, ihren Zielen und Wertungen zum Teil erheblich unterscheiden. Vereinfachend kann man sich dabei auf drei exemplarische Stakeholdergruppen beschränken, die repräsentativ für die anderen Stakeholder stehen:
• Der Anforderungserfasser (Schlagwort: Ersteller), dessen Hauptaufgabe darin liegt, im Dialog mit Marketing, Kunden, Nutzern und vielen anderen die Anforderungen zu erar- beiten und die Spezifikation zu validieren. Hierzu wird eine flexible Dokumentations- form benötigt, die einerseits Freiraum für kreatives und verteiltes Arbeiten lässt, die an- dererseits strukturierend unterstützt. Anforderungen werden meistens informell und na- türlichsprachig formuliert, weil dies die einzige Sprache ist, die alle beteiligten Stake- holder gleichermaßen souverän verstehen und benutzen können. Als Werkzeuge für die kreative Erarbeitung von innovativen Anforderungen werden oft Zettel und Stift, Word oder Powerpoint, Mindmaps [Buz97], sowie vereinzelt auch spezielle kollaborative Tools wie beispielsweise EASYWINWIN [EA07, Grü01, Grü02] benutzt. Für die syste- matische Erarbeitung einer möglichst vollständigen Spezifikation werden oft Musterdo- kumente (mit vorgegebenem Inhaltsverzeichnis), Checklisten, Use-Cases oder Story- cards verwendet. Die Anforderungen können im Rahmen des weiteren Dokumentati- onsprozesses verbessert werden, müssen aber auch danach noch von den Stakeholdern verstanden werden, da sonst keine Validierung der Spezifikation möglich ist. Der An- forderungsingenieur in der frühen Phase steht damit stellvertretend für alle eher infor- mell ausgerichteten Anforderungsbearbeiter. Seine Anforderungen an die Dokumentati- on der Spezifikation lassen sich unter den Schlagworten „Verständlichkeit“, „Flexibili- tät“ und „Systematik“ zusammenfassen.
• Der Anforderungsbearbeiter (Schlagwort: Verwalter), dessen Hauptaufgabe darin liegt, die Anforderungen zu konsolidieren und zu verwalten und die Spezifikation den ande- ren Prozessbeteiligten in einer geeigneten Form zur Verfügung zu stellen. Hier ist eine Dokumentationsform nötig, die bei der Analyse der Qualität der Anforderungen (insbe- sondere Vollständigkeit und Konsistenz) unterstützt. In der Praxis werden Anforderun- gen bislang meist nicht formal notiert; in der Forschung schlagen die meisten Ansätze entweder eine textuelle Darstellung mit logischen Formeln o.ä. (vgl. [HR+06, HR07]) oder graphische Ansätze mit Message Sequence Charts, Automaten o.ä. (vgl. [AF07]) vor, abhängig von der Zielsprache des Designs. Der Anforderungsingenieur in der spä- ten Phase steht damit stellvertretend für die eher formal ausgerichteten Anforderungs- bearbeiter und seine Anforderungen an die Dokumentation der Spezifikation lassen sich folglich unter dem Schlagwort „Formalisierung“ zusammenfassen.
• Der Entwicklungsingenieur (Schlagwort: Nutzer), dessen Hauptaufgabe darin liegt, die Spezifikation als Grundlage für die weiteren Arbeiten (Testfalldefinitionen, Architektu- ren, Code) zu verwenden. Hier ist eine Dokumentationsform der Anforderungen nötig, die sich möglichst nahtlos in die Sprachelemente des Designs (als Schnittstelle zu den anderen Entwicklungsartefakten) übertragen lässt. Der Designer steht damit stellvertre- tend für die Personengruppen, die die Spezifikation als Informationsquelle nutzen und sie in ihre eigene Fachsprache übersetzen, ohne die Spezifikation dabei zu verändern. Je klarer diese Übersetzung ist, umso weniger Aufwand und Fehlerpotential ist damit ver- bunden. Diese Anforderungen an die Dokumentation der Spezifikation lassen sich unter dem Schlagwort „Durchgängigkeit“ zusammenfassen. Da in der Automobilindustrie
Seite 18
Modellbasierte Formalisierung von Anforderungen
angestrebt wird, das Design modellbasiert zu entwickeln, bedeutet Durchgängigkeit also Anbindung an ein modellbasiertes Design.
Diese verschiedenen Anforderungen an die Dokumentationsform einer Spezifikation sind zum Teil widersprüchlich. Ein Ansatz zur Dokumentation von Anforderungen muss aber unbedingt allen diesen zum Teil widersprüchlichen Aspekten Verständlichkeit, Formalisierung und Durchgängigkeit Rechnung tragen. Bislang gibt es keinen Ansatz zur Dokumentation von An-
forderungen, der alle drei Aspekte berücksichtigt 6 : Entweder werden die Anforderungen über- haupt nicht formalisiert, was zu erheblichen Schwierigkeiten bei der Qualitätssicherung der Anforderungen führt. Oder es werden die Anforderungen formalisiert, ohne dabei die Notwen- digkeit der Transparenz und Verständlichkeit zu berücksichtigen, was zu schwer verständlichen, nicht handhabbaren und insbesondere nicht validierbaren Anforderungen führt. Oder aber es werden Anforderungen formalisiert, ohne sie dabei an das Design anzunähern, sodass keine Durchgängigkeit zum Design erreicht wird.
In der heutigen Praxis werden Anforderungen überwiegend nicht formalisiert, sondern informell aufgeschrieben (z.B. siehe [VH+03]). Im besten Fall werden die Anforderungen standardisiert erfasst, beispielsweise als VOLERE Templates [VO07], in Excel-Tabellen oder mit verschiede- nen Anforderungswerkzeugen wie DOORS oder REQUISITEPRO oder CALIBERRM [DO07, CA07, RQ07]. Die beiden Screenshots in Abbildung 6 und Abbildung 7 zeigen, wie Anforde- rungen in der Praxis mit Toolunterstützung bestenfalls erfasst werden.
Abbildung 6: Anforderungsverwaltung am Beispiel von CALIBERRM
6 Siehe die Diskussion ähnlicher Arbeiten im Kapitel 14.
Seite 19
Modellbasierte Formalisierung von Anforderungen
Abbildung 7: Anforderungsverwaltung am Beispiel von DOORS
Beiden Erfassungsformen ist gemeinsam, dass die wesentlichen Anforderungsbeschreibungen informell und natürlichsprachig formuliert sind (Abbildung 6: „The applicant submits a lo- an…“, Abbildung 7: „Users shall be able…“). Immerhin werden die Anforderungen zunehmend mit Attributen versehen, deren Wertebereich oft präzise definiert ist. Durch die Standardisierung und Formalisierung der Verwaltungsstrukturen einzelner Anforderungen ist hier bereits der erste Schritt in Richtung Formalisierung getan. Aber gerade der wesentliche Kern der Anforderung, nämlich ihr Inhalt, ist nicht formalisiert. Die in dieser Arbeit vorgestellte Formalisierungsme-
thodik geht einen Schritt weiter, indem sie auch die Anforderungsbeschreibungen 7 formalisiert – ohne dabei die anderen oben beschriebenen Kriterien wie Verständlichkeit, Transparenz oder Pragmatismus aus den Augen zu verlieren.
Zusammenfassend stehen in dieser Arbeit die folgenden Herausforderungen im Fokus, die bei der Entwicklung einer geeigneten Dokumentationsform berücksichtigt werden müssen:
• Heterogenität der Ansprüche an die Anforderungsdokumentation. Wie oben eingehend erläutert, muss die Dokumentation o verständlich und flexibel sein, sodass informell denkende Menschen wie bei- spielsweise Marketing oder Werkstattpersonal ihre Anforderungen effektiv ein- bringen und validieren können.
o formal und präzise sein, sodass eine hohe Qualität erzielt und die Analyse und Qualitätssicherung (bezüglich Konsistenz, Korrektheit und Vollständigkeit) er- leichtert wird.
7 Sie spielt sich also gewissermaßen innerhalb der Spalte „User Requirements“ (DOORS, Abbildung 7) oder des Fel-
des „Description“ (CALIBERRM, Abbildung 6) ab.
Seite 20
Modellbasierte Formalisierung von Anforderungen
o
zum Design durchgängig sein, sodass die dokumentierten und qualitätsgesicher- ten Anforderungen ohne großen Aufwand und ohne große Fehlermöglichkeiten direkt in ein modellbasiertes Design übertragen werden können.
• Heterogenität der Anforderungen. Die Menge an Anforderungen ist sehr heterogen, zum einen bezüglich ihrer Form (Stichpunkte, Skizzen, freier Text, Use-Cases, Kopien aus Gesetzestexten und Normen, Prototypen, Screenshots, Tabellen, Mindmaps), zum anderen bezüglich ihres Inhaltes (so finden sich beispielsweise sehr abstrakte Anforde- rungen wie „Freude am Fahren“ und sehr konkrete Anforderungen wie „Das Steuerge- rät darf nicht mehr als 256KB Speicher benötigen“). Dies liegt natürlich zum Teil be- gründet in der Heterogenität der Stakeholder, die die Anforderungen einbringen.
• Menge von Anforderungen. Bei hinreichend komplexen Systemen, wie sie in Fahrzeu- gen anzutreffen sind, ist die Menge der Anforderungen allein schon aufgrund ihrer Grö- ße (beispielsweise besteht eine typische Spezifikation im Automotive-Bereich aus mehr als 10.000 Anforderungen) schwer auf Vollständigkeit, Korrektheit und Konsistenz zu prüfen.
• Notwendigkeit von Strukturen. Unabhängig von der Wahl der Form der Anforderungs- beschreibung (informell oder formal, Text oder Grafik) muss bei der Dokumentations- form auch berücksichtigt werden, dass das Design höhere Ansprüche an die Konsistenz und vor allem an die Vollständigkeit der Anforderungen stellt. Zwar gilt bereits im An- forderungsmanagement das Qualitätskriterium der Vollständigkeit, allerdings werden im Anforderungsmanagement in der Regel nicht systematisch alle impliziten Annahmen (Vorbedingungen einer Anforderung) explizit gemacht (dies geschieht bislang in der Regel erst im Design). Soll eine wirklich Durchgängigkeit zum Design erreicht werden, so muss diese Explizitmachung ins Anforderungsmanagement vorverlagert werden; da- durch können unter Umständen dramatisch mehr Anforderungen anfallen (siehe aus- führliche Diskussion im Kapitel 9). Damit diese überhaupt systematisch erarbeitet wer- den und damit effektiv gehandhabt werden können, ist es notwendig, die Anforderun- gen entsprechend zu strukturieren. Da durch die Formalisierung besonders die Precon- ditions einer Anforderung wachsen, muss eine Strukturierung anhand dieser Vorbedin- gungen hinzukommen, um die Anforderungsmenge sinnvoll partitionieren zu können. Das Ziel dieser Arbeit ist es daher, eine Dokumentationsform für Anforderungen zu entwickeln und entsprechende Aktivitäten zu definieren, die diesen Herausforderungen gerecht werden. Diese Zielsetzung wird im nächsten Abschnitt näher erläutert.
1.3 Zielsetzung und Nutzen der Arbeit
Ziel dieser Arbeit ist die Entwicklung einer fundierten und geeigneten Darstellungsform und einer begleitenden Methodik zur Formalisierung von Anforderungen. Ausgehend von einer definierten Ausgangssituation, den informellen Anforderungen, sollen die Anforderungen durch geeignete Datenstrukturen und Methoden schrittweise
• präziser und einheitlicher formuliert werden. Dafür sollen zum einen die Elemente der Anforderungen (sozusagen der „Wortschatz“) in einem Katalog definiert werden. Zum anderen sollen diese Elemente innerhalb der Anforderungen gemäß definierter Anforde- rungsmuster (sozusagen der „Satzbau“) angeordnet werden: Formulierung.
Seite 21
Modellbasierte Formalisierung von Anforderungen
• strukturiert und vervollständig werden. Dies soll zum einen innerhalb einzelner Anfor- derungen geschehen (durch Anforderungsmuster werden die Elemente der Anforderun- gen strukturiert und gegebenenfalls gemäß den in dem Muster vorgesehenen Platzhal- tern vervollständigt). Zum anderen soll auch die Menge der Anforderungen strukturiert und fehlende Anforderungen identifiziert werden: Strukturierung.
• an die Datenstrukturen des Designs angenähert werden. Die Durchgängigkeit zum De- sign wird erreicht durch den Bezug auf ein Modell eingebetteter Systeme, das sowohl dem Anforderungsmanagement als auch dem Design zugrunde liegt, aber in unter- schiedlichen, jeweils für die Aufgabe angemessenen Detailtiefen und Formalisierungs- graden verwendet wird: Modellbasierung.
Die Anforderungen sollen durch die Formalisierung schrittweise so weit an die Zielsprache des Designs angenähert werden, dass der Übergang zum Design einfach, nachvollziehbar und feh- lertolerant durchgeführt werden kann. Die Anforderungen sollen trotz systematischer Erhöhung der Qualität und Formalität bis zur Übergabe an das Design natürlichsprachig und damit für die informell denkenden Stakeholder verständlich und transparent bleiben (sodass beispielsweise eine Validierung der formalisierten Anforderungen weiterhin möglich ist). Mit Hilfe geeigneter Strukturen soll durch Explizitmachung verborgener Vorbedingungen die Konsistenz und Voll- ständigkeit der Anforderungen so weit erhöht werden, dass ein sinnvoller Übergang zum Design möglich ist. Die Formalisierungsschritte sind:
• Klassifikation der Anforderungen (siehe Kapitel 7), in der die Anforderungsmenge in Klassen unterteilt wird (für jede Klasse ist ein Satz von erlaubten Anforderungsbestand- teilen definiert).
• Formulierung der Anforderung (siehe Kapitel 8), in der die Anforderungsbestandteile identifiziert, extrahiert, katalogisiert und vereinheitlicht, und die Anforderungen gemäß der Formulierungsregeln der jeweiligen Klasse umformuliert werden.
• Strukturierung der Anforderung (siehe Kapitel 9), in der die Anforderungsmenge durch Dienste strukturiert und vervollständigt wird.
• Übergabe an das Design (siehe Kapitel 10), in der aus den Anforderungen korrespon- dierende Elemente im Design erzeugt werden.
Die Datenstruktur und die Methodik werden für eine Klasse von Anforderungen, nämlich die funktionalen Nutzeranforderungen, komplett ausgearbeitet und anhand von Fallstudien aus der Automotive-Domäne verdeutlicht. Die Formalisierung der anderen Anforderungstypen wird im Ausblick skizziert und diskutiert. Schließlich wird dargestellt, wie sich die für die Dokumenta- tion von Anforderungen hier erarbeiteten Datenstrukturen und Aktivitäten der Formalisie- rungsmethodik in ein umfassendes Referenzmodell des Requirements Engineering (hier reprä- sentiert durch REM [GB+06]) einordnen lassen. Der detaillierte Aufbau der Arbeit wird im letzten Abschnitt dieses Kapitels erläutert.
Der Nutzen dieser Arbeit lässt sich teilen in einen praktischen Nutzen, der den Anwendern, die die hier entwickelte Methodik in der Praxis einsetzen, zugute kommt, und in einen wissenschaft- lichen Beitrag für die Forschungsgemeinde im Requirements Engineering:
Seite 22
Modellbasierte Formalisierung von Anforderungen
• Der praktische Nutzen dieser Arbeit liegt zum einen darin, dass Anforderung, die in der beschriebenen Darstellungsform formuliert wurden, eine höhere Qualität haben als rein informelle Anforderungen, da das der Umformulierung zugrundeliegende Modell be- stimmte Eigenschaften der Anforderungen (insbesondere Konsistenz, Vollständigkeit, Übersichtlichkeit, Verständlichkeit, Präzision) steigert und die entsprechenden kon- struktiven und analytischen qualitätssichernden Maßnahmen gezielt unterstützt; dies wird im Laufe dieser Arbeit durch die begleitenden Fallstudien immer wieder demonst- riert. Der zweite praktische Nutzen dieser Arbeit liegt darin, dass den Anforderungsin- genieuren eine systematische, pragmatische und leicht erlernbare Methode zur Formali- sierung an die Hand gegeben wird, die aus einfach durchführbaren Einzelschritten be- steht und die sich an den Bedürfnissen der beteiligten Stakeholder orientiert.
• Der wissenschaftliche Wert dieser Arbeit liegt darin, dass hier erstmals die systemati- sche Auflösung des Interessenskonflikts der verschiedenen Stakeholder bei der Anfor- derungsdokumentation konsequent in den Mittelpunkt der Entwicklung einer neuen Darstellungsform für Anforderungen gestellt wurde (und nicht nur eine Stakeholder- gruppe berücksichtigt wurde). Dieser Interessenskonflikt besteht zwischen dem Wunsch nach einer möglichst freien Notation (die eine kreative Anforderungserarbeitung för- dert), einer möglichst strukturierten Darstellung (die eine systematische Anforderungs- erarbeitung, Vollständigkeit und Konsistenz fördert) und einer möglichst formalen No- tation (die eine präzise Anforderungsdokumentation und einen leichten Übergang ins Design fördert). Wie im Kapitel 14 (Vergleich ähnlicher Arbeiten) erläutert wird, be- rücksichtigen die meisten bislang existierenden Ansätze nur einen Teil dieser Wünsche. Im hier nun vorliegenden Ansatz wurden die unterschiedlichen Anforderungen der Sta- keholder explizit in die Entwicklung der Anforderungsdokumentation miteinbezogen und der Widerspruch zwischen Formalität und Informalität weitgehend aufgelöst, indem einerseits modellbasierte Konzepte als formale Grundlage der Anforderungsdokumenta- tion entwickelt wurden (die eine präzise und zu den Designmodellen durchgängige An- forderungsdokumentation ermöglichen), andererseits aber angemessene informelle Dar- stellungsformen für diese Konzepte entwickelt wurden (die eine verständliche, gut strukturierte und validierbare Anforderungsdokumentation ermöglichen). Dadurch kann die Lücke zwischen informellen Anforderungen und formalen Designmodellen (im Re- quirements Engineering ein wichtiges Problemfeld) verkleinert und vorverlagert wer- den: Durch den nahtlosen Übergang zum Design ist die Lücke nun nicht mehr zwischen Anforderungen und Design, sondern liegt innerhalb des Anforderungsmanagements, in- nerhalb des Prozesses der schrittweisen Formalisierung, wie er in der vorliegenden Ar- beit entwickelt wurde.
Da die hier entwickelte Formalisierungsmethodik direkt an die Bedürfnissen der Stakeholder an die Anforderungsdokumentation anknüpft, da die Methodik in kleine, gut begründete und leicht nachvollziehbare Schritte unterteilt ist, und da bei der Definition sowohl der Darstellungsform als auch der Formalisierungsschritte explizit die Verständlichkeit als eines der wesentlichen Qualitätskriterien für Darstellungsform und Methodik einbezogen wurde, kann die Methodik leicht gelehrt und erlernt werden; dies wird im Teil III dieser Arbeit durch die begleitende Fall- studie demonstriert.
Seite 23
Modellbasierte Formalisierung von Anforderungen
1.4 Aufbau der Arbeit
Diese Arbeit ist in sechs Teile gegliedert, die inhaltlich wie folgt aufgebaut sind:
• Teil I: Einführung Im ersten Teil der Arbeit wird die Aufgabenstellung und Zielsetzung der Arbeit vorge- stellt und begründet. Es wird in die Grundlagen dieser Arbeit eingeführt (Requirements Engineering, Formalisierung und Modellierung, Eingebettete Systeme) und es werden die wissenschaftliche Vorgehensweise und die verwendeten Fallstudien vorgestellt. Die Zielsetzung und die Fallstudie dienen gemeinsam als roter Faden für den weiteren Ver- lauf der Arbeit, indem anhand der Fallstudie das Erreichen der Ziele, insbesondere die Anwendbarkeit und der Nutzen der Formalisierungsmethodik demonstriert werden.
1. Einführung
2. Grundlagen
3. Wissenschaftliche Vorgehensweise und Fallstudie
• Teil II: Formalisierungskonzept Im zweiten Teil der Arbeit wird zunächst begründet, warum sich die Arbeit auf einen Typ von Anforderungen, nämlich die funktionalen Nutzeranforderungen konzentriert. Danach wird das dieser Klasse von Anforderungen zugrunde liegende Denkmodell ana- lysiert und formal definiert. Auf diesem Modell aufbauend wird eine geeignete Darstel- lungsform für die formalisierten Anforderungen entworfen.
4. Auswahl der zu formalisierenden Anforderungen
5. Formale Definition des zugrundeliegenden Modells
6. Definition einer geeigneten Darstellungsform
• Teil III: Formalisierungsmethodik Im dritten Teil der Arbeit werden die Formalisierungsschritte vorgestellt, die informelle Anforderungen in die semiformale Darstellungsform überführen, und anhand der Fall- studie wird die Anwendbarkeit und der Nutzen der Formalisierungsmethodik demonst- riert. Zunächst werden im Schritt Klassifikation Anforderungen klassifiziert, um zu ent- scheiden, ob und wie und wie weit sie formalisiert werden. Im Anschluss daran werden im Schritt Formulierung die Anforderungen in ihre elementaren Bestandteile zerlegt, diese einzeln umformuliert und dann gemäß definierter Anforderungsmuster zu standar- disiert formulierten und strukturierten Anforderungen zusammengefügt. Im nächsten Schritt, der Strukturierung, werden Anforderungen so organisiert, dass die Konsistenz und Vollständigkeit systematisch erhöht wird, sodass im letzten Schritt, der Übergabe, ein nahtloser Übergang vom Anforderungsmanagement zum Design möglich ist.
7. Klassifikation
8. Formalisierung
9. Strukturierung
10. Übergabe ans Design
• Teil IV: Einbettung in den Entwicklungsprozess Im vierten Teil der Arbeit wird beschrieben, wie die vorgestellte Formalisierungsme- thodik in den Entwicklungsprozess eingeordnet werden kann, indem das Datenmodell, das Aktivitätenmodell und das Reifegradmodell der Formalisierungsmethodik in ein umfassendes Referenzmodell für Requirements Engineering eingepasst werden.
Seite 24
Modellbasierte Formalisierung von Anforderungen
11. Datenmodell
12. Aktivitätenmodell
13. Reifegradmodell
• Teil V: Bewertung und Ausblick Im fünften Teil der Arbeit werden ähnliche Arbeiten und Ansätze vorgestellt und disku- tiert, und es wird dargestellt, worin der Mehrwert der vorliegenden Arbeit besteht. Die Arbeit wird noch einmal zusammengefasst und im Ausblick wird die weitere Perspekti- ve dieser Arbeit skizziert: Ausarbeiten der Formalisierung für weitere Anforderungsty- pen, Vorverlagerung der modellbasierten Formalisierung zu einer modellbasierten Er- hebung von Anforderungen und Werkzeugunterstützung für den vorgestellten Ansatz.
14. Diskussion ähnlicher Arbeiten
15. Zusammenfassung
16. Ausblick
• Teil VI: Anhang Im sechsten Teil der Arbeit schließlich werden die wichtigsten Fachbegriffe erläutert und die verwendete und zitierte Literatur aufgelistet.
17. Glossar
18. Literaturverzeichnis
Jedes Kapitel beginnt mit einem kurzen fett gedruckten Text, der die wichtigsten Inhalte des Kapitels zusammenfasst. Der eilige Leser kann von Kapitel zu Kapitel weiterblättern und ein- fach nur den fett gedruckten Einleitungstext lesen, um schnell einen Überblick über die gesamte Arbeit zu gewinnen. Die Kapitel im Teil III, Formalisierungsmethodik, enthalten darüber hinaus jeweils am Ende noch einmal eine Zusammenfassung in Form eines einseitigen Steckbriefes des jeweiligen Formalisierungsschrittes.
Seite 25
Modellbasierte Formalisierung von Anforderungen
2. Grundlagen
Die in dieser Arbeit vorgestellte Formalisierungsmethodik fällt ins Aufgabengebiet des Requirements Engineering, das der Teil des Software- und Systementwicklungsprozesses ist, in dem die Anforderungen an das zu entwickelnde System erfasst, dokumentiert und analysiert werden. Die Philosophie, die der Methodik zugrunde liegt, ist die der modellba- sierten Entwicklung: die Methodik hat den Anspruch, Anforderungen modellbasiert zu formalisieren und einen einfachen Übergang zu einem modellbasierten Design herzustel- len. Die Klasse von Systemen, für die die Methodik exemplarisch ausgearbeitet wurde, ist die der eingebetteten Systeme in Fahrzeugen.
2.1 Requirements Engineering
Requirements Engineering ist der Teil des Software- und Systementwicklungsprozesses, der sich mit der Erarbeitung, Analyse und Dokumentation der Anforderungen an ein zu entwickeln- des System beschäftigt. Requirements Engineering ist Teil des Requirements Managements (Anforderungsmanagement), das zusätzlich noch ein Änderungsmanagement für Anforderungen und ein Umsetzungsmanagement beinhaltet. Eine Übersicht über weitere Definitionen von Re- quirements Engineering findet sich beispielsweise in [Poh96] und [Par98]. Innerhalb des Entwicklungsprozesses ist der Anforderungsmanagementprozess für die Erarbei- tung, Analyse, Dokumentation, Qualitätssicherung und Bereitstellung der Anforderungen ver- antwortlich [VH+03]. Ziel des Anforderungsmanagementprozesses ist es, mit möglichst gerin- gem Zeit-, Kosten- und Denkaufwand eine Spezifikation hoher Qualität zu erstellen.
Es gibt dabei eine Reihe von Faktoren, die die Qualität einer Anforderung und der Spezifikation bestimmen, beispielsweise:
• Korrektheit (in Sinne, dass die Anforderung den tatsächlichen Bedürfnissen der Stake- holder entsprechen sollen 8 ),
• Konsistenz (die Anforderungen sollen sich nicht widersprechen),
• Vollständigkeit (es sollen alle relevanten Aspekte des zu entwickelnden Systems be- schrieben werden),
• Änderbarkeit (es soll leicht möglich sein, einzelne Anforderungen zu finden und zu än- dern; die Auswirkungen solcher Änderungen, der sogenannte Change Impact, sollen leicht identifiziert werden können),
• Nachvollziehbarkeit (für jede Anforderung soll es möglich sein, ihren Ursprung und ih- re Begründung nachzuvollziehen; oft wird dies mit Attributen wie „Autor“ oder „Quel- le“ realisiert, oder durch Ableitungsketten, die jede Anforderung zurückführen auf ein Geschäftsziel),
• Eindeutigkeit (Anforderungen sollen so präzise formuliert sein, dass sich nicht missver- standen werden können),
• Umsetzbarkeit (eine Anforderung muss sich tatsächlich umsetzen lassen können),
8 Korrektheit wird auch in einem zweiten Sinne verwendet, nämlich dass das entwickelte Produkt seiner in den An-
forderungen dokumentierten Spezifikation entspricht (das Maß für diese Form der Korrektheit ist der Grad der Über-
einstimmung des Produktes mit seiner Spezifikation).
Seite 26
Modellbasierte Formalisierung von Anforderungen
• Testbarkeit (es muss am Ende des Projektes für jede Anforderung überprüfbar sein, ob
sie korrekt umgesetzt wurde; oft werden dazu für jede Anforderung Akzeptanzkriterien
definiert) und
• Wiederverwendbarkeit (eine Anforderung soll leicht in späteren ähnlichen Projekten
wiederverwendet werden können).
Weitere Qualitätskriterien für Anforderungen finden sich beispielsweise bei [Rup02b]. In der Theorie (beispielsweise [SS97, Som01]) werden im Requirements Engineering die fol-
genden Aufgabenfelder unterschieden (in der Praxis ist eine klare Trennung zwischen diesen
verschiedenen Aufgaben nicht immer möglich und sinnvoll):
• Erhebung (Elicitation): Die Stakeholder des Systems werden identifiziert und die An-
forderungen an das zu entwickelnde Produkt werden im Dialog mit den verschiedenen
Stakeholdern erhoben. Dies wird beispielsweise durch Fragebögen, Marketing-Studien,
Interviews und Workshops mit potentiellen Nutzern, Analyse von Konkurrenzproduk-
ten, Einbeziehung von Gesetzestexten und Normen oder Prototyping erreicht (siehe bei-
spielsweise in den Kapiteln 4 und 5.2 in [Rup02b] oder im Kapitel 2.6 in [VH+03] oder
in den Kapiteln 2 bis 4 in [AS02]).
• Entscheidung (Negotiation): Anforderungen werden aus vielen Quellen und von vielen
verschiedenen Stakeholdern eingebracht. Aus dieser großen und widersprüchlichen
Menge, die die unterschiedlichen Wünsche der Stakeholder widerspiegelt, müssen
durch einen systematischen Entscheidungsprozess die relevanten Anforderungen her-
ausgesucht und priorisiert werden.
• Dokumentation (inkl. Strukturierung): Die Anforderungen müssen in einer geeigneten
Form schriftlich dokumentiert werden. Anforderungen müssen präzise notiert werden,
dabei aber für alle beteiligten Stakeholder verständlich bleiben, auch bei großen Anfor-
derungsmengen darf die Übersicht nicht verloren gehen (Strukturierung, Modularisie-
rung), auch relevante Beziehungen zwischen Anforderungen müssen dokumentiert wer-
den (horizontales Tracing). In der Praxis werden Anforderungen zumeist als strukturier-
te Texte dokumentiert, oft werden sie mit einer Vielzahl von Attributen versehen (zum
Beispiel Erstellungsdatum, Autor, Priorität).
• Analyse (inkl. Validierung): Die dokumentierten Anforderungen müssen validiert wer-
den (ob sie den tatsächlichen Wünschen und Bedürfnissen der Stakeholder entspre-
chen), und es muss analysiert werden, ob sie den vorher definierten Qualitätskriterien
genügen, insbesondere ob sie vollständig und konsistent (widerspruchsfrei) sind. Dies
wird zu einem kleinen Teil automatisch überprüft (beispielsweise, ob alle relevanten
Attribute mit Werten belegt sind), zum Großteil aber durch Reviews der ausgedruckten
Dokumente und einen Abnahmeprozess (beispielsweise mit Quality Gates 9 ) sicherge- stellt.
• Verwaltung (inkl. Tracing): Zur Verwaltung der Anforderungen gehört zum einen das
Änderungsmanagement; hier werden Auswirkungen von Änderungen abgeschätzt und
Änderungen durchgeführt, dokumentiert und gegebenenfalls wieder rückgängig ge-
9 Siehe beispielsweise die Quality Gates im Requirements Engineering Reference Model [GB+06], dargestellt u.a. im
Kapitel 13.
Seite 27
Modellbasierte Formalisierung von Anforderungen
macht. Zum anderen fällt auch das Umsetzungsmanagement in diesen Aufgabenbereich; hier wird (zum Beispiel durch
vertikales Tracing)
verfolgt, wie und wie weit die jewei- ligen Anforderungen in Design und Implementierung umgesetzt wurden.
Einen Überblick über aktuelle Forschungsaktivitäten in diesen Aufgabenfeldern des Require- ments Engineering finden sich in [Zav97], [NE00] und [Lam00]. Die in dieser Arbeit vorgestell- te Formalisierungsmethodik fällt, wie bereits im Kapitel 1 beschrieben, in das Aufgabenfeld der Dokumentation; eine Übersicht über verwandte Arbeiten in diesem Bereich findet sich im Kapi- tel 14. Im Zuge der steigenden Komplexität von Software-Systemen gewinnen modellbasierte Ansätze in der Software-Entwicklung [Bro04] immer mehr an Bedeutung. Dadurch wird Mo- dellbasierung auch im Requirements Engineering immer attraktiver [Par98, FG+04a] – sowohl die modellbasierte Erarbeitung von Anforderungen als auch die für diese Arbeit relevante mo- dellbasierte Dokumentation und Analyse von Anforderungen. Daher werden in den nächsten Abschnitten die Begriffe „Modellbasierung“ und „Formalisierung“ definiert und erläutert.
2.2 Modellbasierung
Unter Modellbasierung wird im Kontext dieser Arbeit verstanden, dass dem Anforderungsma- nagement ein explizit definiertes Modell des zu entwickelnden Systems zugrunde liegt, also dass es auf einem expliziten Modell basiert. Ein solches Modell definiert, welche Elemente zu einer Systembeschreibung gehören und welche Relationen auf diesen Elementen zur Verfügung stehen.
Mit Hilfe eines expliziten Modells können Anforderungen
• besser erhoben werden, da die relevanten Informationen (Elemente und Relationen dar- auf) gezielter und systematischer abgefragt werden können.
• besser dokumentiert werden, da für die relevanten Informationen spezifische Dokumen- tationsformen angeboten werden können, die gezielte Unterstützung für die einzelnen Inhalte anbieten können.
• besser analysiert werden, da, abhängig von der Formalität des Modells, die Anforde- rungsinhalte über das Modell strukturierter dargestellt und semantisch greifbar werden und damit zum Teil sogar automatisch auf Konsistenz und Vollständigkeit überprüft werden können.
• besser übergeben werden, wenn die Modelle des Anforderungsmanagements und des Designs aneinander ausgerichtet sind.
Diese Arbeit widmet sich der modellbasierten Formalisierung von Anforderungen: Wie kann man frei erfasste, informelle Anforderungen mit Hilfe eines Modells systematisch in eine präzi- sere, vollständigere und kompaktere Darstellungsform bringen, die sich leicht in die Elemente des Designs überführen lässt?
In diesem Kontext sind drei Begriffe wichtig: Modell, Darstellungsform und Formalisierung.
• Ein explizites Modell kann auf verschiedene Weisen definiert werden: eher informell („Ein Zustand ist eine Situation, in der…“) oder eher formal („Zustand z = {v i |i ∈ IN ∧ …“). Im Kapitel 5 wird das den Nutzeranforderungen zugrundeliegende Modell einge- betteter Systeme explizit gemacht und formal definiert.
• Steht das Modell fest, so gibt es in der Regel eine Reihe von alternativen Darstellungs- formen für das Modell. Ein Zustandsmodell kann beispielsweise graphisch oder in Ta-
Seite 28
Modellbasierte Formalisierung von Anforderungen
bellenform oder als freier Text dargestellt werden. Im Kapitel 6 wird eine für das An-
forderungsmanagement geeignete Darstellungsform definiert.
• Steht das Modell fest und ist eine geeignete Darstellungsform definiert, so ist die Auf-
gabe einer Methodik, Anforderungen in diese Darstellungsform zu überführen. Da in
der vorliegenden Arbeit die Darstellungsform semiformal ist, kann diese Methodik als
Formalisierungsmethodik bezeichnet werden, die informell vorliegende Anforderungen
schrittweise in eine formalere Form überführt (formalisiert). In den Kapiteln 7 bis 10
wird diese Formalisierungsmethodik, bestehend aus vier Formalisierungsschritten, ent-
wickelt.
Um eine Durchgängigkeit zum Design zu erreichen, liegt sowohl dem Anforderungsmanage-
ment als auch dem Design dasselbe Systemmodell zugrunde – aber in unterschiedlichen, jeweils
für die Aufgabe angemessenen Detailtiefen und Formalisierungsgraden. Dadurch, dass beide
Teilprozesse dasselbe Modell verwenden, ist ein nahtloser Übergang zwischen den beiden Teil-
prozessen möglich (Durchgängigkeit); dadurch, dass beide Teilprozesse dieses Systemmodell in
jeweils angemessener Detailtiefe und Formalisierungsgrad benutzen, kann das Modell die je-
weiligen Aufgaben spezifisch unterstützen.
Modelle werden in der Informatik häufig mit formalen Modellen gleichgesetzt; ein Modell muss
aber nicht notwendigerweise formal sein [Sta73, Ama05]. Allerdings liegt einer Formalisierung
immer ein Modell zugrunde.
2.3 Formalisierung
Unter Formalisierung wird in dieser Arbeit das schrittweise Verändern der Form einer Anforde-
rung verstanden (ohne dabei ihren Inhalt zu verändern 10 ), sodass ein zunächst natürlichsprachi-
ger freier Text immer mehr Regeln genügen muss, und immer mehr auf seine wesentliche Aus-
sage komprimiert wird. Diese Regeln beziehen sich insbesondere auf den zur Verfügung ste-
henden Wortschatz (es wird definiert, aus welchen Elementen eine Anforderung bestehen darf,
und wie diese Elemente formuliert werden müssen) und die Anordnung dieser Elemente
(Grammatik): es wird definiert, nach welchen Mustern die Elemente innerhalb einer Anforde-
rung angeordnet werden müssen, und welche Elemente in einem Muster optional oder obligato-
risch sind.
Diese Regeln leiten sich aus einem zugrundeliegenden Modell ab; dieses Modell wird im Kapi-
tel 5 beschrieben, und die daraus abgeleitete semiformale Darstellungsform im Kapitel 6.
Auf dem Modell hätte auch eine rein informelle Darstellungsform definiert werden können; die
Entscheidung für eine semiformale Darstellung, und damit für eine modellbasierte Formalisie-
rung von Anforderungen, wurde aus fünf Gründen heraus getroffen:
• Erstens handelt es sich um eine Informationskompression, die eine Konzentration auf
das Wesentliche anstrebt (im Gegensatz zu natürlichsprachigen Formulierungen, die
immer inhaltlich überflüssiges sprachliches Beiwerk enthalten).
10 Die Forderung, dass die Formalisierung nur die Form, nicht aber den Inhalt einer Anforderung verändern soll,
spiegelt ein Prinzip der Formalisierung wieder, das eher die grobe Richtung der Formalisierung beschreibt, und we-
niger ihre tatsächliche Praxis; in der tatsächlichen Anwendung ist die Formalisierung sehr oft mit Qualitätsverbesse-
rungen der Anforderungen verbunden, die sich auch in der inhaltlichen Präzisierung und in der inhaltlichen Vervoll-
ständigung niederschlagen.
Seite 29
Modellbasierte Formalisierung von Anforderungen
• Zweitens wird es möglich, durch Reduktion von Interpretationsfreiheiten Anforderun- gen sehr präzise zu formulieren (im Gegensatz zu natürlichsprachigen Formulierungen,
die inhärent anfällig für Missverständnisse 11 sind [Rup01, Sch98]).
• Drittens ist eine Vereinheitlichung der Form einer Anforderung auch ein Mittel, um in- haltliche Defizite zu identifizieren und zu beseitigen (hier findet eine Verzahnung mit Elicitation und Analyse statt).
• Viertens kann durch eine geeignete modellbasierte Formalisierung die Durchgängigkeit zum Design entschieden verbessert und damit eine bedeutsame Fehlerquelle reduziert werden (wenn ein Formalismus gewählt wird, der leicht in Designmodellelemente über- führt oder zumindest mit ihnen verknüpft werden kann).
• Fünftens ist eine Formalisierung Grundlage für eine weiterreichende Werkzeugunter- stützung (so sind bei geeigneten Formalismen automatische oder zumindest halbauto- matische Konsistenzchecks und Vollständigkeitsanalysen denkbar).
Es gibt verschiedene Ansätze zur Formalisierung von Anforderungen (siehe Kapitel 14), die zum Teil auf graphische, zum Teil auf mathematische Notationen zurückgreifen. Alle diese Ansätze haben den Nachteil, dass auf diese Weise umformulierte Anforderungen für die meisten Stakeholder, die die Anforderungen ursprünglich eingebracht haben, nicht mehr verständlich und damit nicht mehr validierbar sind. Daher wird in dieser Arbeit ein Formalisierungsansatz entwickelt, der nicht ganz so streng formalisiert, dafür aber die Verständlichkeit der Anforde- rungen weitgehend erhält (das Kriterium für die Verständlichkeit ist hier die Möglichkeit, eine
Anforderung noch als natürlichen Text interpretieren zu können 12 ).
Die Formalisierung von Anforderungen muss nicht notwendigerweise bedeuten, dass dadurch die Anforderungen dem Design angenähert werden und die Durchgängigkeit zum Design er- leichtert wird; in der Praxis aber sind die meisten Formalisierungsansätze inzwischen auf ein bestimmtes Designparadigma ausgerichtet, weil sich ohne eine solche Durchgängigkeit der For- malisierungsaufwand kaum rechtfertigen ließe. In dieser Arbeit werden als Referenzmodell für das Design die im Projekt Mobilsoft entwickelten Modellierungsebenen der CAR-DL gewählt (siehe [HR+07, HR07] und Kapitel 10). Es handelt sich dabei um eine modellbasierte Beschrei- bungssprache für das Design eingebetteter Software, die auf der EAST-ADL [Lön04] aufbaut.
2.4 Eingebettete Systeme im Automotive Bereich
Die in dieser Arbeit entwickelte Formalisierungsmethodik wurde exemplarisch an der Domäne eingebetteter System in Fahrzeugen erprobt und validiert. In diese Domäne der eingebetteten Systeme wird im Folgenden kurz eingeführt.
2.4.1 Eingebettete Systeme
Eingebettete Systeme sind Software-/Hardwaresysteme, die als Teil eines größeren Systems für den Benutzer verborgen arbeiten, aber für die Funktions- und Leistungsfähigkeit des Gesamt- systems sehr wichtig sind. Ihre Aufgabe besteht darin, eine Anzahl technischer Geräte und phy- sikalischer Prozesse der Umgebung mittels Sensoren zu überwachen und/oder gemäß einer de-
11 Siehe die Phänomene sprachlicher Defekte (Tilgung, Generalisierung, Verzerrung) in natürlichsprachigen Spezifi-
kationen [Rup01].
12 Die Thematik der Verständlichkeit von Modellen wurde vom Autor in [AF06] ausführlich behandelt.
Seite 30
Modellbasierte Formalisierung von Anforderungen
finierten Funktionalität mittels Aktuatoren zu steuern und zu regeln. Sie sind reaktiv: abhängig
von aktuellen Eingaben und Zustandsinformation der Umgebung werden die relevanten Größen
und Prozesse gesteuert [FG+04a].
In modernen Fahrzeugen versehen heutzutage bis zu 80 eingebettete Systeme ihren Dienst 13 ;
beispielsweise [EE07]:
• ABS - Antilock Brake System (Anti-Blockier System)
• ACC - Automatic Cruise Control (Abstandsgeregelte Cruise Control)
• AFL - Adaptive Forward Lighting (Kurvenfahrlicht)
• APS - Acoustic Parking System (Rückfahr-Abstandswarner)
• CBC - Cornering Brake Control (Kurvenbremshilfe)
• DSR - Driver Steering Recommendation (Lenkhilfe)
• EPB - Electronic Parking Brake (Electronics Handbremse)
• HDC - Hill Descent Control (Bergabfahrhilfe)
• TPMS - Tyre Pressure Measurement System (Reifendruckkontrolle)
• TSP - Trailer Stability Program (ESP für Anhänger) Die Charakteristika eingebetteter Systeme und die sich daraus ergebenden Herausforderungen
für das Requirements Engineering sind vom Autor in [FG+04a] bereits eingehend beschrieben
worden. Im Folgenden werden die für diese Arbeit wichtigsten Aspekte noch einmal zusam-
mengefasst:
• Einbettung: Eingebettete Systeme sind, wie der Name schon sagt, in ein Gesamtsystem
eingebettet und werden vom Nutzer des Gesamtsystems meist nicht als eigenständiges
System wahrgenommen, sondern als Teil des Verhaltens des Gesamtsystems. Daher ha-
ben eingebettete Systeme in der Regel kein eigenes Nutzerinterface, sondern werden
über das Interface des Gesamtsystems bedient.
• Komplexe Systemumgebung: Eingebettete Systeme agieren in einer komplexen Umge-
bung, die aus Sensoren und Aktuatoren, sowie aus einer Vielzahl von anderen eingebet-
teten Systemen besteht.
• Parallelität, Echtzeit, Kritikalität: Eingebettete Systeme werden oft in sicherheitskriti-
schen Bereichen eingesetzt und müssen in der Regel in Echtzeit reagieren.
• Interdisziplinärer Entwurf: Eingebettete Systeme werden von Hardware- und Software-
Entwicklern gemeinsam entwickelt. Dieser Aspekt der Interdisziplinarität wird bei-
spielsweise in [Gei05] thematisiert.
2.4.2 Automotive-Spezifika
Eingebettete Systeme finden inzwischen in vielfältigen Bereichen Verwendung, beispielsweise
Fahrzeuge, Waschmaschinen oder Handys. Dass die in dieser Arbeit entwickelte Methodik ex-
plizit auf den Automotive-Bereich beschränkt ist, ist zuvorderst damit begründet, dass diese
Methodik fallstudiengetrieben entworfen wurde (siehe Abschnitt 3.2) und alle verwendeten
13 Zurzeit werden viele Funktionalitäten noch zusammen mit „ihrem“ eigenen eingebetteten System (Steuergerät)
entwickelt; dadurch wächst die Zahl der Steuergeräte in Fahrzeugen immer mehr, so dass für die Zukunft geplant ist,
dass sich verschiedene Funktionalitäten eine Hardware „teilen“.
Seite 31
Modellbasierte Formalisierung von Anforderungen
Fallstudien aus dem Automotive-Bereich stammen. Daher lässt sich zunächst keine Allgemein- gültigkeit für alle eingebetteten Systeme ableiten. Im Projekt Mobilsoft [FB+06] werden die für die Automobilindustrie charakteristischen Aspekte bei der Spezifikation eingebetteter System in Fahrzeugen beschrieben, von denen die wichtigsten hier auszugsweise wiedergegeben werden:
• Hoher Anteil an Fremdentwicklung: Die Entwicklung von Fahrzeugen verteilt sich auf eine ganze Reihe von Zulieferern, die zum Teil innerhalb eines großen Entscheidungs- freiraumes eingebettete Systeme für das Gesamtsystem entwickeln.
• Hohe Stückzahl: Eingebettete Systeme für Fahrzeuge sind keine Individualentwicklun- gen, sondern werden meist in hoher Stückzahl hergestellt.
• Variantenvielfalt: Die Variantenvielfalt bei den Fahrzeugen (beispielsweise Fahrzeug- reihen, Ausstattungsvarianten) spiegelt sich auch in der Variantenvielfalt bei eingebette- ten Systemen wider. Dadurch wird die systematische Wiederverwendung von Anforde- rungen bis hin zu Produktlinien zu einem sehr wichtigen Faktor.
• Kurze Entwicklungszyklen: Mit fünf bis sieben Jahren ist der Entwicklungszyklus recht kurz für so komplexe Systeme wie Fahrzeuge sie darstellen.
• Mischung aus Bottom-Up und Top-Down Vorgehen: Ein komplexes System wie ein Fahrzeug, an dem viele verschiedene Disziplinen und Zulieferer arbeiten, kann nicht in einem reinen Bottom-Up oder Top-Down Vorgehen entwickelt werden, vielmehr findet ein Mischung aus diesen beiden Ansätzen Anwendung. Das führt zu „Simultaneous En- gineering“, das heißt, dass voneinander abhängige Systeme parallel entwickelt werden.
• Große Anforderungsmenge: Die Komplexität der Fahrzeuge und die vielfältigen Ab- hängigkeiten der eingebetteten Systeme innerhalb des Fahrzeugs spiegelt sich in einer großen Anzahl von Anforderung und Anforderungsabhängigkeiten wieder.
Einige dieser Aspekte teilen sich Eingebettete Systeme in Fahrzeugen mit denen anderer Syste- me (beispielsweise trifft „Hohe Stückzahl“ sowohl auf Fahrzeuge als auch Handys zu), andere wiederum unterscheiden sich (beispielsweise trifft der Aspekt „Hoher Anteil an Fremdentwick- lung“ nicht auf Handys zu). Dennoch kann der in dieser Arbeit betrachtete Teil des Anforde- rungsmanagements, nämlich die modellbasierte Anforderungsdokumentation, prinzipiell auch auf andere Domänen übertragen werden; zwar werden sich die Modelle und Modell- Taxonomien unterscheiden, das grundsätzliche Vorgehen aber, wie in dieser Arbeit beschrieben, ist dennoch anwendbar. Dies exemplarisch anhand von Fallstudien aus anderen Domänen zu demonstrieren und zu diskutieren ist ein Punkt für an diese Arbeit anknüpfende weitere Arbei- ten (siehe Ausblick).
Seite 32
Modellbasierte Formalisierung von Anforderungen
3. Wissenschaftliche Vorgehensweise und Fallstudie
Die in dieser Arbeit vorgestellte Formalisierungsmethodik wurde in engem Wechselspiel mit der Durchführung verschiedener Fallstudien aus der Automobilindustrie entwickelt; dazu wurden in mehren Iterationen Konzepte entwickelt, anhand von Fallstudien ange- wendet und gemeinsam mit Industriepartnern evaluiert. Damit eine so entwickelte Me- thodik nicht nur für die betrachteten Fallstudien von Bedeutung, sondern grundsätzlich anwendbar ist, wurde sichergestellt, dass die verwendeten Fallstudien repräsentativ für die betrachtete Domäne sind. Die betrachteten Fallstudien waren ein Fahrerassistenzsys- tem „Adaptive Cruise Control“ (BMW) und ein Türsteuergerät (DaimlerChrysler).
3.1 Vorarbeiten
Diese Arbeit basiert neben dem Fachwissen im Bereich modellbasierter Entwicklung eingebet- teter Systeme und Requirements Engineering auf den folgenden Vorarbeiten, die vom Autor in verschiedenen Projekten gemacht wurden:
• Empress (01/03 bis 10/03): In diesem Projekt wurde ein Datenmodell und ein Require- ments Engineering Prozess entworfen, die spezifisch auf eingebettete Echtzeitsysteme zugeschnitten waren. Schwerpunkt lag dabei auf der Strukturierung natürlichsprachiger Anforderungen [EM07].
Projektbeteiligte waren neben der TU München (Jewgenij Botaschanjan, Andreas Fleischmann, Markus Pister) die beiden Fraunhofer Institute IESE und FIRST, Daimler- Chrysler, Bosch, Siemens, Validas und die TU Eindhoven.
• Inremove (10/03 bis 05/04): In diesem Projekt lag der Schwerpunkt auf der Übersetzung natürlichsprachiger Anforderungen in formalere Konstrukte; dabei wurden aber ledig- lich einzelne Anforderungen prototypisch übersetzt und nicht die Übersetzung ganzer Anforderungsmengen betrachtet.
Projektbeteiligte waren neben der TU München (Andreas Fleischmann, Markus Pister, Alexander Wißpeintner) das Stanford Research Institute (SRI International) und das Army Research Office.
• Refocus (02/04 bis 10/04): In diesem lehrstuhlinternen Projekt ging es um einen allge- meingültigen Entwurf eines Requirements Engineering Prozessframeworks spezifisch für eingebettete Systeme [FG+04b, FG+04c]. Das Framework wurde später zum Kern des Referenzmodells REM [GB+06]. Ein weiteres Ergebnis dieses Projektes war die Entwicklung eines prototypischen modellbasierten Anforderungswerkzeugs AUTO- RAID, [AR07], das mittlerweise in das modellbasierte Entwicklungswerkzeug AUTO-
FOCUS [AF07] integriert wurde.
Projektbeteiligt war nur die TU München (Andreas Fleischmann, Eva Geisberger, Mar- kus Pister).
• Mobilsoft (12/04 bis 06/07): Im Teilprojekt „Anforderungsmanagement“ im bayeri- schen Forschungsverbund wurde neben mehreren anderen Arbeitspaketen vom Autor eine Methodik zur schrittweisen Formalisierung von Anforderungen innerhalb des Re- quirements Engineering Prozesses erarbeitet [Fle07b], deren Weiterentwicklung in der vorliegenden Arbeit dokumentiert ist.
Seite 33
Modellbasierte Formalisierung von Anforderungen
Projektbeteiligte waren neben der TU München (Andreas Fleischmann, Judith Hart- mann, Martin Rappl, Sabine Rittmann, Doris Wild) die beiden bayerischen Automobil- hersteller BMW und Audi, sowie die Zulieferer- und Beratungsfirmen Siemens, Validas und ESG.
Im Rahmen dieser Projekte wurde der aktuelle Stand des Requirements Engineering sowohl in Forschung [FG+04a] wie auch in Praxis [FB+05] analysiert und die spezifischen Herausforde- rungen für ein Requirements Engineering für eingebettete Systeme [FG+04a, FG+04c] heraus- gearbeitet. Darüber hinaus wurde ein allgemeines Prozess-Framework Refocus entworfen, das später zu REM ([Gei05, GB+06]) und [FB+06] weiterentwickelt wurde. Darauf aufbauend wur- de im Verlauf des Projektes Mobilsoft und darüber hinausgehend die vorliegende Formalisie- rungsmethodik entwickelt, erprobt und evaluiert. Diese passt sich in das Prozessframework
REM [GB+06, FB+06] ein.
Persönlicher Beitrag des Autors an den Projektarbeiten: Der Kern der in dieser Arbeit vorge- stellten Formalisierungsmethodik wurde in den Jahren 2005 bis 2007 im Projekt Mobilsoft ent- wickelt; dabei war die Methodik Bestandteil eines Arbeitspaketes, das in der alleinigen Verant- wortung des Autors lag und von ihm alleine inhaltlich vorangetrieben und bearbeitet wurde – unter Rückgriff auf die bei den jeweiligen Meilensteinen durchgeführten Diskussionen, Feed- backs und Evaluationen durch die anderen am Projekt beteiligten Kollegen aus Industrie und Forschung.
3.2 Wissenschaftliche Vorgehensweise und Validierungsansatz
Neben den geschilderten Vorarbeiten und dem Feedback aus Industrie [Mob07] und Forschung [FH+05][HF+06][HR+06] war dabei die Fallstudienanwendung ein zentrales Instrument so- wohl zur Entwicklung als auch zur Qualitätssicherung der Methodik: die entwickelten Konzepte wurden in den Fallstudien angewandt und die dabei gewonnen Erkenntnisse flossen in die Ü- berarbeitung der Konzepte zurück; dieses Vorgehen wurde mehrfach wiederholt.
• Dabei war es zum einen wichtig, sicherzustellen, dass die verwendeten Fallstudien re- präsentativ für die betrachtete Domäne sind. Ansonsten würden für Randerscheinungen einzelner Fallstudien Lösungskonzepte entwickelt werden, die im allgemeinen eventuell gar nicht benötigt werden und die Methodik unnötig aufblähen; außerdem könnten wichtige Probleme ungelöst bleiben, wenn sie zufälligerweise in den Fallstudien nicht auftreten.
• Zum anderen war es wichtig, sich durch die Gebundenheit der Fallstudien an die gegen- wärtige Praxis, und insbesondere auch durch die z.T. mangelnde Qualität der Fallstu- dien nicht einschränken zu lassen bei der Findung zukunftstragender Konzepte.
Dies wurde durch die Auswahl der Fallstudien und die enge Rückkopplung mit verschiedenen Industriepartnern (Automobilhersteller wie beispielsweise BMW oder Audi, sowie Automobil- zulieferer wie beispielsweise Siemens VDO oder ESG) gewährleistet. Insbesondere im Projekt Mobilsoft [Mob07] wurde die Entwicklung der Methodik über einen Zeitraum von mehr als zwei Jahren von den Partnern aus Industrie und Forschung begleitet und mehrfach konstruktiv evaluiert.
Um sicherzustellen, dass die entwickelte Formalisierungsmethodik und das zugrundeliegende Formalisierungskonzept erstens überhaupt praktisch anwendbar ist, zweitens einen signifikanten
Seite 34
Modellbasierte Formalisierung von Anforderungen
Mehrwert bringt und drittens anderen vergleichbaren Ansätzen überlegen ist, wurde folgender
Validierungsansatz verfolgt: In den Abschnitten 1.2 und 1.3 wurden die Problemstellung und
die Zielsetzung der Arbeit vorgestellt, an denen sich diese Arbeit messen lassen muss. Die Vali-
dierung der Methodik, also der Abgleich von Anspruch und Wirklichkeit, wird wie folgt durch-
geführt:
• Die praktische Anwendbarkeit wurde anhand verschiedener Fallstudien aus der Praxis
erprobt, von denen zwei in dieser Arbeit dokumentiert sind (siehe Abschnitt 3.3). Insbe-
sondere die Durchführung der Fallstudie „Abstandsgeregelter Tempomat“ (Abschnitt
3.3.1) wurde im Projekt Mobilsoft von Industriepartnern kritisch begleitet und in mehre-
ren Iterationen wurde mit Hilfe des Feedbacks der Projektpartner die praktische An-
wendbarkeit der Methodik erhöht [Fle07a, Fle07b], einschließlich einer praxistaugli-
chen Integration in einen gesamten Anforderungsprozess [FB+06]. Da die Anwendbar-
keit bereits in Forschungsprojekten mit Industriepartnern evaluiert wurde, wurde auf
„Trockentests“ (zum Beispiel durch Studentenpraktika) verzichtet.
• Der Mehrwert der Methodik wird im Verlauf dieser Arbeit immer wieder anhand der
Fallstudien demonstriert durch eine Gegenüberstellung der unformulierten und der um-
formulierten Anforderungen und einer Diskussion des Mehrwerts. Hierzu wird auf die
Kapitel 7 bis 10 verwiesen, insbesondere auf die Abschnitte 7.4, 8.4 und 9.4.
• Die Vorteile der Methodik gegenüber anderen vergleichbaren Ansätzen werden im Ka-
pitel 14 zusammengefasst dargestellt. Darüber hinaus werden die besonders prägnanten
Vorteile direkt in den Kapiteln 7 bis 10, in denen die einzelnen Formalisierungsschritte
beschrieben werden, anhand der Fallstudie verdeutlicht, insbesondere in den Abschnit-
ten 7.4, 8.4 und 9.4
3.3 Fallstudien
Die beiden in dieser Arbeit dokumentierten Fallstudien 14 stammen aus der Automobilindustrie
und entsprechen dem Stand der heutigen Praxis. In beiden Fällen sind die Anforderungen in-
formell erfasst worden und haben daher viele der typischen Mängel einer informellen Spezifika-
tion, wie in Kapitel 1.2 beschrieben. Genau hier setzt die vorliegende Arbeit an und erhöht
durch die Formalisierungsmethodik schrittweise immer mehr die Qualität der Anforderungen,
d.h. präzisiert sie, vervollständigt sie und deckt Inkonsistenzen auf. Anhand dieser beiden Fall-
studien wird im weiteren Verlauf der Arbeit immer wieder die Anwendung der Formalisie-
rungsmethodik veranschaulicht und ihr Nutzen demonstriert werden.
3.3.1 Abstandsgeregelter Tempomat (ACC)
Ein abstandsgeregelter Tempomat (Adaptive Cruise Control, ACC) verbindet die Funktionalität
eines Tempomats (selbständiges Halten der Wunschgeschwindigkeit) mit dem Halten eines
Sollabstands zu einem voranfahrenden Fahrzeug. Die folgende Grafik stellt diese beiden Funk-
tionalitäten schematisch dar:
14 Die Methodik wurde und wird noch an weiteren Fallstudien erprobt. Aufgrund von Non Disclosure Agreements
dürfen diese nicht in dieser Arbeit dokumentiert werden.
Seite 35
Modellbasierte Formalisierung von Anforderungen
Abbildung 8: Ein typisches Szenario für einen ACC [Bo03]
In der obersten Reihe (1) wird das Halten der Geschwindigkeit skizziert (Tempomat), in der zweiten Reihe (2) wird dargestellt, wie das Fahrzeug verzögert, wenn ein voranfahrendes Fahr- zeug langsamer als Wunschgeschwindigkeit fährt (Halten des Sollabstands) und in der dritten Reihe (3) wird gezeigt, dass das Fahrzeug wieder auf Wunschgeschwindigkeit beschleunigt, wenn das voranfahrende langsamere Fahrzeug verschwunden ist.
Dieses grob beschriebene Verhalten des ACC wurde in einem zweiseitigen Spezifikationsdo- kument [Bau05], das von der BMW CarIT zur Verfügung gestellt wurde, und das auch als Fall- studie im Projekt Mobilsoft [AI07, Fle07a] diente, durch 27 rein textuelle Anforderungen (Ver- haltensregeln) stichpunktartig beschrieben. Man kann dabei folgende Situationen unterscheiden:
• Freies Fahren auf gerader Strecke oder in einer Kurve, bei normalen oder bei erschwer- ten Witterungsverhältnissen.
• Folgefahren auf gerader Strecke oder in einer Kurve, bei normalen oder erschwerten Witterungsverhältnissen, sowie im Stop&Go Verkehr.
Darüber hinaus wird das Aktivieren/Deaktivieren des ACC durch den Fahrer durch Betätigen des Brems- oder Gaspedals beschrieben, sowie die Veränderung von „Sollabstand“ und „Wunschgeschwindigkeit“, zum Teil automatisch bei schlechtem Wetter oder Kurvenfahren, zum Teil manuell durch den Fahrer.
Die folgende Liste enthält alle 27 Originalanforderungen dieses Fallbeispiels [Bau05]:
Seite 36
Modellbasierte Formalisierung von Anforderungen
Bei der Analyse dieser Anforderungen fällt sofort auf, dass die Qualität dieser Anforderungen
nicht optimal ist, insbesondere sind sie missverständlich formuliert und unvollständig. Dies soll
am Beispiel der ersten Anforderung kurz erläutert werden:
1. Fahren auf Gerade ohne Objekt: komfortabel beschleunigen, bis Wunschgeschwindigkeit erreicht, dann
Wunschgeschwindigkeit halten
Durch die Formulierung „komfortabel beschleunigen“ wird nahegelegt, dass die Voraussetzung
ist, dass das Fahrzeug langsamer als Wunschgeschwindigkeit fährt; der Fall, dass das Fahrzeug
schneller ist, wird nicht abgedeckt. Die Formulierung „dann Wunschgeschwindigkeit halten“
wiederum steht für einen dritten Fall, nämlich, dass das Fahrzeug die Wunschgeschwindigkeit
erreicht hat. Somit steht diese Anforderung eigentlich für drei Anforderungen. Zudem sind die
Begriffe „ohne Objekt“ und „komfortabel“ nicht definiert.
Es finden sich auch Widersprüche in dieser Spezifikation, die aus unklaren Formulierungen
herrühren:
8. Kurz nach Objektverlust und Gaspedal vom Fahrer betätigt: zügig beschleunigen
11. Gaspedal vom Fahrer betätigt: ACC inaktiv, nach Loslassen des Gaspedals Übergang in Wunschgeschwin-
digkeit komfortabel gestalten
Seite 37
Modellbasierte Formalisierung von Anforderungen
Und es finden sich undefinierte Begriffe, wie hier beispielsweise „Wunschgeschwindigkeit an-
passen“:
12. glatte Fahrbahn oder geringe Sichtweite: Wunschgeschwindigkeit anpassen, nur wenig beschleunigen Im Verlauf dieser Arbeit wird daher anhand dieser Fallstudie demonstriert werden, wie durch
die schrittweise Formalisierung diese Anforderungen nicht nur präziser und verständlicher for-
muliert werden, sondern auch viele Inkonsistenzen und Unvollständigkeiten systematisch aus-
geräumt werden.
3.3.2 Türsteuergerät (TSG)
Die Spezifikation eines Türsteuergerätes (TSG) wurde von Barbara Paech (Fraunhofer Institut
für experimentelles Software Engineering, IESE 15 ) und Frank Houdek (DaimlerChrysler AG) verfasst, um ein öffentliches Beispieldokument zur Verfügung zu stellen, das von Interessierten
als Fallstudie benutzt werden kann; es liegt als öffentliches Dokument vor [HP02]. In dieser
rund fünfzigseitigen Spezifikation wird ein fiktives Türsteuergerät eines Automobils beschrie-
ben, das folgende Funktionen im Fahrzeug übernimmt:
• Sitzeinstellung: Verstellen des Lehnenwinkels, der horizontalen Sitzposition, der Höhe des vorderen Sitzbereichs, der Höhe des hinteren Sitzbereichs und der Schalung des Sit-
zes.
• Türschloss: Auf- und Zuschließen des Fahrzeugs über Schlüssel, Funksender oder Cont- roller Area Network (CAN).
• Fensterheber: Heben und Senken der Fensterscheiben des Fahrzeugs unter Beachtung einer etwaigen Kindersicherung.
• Innenraumbeleuchtung: Beleuchtung des Fahrzeuginneren als Hilfe beim Ein- und Aus- steigen.
• Außenspiegeleinstellung: Verstellen der Außenspiegel entlang einer horizontalen und einer vertikalen Achse.
Darüber hinaus verfügt das Türsteuergerät über ein rudimentäres Benutzermanagement, das
Sitz- und Außenspiegeleinstellungen abspeichern kann.
15 Inzwischen Professorin für Software-Technik an der Universität Heidelberg.
Seite 38
Modellbasierte Formalisierung von Anforderungen
Abbildung 9: Schematische Darstellung der Bedienelemente des TSG [PH02]
Die Anforderungen aus dieser Fallstudie sind zu umfangreich (rund fünfzig Seiten), um sie hier oder im Anhang abzudrucken; die Fallstudie ist aber öffentlich zugänglich [HP02]. Die folgende Abbildung 10 zeigt einen exemplarischen Auszug einer Seite aus dieser Spezifikation:
Seite 39
Modellbasierte Formalisierung von Anforderungen
Abbildung 10: Eine exemplarische Seite aus der Fallstudie "Türsteuergerät"
In der Spezifikation dieser Fallstudie wird die Funktionalität von Sitzeinstellung, Türschloss, Fensterheber, Innenraumbeleuchtung, Außenspiegeleinstellung detailliert in Form von gut strukturierten Anforderungen beschrieben, darüber hinaus werden auch die relevanten Hard- warebauteile und Steckerelemente spezifiziert; dabei werden zur Spezifikation informelle Gra- fiken, Tabellen und Fließtext benutzt. Dadurch bietet diese Fallstudie ein breites Spektrum (be- züglich Inhalt, Form und Strukturierung) an Anforderungen.
Seite 40
Arbeit zitieren:
Andreas Fleischmann, 2008, Modellbasierte Formalisierung von Anforderungen für eingebettete Systeme im Automotive-Bereich, München, GRIN Verlag GmbH
Dieser Text kann über folgende URL aufgerufen und zitiert werden:
Einbetten
DOI
Entwurf und Implementierung von Algorithmen zur Erfassung und Verfolgu...
Informatik - Theoretische Informatik
Diplomarbeit, 72 Seiten
Metamorphosys: Entwurf eines autonomen adaptiven Systems
Informatik - Technische Informatik
Doktorarbeit / Dissertation, 236 Seiten
Kosten und Nutzen von Portalen im Unternehmen
Informatik - Wirtschaftsinformatik
Hausarbeit, 22 Seiten
Erarbeitung eines Konzepts für die Integration eines Shop-Systems mit ...
Ingenieurwissenschaften - Maschinenbau
Diplomarbeit, 100 Seiten
Andreas Fleischmann's Text Modellbasierte Formalisierung von Anforderungen für eingebettete Systeme im Automotive-Bereich ist nun auf dem Buchmarkt erhältlich
Andreas Fleischmann hat den Text Modellbasierte Formalisierung von Anforderungen für eingebettete Systeme im Automotive-Bereich veröffentlicht
Andreas Fleischmann hat einen neuen Text hochgeladen
Entwurf und Implementierung von Algorithmen zur Erfassung und Verfolgu...
Informatik - Theoretische Informatik
Diplomarbeit, 72 Seiten
Metamorphosys: Entwurf eines autonomen adaptiven Systems
Informatik - Technische Informatik
Doktorarbeit / Dissertation, 236 Seiten
Kosten und Nutzen von Portalen im Unternehmen
Informatik - Wirtschaftsinformatik
Hausarbeit, 22 Seiten
Erarbeitung eines Konzepts für die Integration eines Shop-Systems mit ...
Ingenieurwissenschaften - Maschinenbau
Diplomarbeit, 100 Seiten
Effizientes Framework - Vom De...
Joachim Wietzke, Tran Manh Tien
Software-Engineering eingebetteter Systeme
Grundlagen-Methodik-Anwendunge...
Peter Liggesmeyer, Dieter Rombach
Systemgrundlagen und Entwicklu...
Karsten Berns, Bernd Schürmann, Mario Trapp
0 Kommentare