Modellbasierte Formalisierung von Anforderungen für eingebettete Systeme im Automotive-Bereich

Inhaltsverzeichnis

Kurzfassung

Danksagung

Teil I: Einführung

1. Motivation und Zielsetzung
1.1 Bedeutung der Anforderungen
1.2 Herausforderungen für die Dokumentation von Anforderungen
1.3 Zielsetzung und Nutzen der Arbeit
1.4 Aufbau der Arbeit

2. Grundlagen
2.1 Requirements Engineering
2.2 Modellbasierung
2.3 Formalisierung
2.4 Eingebettete Systeme im Automotive Bereich
2.4.1 Eingebettete Systeme
2.4.2 Automotive-Spezifika

3. Wissenschaftliche Vorgehensweise und Fallstudie
3.1 Vorarbeiten
3.2 Wissenschaftliche Vorgehensweise und Validierungsansatz
3.3 Fallstudien
3.3.1 Abstandsgeregelter Tempomat (ACC)
3.3.2 Türsteuergerät (TSG)

Teil II: Formalisierungskonzept

4. Auswahl der zu formalisierenden Anforderungen
4.1 Notwendigkeit einer formalisierungsspezifischen Klassifizierung
4.2 Kriterien für eine formalisierungsspezifische Klassifizierung
4.2.1 Durchgängigkeit zur Klassifikation im Design
4.2.2 Durchgängigkeit zur Klassifikation der Elicitation
4.2.3 Spezifische Eignung für die Formalisierung
4.3 Definition der formalisierungsspezifischen Klassifizierung
4.3.1 Prozessanforderung
4.3.2 Geschäftsanforderung
4.3.3 Nutzeranforderung
4.3.4 Systemanforderung
4.4 Konsequenzen dieser Klassifikation
4.4.1 Verzahnung von Anforderungsmanagement und Design
4.4.2 Atomarisierung von Anforderungen
4.4.3 Seiteneffekte einer Klassifikation
4.5 Auswahl der Klasse der funktionalen Nutzeranforderungen

5. Formale Definition des zugrundeliegenden Modells
5.1 Bedeutung des Modells für die Formalisierung
5.2 Informelle Beschreibung des Modells
5.2.1 Unterscheidung in Nutzer- und Systemsicht
5.2.2 Die Nutzersicht
5.2.2.1 Ereignisse, Aktivitäten, Zustände
5.2.2.2 Parameter und Variablen
5.2.2.3 Reaktionsverhalten, Situationsverhalten und Invarianten
5.2.3 Systemsicht und Übergang zum Designmodell
5.3 Formale Definition des Modells
5.3.1 Zeit
5.3.2 Variablen
5.3.3 Zustände
5.3.4 Zustandsraum
5.3.5 Ereignisse
5.3.6 Zustandsübergänge
5.3.7 Aktivitäten und ihre Parameter
5.4 Aussagen auf dem formalen Modell
5.4.1 Reaktionsverhalten
5.4.2 Situationsverhalten
5.4.3 Invarianten
5.5 Zusammenfassung des formalen Modells

6. Definition einer geeigneten Darstellungsform
6.1 Qualitätskriterien für die Darstellung von Anforderungen
6.2 Dimensionen der verwendeten Darstellungsform
6.3 Darstellung der Anforderungsbestandteile
6.3.1 Darstellung von Ereignissen und Zuständen
6.3.1.1 Verwaltung/Strukturierung von Ereignissen und Zuständen
6.3.1.2 Formatierung und Formulierung von Ereignissen und Zuständen
6.3.2 Darstellung von Aktivitäten und ihren Parametern
6.3.2.1 Verwaltung/Strukturierung von Aktivitäten und Parametern
6.3.2.2 Formulierung und Formatierung von Aktivitäten und Parametern
6.3.3 Darstellung von Variablen
6.4 Darstellung der Anforderungen
6.4.1 Schlüsselworte
6.4.2 Darstellung von Reaktionsverhalten
6.4.3 Darstellung von Situationsverhalten
6.4.4 Darstellung von Invarianten
6.5 Strukturierung von Anforderungen
6.5.1 Darstellung einzelner Dienste
6.5.2 Darstellung der Diensthierarchie
6.6 Mächtigkeit der Sprache
6.7 Zusammenfassung

Teil III: Formalisierungsmethodik

7. Klassifikation
7.1 Kurzbeschreibung
7.2 Datenelemente
7.2.1 Informelle Anforderung
7.2.2 Klassifizierte Anforderung
7.2.3 Prozessanforderung
7.2.4 Geschäftsanforderung
7.2.5 Nutzeranforderung
7.2.6 Systemanforderung
7.3 Aktivitäten
7.3.1 Anforderungen aus der Elicitation übernehmen
7.3.2 Anforderung klassifizieren
7.3.3 Anforderung atomarisieren
7.3.4 Anforderung filtern
7.3.5 Formalisierungsziel festlegen
7.4 Demonstration und Diskussion anhand der Fallstudie
7.5 Zusammenfassung
7.6 Steckbrief „Klassifikation“

8. Formulierung
8.1 Kurzbeschreibung
8.2 Datenelemente
8.2.1 Logische Aktion
8.2.1.1 Ereignis
8.2.1.2 Zustand
8.2.1.3 Zustandsraum
8.2.1.4 Aktivität
8.2.1.5 Variable
8.2.1.6 Parameter
8.2.2 Katalog logischer Aktionen
8.2.3 Anforderungsmuster
8.2.3.1 Systemreaktion
8.2.3.2 Systemveränderung
8.2.3.3 Ereignisabhängiges Verbot
8.2.3.4 Situationsverhalten
8.2.3.5 Situationseinschränkung
8.2.3.6 Ereignisunabhängiges Verbot
8.2.3.7 Invariante
8.3 Aktivitäten
8.3.1 Extraktion der logischen Aktionen
8.3.2 Anwendung der Anforderungsmuster
8.4 Demonstration und Diskussion anhand der Fallstudie
8.4.1 Ausgangssituation
8.4.2 Demonstration des gesamten Ablaufs im Überblick
8.4.3 Extraktion von logischen Aktionen im Detail
8.4.4 Anwendung der Anforderungsmuster im Detail
8.5 Zusammenfassung
8.6 Steckbrief „Formulierung“

9. Strukturierung
9.1 Kurzbeschreibung
9.2 Datenelemente
9.2.1 Dienst
9.2.2 Diensttabelle
9.2.3 Lastenheft
9.3 Aktivitäten
9.3.1 Diensttabelle erstellen
9.3.2 Anforderungen den Diensten zuordnen
9.3.3 Dienste analysieren
9.3.4 Lastenheft generieren
9.4 Demonstration und Diskussion anhand der Fallstudie
9.5 Zusammenfassung
9.6 Steckbrief „Strukturierung“

10. Übergabe ans Design
10.1 Referenzmodell für das modellbasierte Design
10.2 Datenelemente
10.2.1 Design.Aktion
10.2.2 Design.Dienst
10.2.3 Design.Invariante
10.3 Übersetzung der Anforderungs- in Designelemente
10.3.1 Übersetzen von logischen Aktionen
10.3.2 Übersetzen von Verhaltensanforderungen
10.3.3 Übersetzen von Invarianten
10.4 Rückkopplung vom Design ins Anforderungsmanagement
10.5 Aktivitäten
10.5.1 Logische Aktionen und Invarianten ans Design übergeben
10.5.2 Anforderung ans Design übergeben
10.6 Zusammenfassung
10.7 Steckbrief „Übergabe ans Design“

Teil IV: Einbettung in den Entwicklungsprozess

11. Datenmodell
11.1 Datenmodell der Formalisierung
11.2 Einordnung in das Referenz-Datenmodell

12. Aktivitätenmodell
12.1 Aktivitätenmodell der Formalisierung
12.2 Einordnung in das Referenz-Aktivitätenmodell
12.3 Verzahnung von Anforderungserarbeitung und -dokumentation

13. Reifegradmodell
13.1 Referenzmodelle für die Reife einer Anforderung
13.2 Einordnung der Formalisierung in ein Reifegradmodell
13.2.1 Specification
13.2.2 Agreement
13.2.3 Representation

Teil V: Bewertung und Ausblick

14. Diskussion ähnlicher Arbeiten
14.1 Das Sophist Regelwerk
14.2 ATTEMPTO CONTROLLED ENGLISH
14.3 Sicherheitsfachsprache der Uni Cottbus
14.4 Modellbasierte Erfassung von Anforderungen mit UML
14.5 Formalisierungsansatz nach AUTORAID
14.6 Anforderungserfassung in OCTOPUS/UML
14.7 Die Spezifikationssprache SALT

15. Zusammenfassung

16. Ausblick
16.1 Formalisierung von Zeiteigenschaften
16.2 Formalisierung von Systemanforderungen
16.3 Vorverlagerung der Modellbasierung
16.4 Werkzeugunterstützung
16.5 Verknüpfung zu einer umfassenden Methodik

Teil VI: Anhang

17. Glossar

18. Literaturverzeichnis

Kurzfassung

Anforderungen sind ein zentrales Arbeitsprodukt im Entwicklungsprozess, mit dem Stakeholder mit sehr unterschiedlichen Bedürfnissen arbeiten müssen. Hierbei kann man vereinfachend unter­scheiden zwischen

- eher informell (also nicht mithilfe formaler Modelle) denkenden und arbeitenden Stakeholdern (beispiels­weise 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 Stake­holdern (beispielsweise Designer, Tester), die Anforderungen gerne in einer formal modellierten Form bekommen würden, 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 Anforderungen informell notiert, sind dadurch inhärent missverständlich, eine systematische Qualitätssicherung ist schwierig und der Übergang zum Design fehleranfällig; oder aber die Anforderungen 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 in­formell formulierte Anforderungen schrittweise in eine formalere Form bringt (so dass Anforderungen präziser formuliert sind und Konsistenzsicherung und Vervollständigung leichter ausgeführt werden können) und dabei andererseits die Ver­ständ­lichkeit der Anforderungen erhält (so dass die Anforderungen weiterhin von informell denkenden Stakeholder ver­standen 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 Softwaresysteme (nämlich funktionale Nutzeranforderungen) das zugrundeliegende Denkmodell zu identifizieren und formal zu definieren,
- dann eine für die im Requirements Engineering anfallenden Aufgaben (insbesondere Vervollständigung, Konsistenzsicherung, Validierung) geeignete semiformale Darstellungsform 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 zugeschnittenen semiformalen Darstellungsform konnte eine pragmatische und wirkungsvolle Formalisierungsmethodik für funktionale Nutzeranforderungen erarbeitet werden, die aus vier aufeinander aufbauenden Schritten besteht:

- Im ersten Schritt, der Klassifikation, werden die Anforderungen zunächst geeignet klassifiziert; dies ist nötig, da die Anforderungen für eingebettete Softwaresysteme in Fahrzeugen sehr heterogen sind und sich entsprechend ihrer Klassifikation auf ganz unterschiedliche Modelle beziehen – und dementsprechend auch unterschiedlich formalisiert werden müssen. In diesem Schritt wird also zunächst aus der gesamten Anforderungsmenge die Teilmenge der funktionalen Nutzeranforderungen herausgefiltert.
- Im zweiten Schritt, der Zerlegung und Formulierung, werden die wesentlichen Bestandteile der klassifizierten Anforderungen identifiziert, und entsprechend dem zugrundeliegenden Modell zunächst einzeln modelliert und umformuliert. Danach werden die Anforderungen selbst modelliert, indem die vorher modellierten Bestandteile innerhalb der Anforderungen standardisiert angeordnet und die Beziehungen zwischen diesen Bestandteilen standardisiert formuliert werden.
- Nach der Umformulierung werden in einem dritten Schritt, der Strukturierung, die Anforderungen in eine Diensthierarchie eingeordnet. Da eine sinnvolle Durchgängigkeit zum Design höhere Ansprüche an die Vollständigkeit der Anforderungen stellt und diese durch die Modellierung hergestellt wird, führt dies zu einer erheblich größeren Anforderungsmenge, wodurch diese Strukturierung notwendig wird, um diese große Anforderungsmenge noch übersichtlich darstellen und systematisch qualitätssichern zu können.
- Im vierten Formalisierungsschritt, der Übergabe, werden die modellierten und strukturierten 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 zugrundeliegende 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 deutschen Automobilherstellern und -zulieferern entwickelt und an einer Fallstudie aus dem Automobilbereich erprobt. Die entwickelte Formalisierungsmethodik hat dabei folgende Vorteile gezeigt:

- Die auf diese Weise umformulierten Anforderungen haben eine höhere Qualität als informelle Anforderungen, da das der Umformulierung zugrundeliegende Modell bestimmte Eigenschaften der Anforderungen (insbesondere Konsistenz, Vollständigkeit, Übersichtlichkeit, Verständlichkeit, Präzision) steigert und die entsprechenden konstruktiven und analytischen qualitätssichernden Maßnahmen gezielt unterstützt.
- Gleichzeitig bleibt (im Gegensatz zu den meisten bislang existierenden Formalisierungsansätzen für Anforderungen) durch die gewählte Darstellungsform des Modells die Verständlichkeit der Anforderungen erhalten, so dass eine Bearbeitung und Validierung durch informell denkende Stakeholder weiterhin möglich ist.
- Da beim Übergang zum Design die Anforderungen nicht neu modelliert werden müssen, sondern lediglich die Darstellungsform des Modells gewechselt wird, ist der Übergang besser nachvollziehbar, weniger fehleranfällig und weniger aufwändig als mit informellen 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 Engagement 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 ProLehre, 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, Bernhard 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 Familie 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,
München, Frühjahr 2008

Teil I Einführung

1. Motivation und Zielsetzung

Da Anforderungen eine zentrale Rolle im Entwicklungsprozess spielen und unterschiedlichste Stakeholder darauf zugreifen müssen, ist es nicht einfach, eine Darstellungsform für Anforderungen zu finden, die allen Stakeholdern gleichermaßen gerecht wird. Insbesondere besteht ein Interessenskonflikt zwischen dem Wunsch nach einer möglichst freien Notation (die eine kreative Anforderungserarbeitung fördert), einer möglichst strukturierten Darstellung (die eine systematische Anforderungserarbeitung, Vollständigkeit und Konsistenz fördert) und einer möglichst formalen Notation (die eine präzise Anforderungsdokumentation 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ändlichkeit 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 in Form von Anforderungen an das zu entwickelnde System beschrieben. Eine Anforderung (engl. Requirement) ist

„(1) eine Bedingung/Fähigkeit/Eigenschaft, die ein Stakeholder 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 einer 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 .

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 unter¬schiedlichen 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 die in den Anforderungen formulierten Constraints und nichtfunktionalen Eigenschaften beeinflusst. Falsche oder fehlende Anforderungen können die Funktionalität oder Architektur des Systems massiv verschlechtern.
- Test: Die Testfälle werden in der Regel aus den Anforderungen gewonnen. Da das fertige Produkt gegen diese Anforderungen getestet wird, können Fehler in den Anforderungen nicht durch Tests aufgedeckt werden.
- Risikomanagement: Das Risikomanagement beruht zu einem Großteil aus der Bewertung der Anforderungen. Falsche oder fehlende Anforderungen können zu einer falschen Risikoabschätzung führen.
- Projektmanagement: Ein wesentlicher Teil des Projektmanagements basiert auf der Analyse der Anforderungen. Falsche oder fehlende Anforderungen können zu Budgetüberschreitungen und Verzögerungen im Zeitplan führen.

Abbildung in dieser Leseprobe nicht enthalten

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 wirtschaftlichen 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:

Abbildung in dieser Leseprobe nicht enthalten

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 in dieser Leseprobe nicht enthalten

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 Anforderungen zurückzuführen. Der häufigste Einzelgrund für das Scheitern liegt dabei mit 13,1% in unvollständigen Anforderungen (siehe Abbildung 4).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Die wichtigsten 10 Einflussfaktoren, die den Projekterfolg gefährden [Sta95, IA02]

Und auch an den Wartungskosten haben Änderungen in den Anforderungen den größten Anteil:

Abbildung in dieser Leseprobe nicht enthalten

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 wichtiger 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 evaluieren (analytische Qualitätssicherung), bevor die Anforderungen den anderen Teilprozessen zur Verfügung gestellt werden. Innerhalb des Entwicklungsprozesses ist für das Erarbeiten, Dokumentieren, Validieren, Verwalten und Qualitätssichern der Anforderungen das Anforderungsmanagement zuständig.

Das Anforderungsmanagement hat in den letzten Jahren nicht zuletzt im Automobilbereich erheblich 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 sicherheitskritischer Systeme wird heute zudem die Erfüllung von Standards, Gesetzen und Normen gefordert, wie beispielsweise SPICE [SP07a, SP07b] und CMMI [CMMI], die beide ein systematisches 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ätsgesicherter Anforderungen in späteren Projekten (bis hin zur Entwicklung und Pflege von Produktlinien [PB+05]) angestrebt.
- Ebenso wird eine hohe Durchgängigkeit zu Nachbarprozessen angestrebt, vor allem eine möglichst nahtlose Übernahme der Anforderungen ins Design (sodass die Übersetzung 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önnen).

Entsprechend der großen Bedeutung der Anforderungen für den Verlauf des Entwicklungsprozesses und für das zu entwickelnde Produkt wird ein effektives Anforderungsmanagement immer wichtiger. Daher beschäftigen sich sowohl in der Forschung als auch in der Praxis Wissenschaftler und Praktiker damit, das Anforderungsmanagement zu verbessern.

Das Anforderungsmanagement kann dabei in verschiedene Aufgaben zerlegt werden : Die Anforderungserarbeitung (Elicitation) beispielsweise beschäftigt sich damit, woher die Anforderungen 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 besten erarbeitet werden können (zum Beispiel durch Einzelinterviews, Marktstudien, Workshops, Fallstudien). Die Qualitätssicherung beschäftigt sich beispielsweise damit, welche Qualitätskriterien im Anforderungsmanagement relevant sind (zum Beispiel Konsistenz, Vollständigkeit, Korrektheit), wie diese Qualitätseigenschaften konstruktiv sichergestellt werden und analytisch überprüft werden können. Bei diesen Aufgaben im Anforderungsmanagement spielt die Art und Weise, wie Anforderungen repräsentiert werden, eine große Rolle. Eine sehr wichtige Aufgabe des Anforderungsmanagements ist es daher, Methoden und Datenstrukturen zur Dokumentation 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 Testfallgenerierung, Ü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 Anforderungsdokumentation detaillierter beschrieben.

1.2 Herausforderungen für die Dokumentation von Anforderungen

Da die Spezifikation ein zentrales Artefakt im Entwicklungsprozess ist, auf das viele unterschiedliche 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 Anforderungen sich daraus an die Dokumentation ergeben.

Zwar sind sehr unterschiedliche Personengruppen an der Erstellung und Nutzung der Anforderungen 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 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 erarbeiten und die Spezifikation zu validieren. Hierzu wird eine flexible Dokumentationsform benötigt, die einerseits Freiraum für kreatives und verteiltes Arbeiten lässt, die andererseits strukturierend unterstützt. Anforderungen werden meistens informell und natürlichsprachig formuliert, weil dies die einzige Sprache ist, die alle beteiligten Stakeholder 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 systematische Erarbeitung einer möglichst vollständigen Spezifikation werden oft Musterdokumente (mit vorgegebenem Inhaltsverzeichnis), Checklisten, Use-Cases oder Storycards verwendet. Die Anforderungen können im Rahmen des weiteren Dokumentationsprozesses verbessert werden, müssen aber auch danach noch von den Stakeholdern verstanden werden, da sonst keine Validierung der Spezifikation möglich ist. Der Anforderungsingenieur in der frühen Phase steht damit stellvertretend für alle eher informell ausgerichteten Anforderungsbearbeiter. Seine Anforderungen an die Dokumentation der Spezifikation lassen sich unter den Schlagworten „Verständlichkeit“, „Flexibilität“ und „Systematik“ zusammenfassen.
- Der Anforderungsbearbeiter (Schlagwort: Verwalter), dessen Hauptaufgabe darin liegt, die Anforderungen zu konsolidieren und zu verwalten und die Spezifikation den anderen 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 (insbesondere Vollständigkeit und Konsistenz) unterstützt. In der Praxis werden Anforderungen 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 Anforderungsbearbeiter 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, Architekturen, 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 stellvertretend 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 verbunden. Diese Anforderungen an die Dokumentation der Spezifikation lassen sich unter dem Schlagwort „Durchgängigkeit“ zusammenfassen. Da in der Automobilindustrie 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 Anforderungen, der alle drei Aspekte berücksichtigt : Entweder werden die Anforderungen überhaupt nicht formalisiert, was zu erheblichen Schwierigkeiten bei der Qualitätssicherung der Anforderungen führt. Oder es werden die Anforderungen formalisiert, ohne dabei die Notwendigkeit 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 verschiedenen Anforderungswerkzeugen wie DOORS oder REQUISITEPRO oder CALIBERRM [DO07, CA07, RQ07]. Die beiden Screenshots in Abbildung 6 und Abbildung 7 zeigen, wie Anforderungen in der Praxis mit Toolunterstützung bestenfalls erfasst werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Anforderungsverwaltung am Beispiel von CALIBERRM

Abbildung in dieser Leseprobe nicht enthalten

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 loan…“, 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 Formalisierungsmethodik geht einen Schritt weiter, indem sie auch die Anforderungsbeschreibungen 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
- verständlich und flexibel sein, sodass informell denkende Menschen wie beispielsweise Marketing oder Werkstattpersonal ihre Anforderungen effektiv einbringen und validieren können.
- formal und präzise sein, sodass eine hohe Qualität erzielt und die Analyse und Qualitätssicherung (bezüglich Konsistenz, Korrektheit und Vollständigkeit) erleichtert wird.
- zum Design durchgängig sein, sodass die dokumentierten und qualitätsgesicherten 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 Anforderungen wie „Freude am Fahren“ und sehr konkrete Anforderungen wie „Das Steuergerät darf nicht mehr als 256KB Speicher benötigen“). Dies liegt natürlich zum Teil begründet in der Heterogenität der Stakeholder, die die Anforderungen einbringen.
- Menge von Anforderungen. Bei hinreichend komplexen Systemen, wie sie in Fahrzeugen 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 Anforderungsbeschreibung (informell oder formal, Text oder Grafik) muss bei der Dokumentationsform 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 Anforderungsmanagement 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; dadurch können unter Umständen dramatisch mehr Anforderungen anfallen (siehe ausführliche Diskussion im Kapitel 9). Damit diese überhaupt systematisch erarbeitet werden und damit effektiv gehandhabt werden können, ist es notwendig, die Anforderungen entsprechend zu strukturieren. Da durch die Formalisierung besonders die Preconditions einer Anforderung wachsen, muss eine Strukturierung anhand dieser Vorbedingungen 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 Anforderungsmuster (sozusagen der „Satzbau“) angeordnet werden: Formulierung.
- strukturiert und vervollständig werden. Dies soll zum einen innerhalb einzelner Anforderungen geschehen (durch Anforderungsmuster werden die Elemente der Anforderungen strukturiert und gegebenenfalls gemäß den in dem Muster vorgesehenen Platzhaltern 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 Design wird erreicht durch den Bezug auf ein Modell eingebetteter Systeme, das sowohl dem Anforderungsmanagement als auch dem Design zugrunde liegt, aber in unterschiedlichen, jeweils für die Aufgabe angemessenen Detailtiefen und Formalisierungsgraden 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 fehlertolerant 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 Vollstä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 Anforderungsbestandteilen 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 korrespondierende 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 Dokumentation von Anforderungen hier erarbeiteten Datenstrukturen und Aktivitäten der Formalisierungsmethodik 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 wissenschaftlichen Beitrag für die Forschungsgemeinde im Requirements Engineering:

- 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 bestimmte Eigenschaften der Anforderungen (insbesondere Konsistenz, Vollständigkeit, Übersichtlichkeit, Verständlichkeit, Präzision) steigert und die entsprechenden konstruktiven und analytischen qualitätssichernden Maßnahmen gezielt unterstützt; dies wird im Laufe dieser Arbeit durch die begleitenden Fallstudien immer wieder demonstriert. Der zweite praktische Nutzen dieser Arbeit liegt darin, dass den Anforderungsingenieuren eine systematische, pragmatische und leicht erlernbare Methode zur Formalisierung an die Hand gegeben wird, die aus einfach durchführbaren Einzelschritten besteht und die sich an den Bedürfnissen der beteiligten Stakeholder orientiert.
- Der wissenschaftliche Wert dieser Arbeit liegt darin, dass hier erstmals die systematische Auflösung des Interessenskonflikts der verschiedenen Stakeholder bei der Anforderungsdokumentation konsequent in den Mittelpunkt der Entwicklung einer neuen Darstellungsform für Anforderungen gestellt wurde (und nicht nur eine Stakeholdergruppe berücksichtigt wurde). Dieser Interessenskonflikt besteht zwischen dem Wunsch nach einer möglichst freien Notation (die eine kreative Anforderungserarbeitung fördert), einer möglichst strukturierten Darstellung (die eine systematische Anforderungserarbeitung, Vollständigkeit und Konsistenz fördert) und einer möglichst formalen Notation (die eine präzise Anforderungsdokumentation und einen leichten Übergang ins Design fördert). Wie im Kapitel 14 (Vergleich ähnlicher Arbeiten) erläutert wird, berücksichtigen die meisten bislang existierenden Ansätze nur einen Teil dieser Wünsche. Im hier nun vorliegenden Ansatz wurden die unterschiedlichen Anforderungen der Stakeholder 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 Anforderungsdokumentation entwickelt wurden (die eine präzise und zu den Designmodellen durchgängige Anforderungsdokumentation ermöglichen), andererseits aber angemessene informelle Darstellungsformen 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 Requirements Engineering ein wichtiges Problemfeld) verkleinert und vorverlagert werden: Durch den nahtlosen Übergang zum Design ist die Lücke nun nicht mehr zwischen Anforderungen und Design, sondern liegt innerhalb des Anforderungsmanagements, innerhalb des Prozesses der schrittweisen Formalisierung, wie er in der vorliegenden Arbeit 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 Fallstudie demonstriert.

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 vorgestellt 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 Verlauf 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 analysiert und formal definiert. Auf diesem Modell aufbauend wird eine geeignete Darstellungsform 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 Fallstudie wird die Anwendbarkeit und der Nutzen der Formalisierungsmethodik demonstriert. Zunächst werden im Schritt Klassifikation Anforderungen klassifiziert, um zu entscheiden, 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 standardisiert 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 Formalisierungsmethodik 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.

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 diskutiert, und es wird dargestellt, worin der Mehrwert der vorliegenden Arbeit besteht. Die Arbeit wird noch einmal zusammengefasst und im Ausblick wird die weitere Perspektive dieser Arbeit skizziert: Ausarbeiten der Formalisierung für weitere Anforderungstypen, Vorverlagerung der modellbasierten Formalisierung zu einer modellbasierten Erhebung 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 einfach 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.

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 modellbasierten Entwicklung: die Methodik hat den Anspruch, Anforderungen modellbasiert zu formalisieren und einen einfachen Übergang zu einem modellbasierten Design herzustellen. 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 entwickelndes 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 Requirements Engineering findet sich beispielsweise in [Poh96] und [Par98].

Innerhalb des Entwicklungsprozesses ist der Anforderungsmanagementprozess für die Erarbeitung, Analyse, Dokumentation, Qualitätssicherung und Bereitstellung der Anforderungen verantwortlich [VH+03]. Ziel des Anforderungsmanagementprozesses ist es, mit möglichst geringem 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 Stakeholder entsprechen sollen ),
- Konsistenz (die Anforderungen sollen sich nicht widersprechen),
- Vollständigkeit (es sollen alle relevanten Aspekte des zu entwickelnden Systems beschrieben werden),
- Änderbarkeit (es soll leicht möglich sein, einzelne Anforderungen zu finden und zu ändern; 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 ihre Begründung nachzuvollziehen; oft wird dies mit Attributen wie „Autor“ oder „Quelle“ 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 missverstanden werden können),
- Umsetzbarkeit (eine Anforderung muss sich tatsächlich umsetzen lassen können),
- 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 folgenden 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 Anforderungen 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 Konkurrenzprodukten, Einbeziehung von Gesetzestexten und Normen oder Prototyping erreicht (siehe beispielsweise 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 herausgesucht 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 Anforderungsmengen darf die Übersicht nicht verloren gehen (Strukturierung, Modularisierung), auch relevante Beziehungen zwischen Anforderungen müssen dokumentiert werden (horizontales Tracing). In der Praxis werden Anforderungen zumeist als strukturierte 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 werden (ob sie den tatsächlichen Wünschen und Bedürfnissen der Stakeholder entsprechen), 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 ) sichergestellt.
- 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 gemacht. Zum anderen fällt auch das Umsetzungsmanagement in diesen Aufgabenbereich; hier wird (zum Beispiel durch vertikales Tracing) verfolgt, wie und wie weit die jeweiligen Anforderungen in Design und Implementierung umgesetzt wurden.

Einen Überblick über aktuelle Forschungsaktivitäten in diesen Aufgabenfeldern des Requirements Engineering finden sich in [Zav97], [NE00] und [Lam00]. Die in dieser Arbeit vorgestellte 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 Kapitel 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 Modellbasierung auch im Requirements Engineering immer attraktiver [Par98, FG+04a] – sowohl die modellbasierte Erarbeitung von Anforderungen als auch die für diese Arbeit relevante modellbasierte 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 Anforderungsmanagement 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 darauf) gezielter und systematischer abgefragt werden können.
- besser dokumentiert werden, da für die relevanten Informationen spezifische Dokumentationsformen 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 Anforderungsinhalte ü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äzisere, 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 = {vi|i  IN  …“). Im Kapitel 5 wird das den Nutzeranforderungen zugrundeliegende Modell eingebetteter Systeme explizit gemacht und formal definiert.
- Steht das Modell fest, so gibt es in der Regel eine Reihe von alternativen Darstellungsformen für das Modell. Ein Zustandsmodell kann beispielsweise graphisch oder in Tabellenform oder als freier Text dargestellt werden. Im Kapitel 6 wird eine für das Anforderungsmanagement geeignete Darstellungsform definiert.
- Steht das Modell fest und ist eine geeignete Darstellungsform definiert, so ist die Aufgabe 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, entwickelt.

Um eine Durchgängigkeit zum Design zu erreichen, liegt sowohl dem Anforderungsmanagement 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 Teilprozessen möglich (Durchgängigkeit); dadurch, dass beide Teilprozesse dieses Systemmodell in jeweils angemessener Detailtiefe und Formalisierungsgrad benutzen, kann das Modell die jeweiligen 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 Anforderung verstanden (ohne dabei ihren Inhalt zu verändern ), sodass ein zunächst natürlichsprachiger freier Text immer mehr Regeln genügen muss, und immer mehr auf seine wesentliche Aussage komprimiert wird. Diese Regeln beziehen sich insbesondere auf den zur Verfügung stehenden 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 Anforderung angeordnet werden müssen, und welche Elemente in einem Muster optional oder obligatorisch sind.

Diese Regeln leiten sich aus einem zugrundeliegenden Modell ab; dieses Modell wird im Kapitel 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 Formalisierung 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).
- Zweitens wird es möglich, durch Reduktion von Interpretationsfreiheiten Anforderungen sehr präzise zu formulieren (im Gegensatz zu natürlichsprachigen Formulierungen, die inhärent anfällig für Missverständnisse sind [Rup01, Sch98]).
- Drittens ist eine Vereinheitlichung der Form einer Anforderung auch ein Mittel, um inhaltliche 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 überführt oder zumindest mit ihnen verknüpft werden kann).
- Fünftens ist eine Formalisierung Grundlage für eine weiterreichende Werkzeugunterstützung (so sind bei geeigneten Formalismen automatische oder zumindest halbautomatische 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 Anforderungen 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 ).

Die Formalisierung von Anforderungen muss nicht notwendigerweise bedeuten, dass dadurch die Anforderungen dem Design angenähert werden und die Durchgängigkeit zum Design erleichtert wird; in der Praxis aber sind die meisten Formalisierungsansätze inzwischen auf ein bestimmtes Designparadigma ausgerichtet, weil sich ohne eine solche Durchgängigkeit der Formalisierungsaufwand 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 Beschreibungssprache 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 Gesamtsystems sehr wichtig sind. Ihre Aufgabe besteht darin, eine Anzahl technischer Geräte und physikalischer Prozesse der Umgebung mittels Sensoren zu überwachen und/oder gemäß einer definierten 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 ; 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 zusammengefasst:

- 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 haben eingebettete Systeme in der Regel kein eigenes Nutzerinterface, sondern werden über das Interface des Gesamtsystems bedient.
- Komplexe Systemumgebung: Eingebettete Systeme agieren in einer komplexen Umgebung, die aus Sensoren und Aktuatoren, sowie aus einer Vielzahl von anderen eingebetteten Systemen besteht.
- Parallelität, Echtzeit, Kritikalität: Eingebettete Systeme werden oft in sicherheitskritischen 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 beispielsweise 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 explizit 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 Fallstudien aus dem Automotive-Bereich stammen. Daher lässt sich zunächst keine Allgemeingü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 Entscheidungsfreiraumes eingebettete Systeme für das Gesamtsystem entwickeln.
- Hohe Stückzahl: Eingebettete Systeme für Fahrzeuge sind keine Individualentwicklungen, sondern werden meist in hoher Stückzahl hergestellt.
- Variantenvielfalt: Die Variantenvielfalt bei den Fahrzeugen (beispielsweise Fahrzeugreihen, Ausstattungsvarianten) spiegelt sich auch in der Variantenvielfalt bei eingebetteten Systemen wider. Dadurch wird die systematische Wiederverwendung von Anforderungen 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 Engineering“, das heißt, dass voneinander abhängige Systeme parallel entwickelt werden.
- Große Anforderungsmenge: Die Komplexität der Fahrzeuge und die vielfältigen Abhä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 Systeme (beispielsweise trifft „Hohe Stückzahl“ sowohl auf Fahrzeuge als auch Handys zu), andere wiederum unterscheiden sich (beispielsweise trifft der Aspekt „Hoher Anteil an Fremdentwicklung“ nicht auf Handys zu). Dennoch kann der in dieser Arbeit betrachtete Teil des Anforderungsmanagements, 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 Arbeiten (siehe Ausblick).

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 angewendet und gemeinsam mit Industriepartnern evaluiert. Damit eine so entwickelte Methodik 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 Fahrerassistenzsystem „Adaptive Cruise Control“ (BMW) und ein Türsteuergerät (DaimlerChrysler).

3.1 Vorarbeiten

Diese Arbeit basiert neben dem Fachwissen im Bereich modellbasierter Entwicklung eingebetteter 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 Requirements 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 lediglich 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 allgemeingü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 AUTORAID, [AR07], das mittlerweise in das modellbasierte Entwicklungswerkzeug AUTOFOCUS [AF07] integriert wurde.

Projektbeteiligt war nur die TU München (Andreas Fleischmann, Eva Geisberger, Markus Pister).

- Mobilsoft (12/04 bis 06/07): Im Teilprojekt „Anforderungsmanagement“ im bayerischen Forschungsverbund wurde neben mehreren anderen Arbeitspaketen vom Autor eine Methodik zur schrittweisen Formalisierung von Anforderungen innerhalb des Requirements Engineering Prozesses erarbeitet [Fle07b], deren Weiterentwicklung in der vorliegenden Arbeit dokumentiert ist.

Projektbeteiligte waren neben der TU München (Andreas Fleischmann, Judith Hartmann, Martin Rappl, Sabine Rittmann, Doris Wild) die beiden bayerischen Automobilhersteller 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 Herausforderungen für ein Requirements Engineering für eingebettete Systeme [FG+04a, FG+04c] herausgearbeitet. 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 wurde im Verlauf des Projektes Mobilsoft und darüber hinausgehend die vorliegende Formalisierungsmethodik 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 vorgestellten Formalisierungsmethodik wurde in den Jahren 2005 bis 2007 im Projekt Mobilsoft entwickelt; dabei war die Methodik Bestandteil eines Arbeitspaketes, das in der alleinigen Verantwortung des Autors lag und von ihm alleine inhaltlich vorangetrieben und bearbeitet wurde – unter Rückgriff auf die bei den jeweiligen Meilensteinen durchgeführten Diskussionen, Feedbacks 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 sowohl 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 repräsentativ für die betrachtete Domäne sind. Ansonsten würden für Rand¬er¬schei¬nungen 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 Fallstudien 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 Automobilzulieferer 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 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 Validierung der Methodik, also der Abgleich von Anspruch und Wirklichkeit, wird wie folgt durchgeführt:

- Die praktische Anwendbarkeit wurde anhand verschiedener Fallstudien aus der Praxis erprobt, von denen zwei in dieser Arbeit dokumentiert sind (siehe Abschnitt 3.3). Insbesondere die Durchführung der Fallstudie „Abstandsgeregelter Tempomat“ (Abschnitt 3.3.1) wurde im Projekt Mobilsoft von Industriepartnern kritisch begleitet und in mehreren Iterationen wurde mit Hilfe des Feedbacks der Projektpartner die praktische Anwendbarkeit der Methodik erhöht [Fle07a, Fle07b], einschließlich einer praxistauglichen Integration in einen gesamten Anforderungsprozess [FB+06]. Da die Anwendbarkeit 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 umformulierten 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 Kapitel 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 Abschnitten 7.4, 8.4 und 9.4

3.3 Fallstudien

Die beiden in dieser Arbeit dokumentierten Fallstudien stammen aus der Automobilindustrie und entsprechen dem Stand der heutigen Praxis. In beiden Fällen sind die Anforderungen informell erfasst worden und haben daher viele der typischen Mängel einer informellen Spezifikation, 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 Fallstudien wird im weiteren Verlauf der Arbeit immer wieder die Anwendung der Formalisierungsmethodik 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 Funktionalitäten schematisch dar:

Abbildung in dieser Leseprobe nicht enthalten

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 Fahrzeug 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 Spezifikationsdokument [Bau05], das von der BMW CarIT zur Verfügung gestellt wurde, und das auch als Fallstudie im Projekt Mobilsoft [AI07, Fle07a] diente, durch 27 rein textuelle Anforderungen (Verhaltensregeln) stichpunktartig beschrieben. Man kann dabei folgende Situationen unterscheiden:

- Freies Fahren auf gerader Strecke oder in einer Kurve, bei normalen oder bei erschwerten 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]:

Freies Fahren: Kein Objekt im Fahrschlauch

1. Fahren auf Gerade ohne Objekt: komfortabel beschleunigen, bis Wunschgeschwindigkeit erreicht, dann Wunschgeschwindigkeit halten
2. Verlassen der Kurve ohne Objekt: erst langsam beschleunigen, dann mehr, bis Wunschgeschwindigkeit erreicht, dann Wunschgeschwindigkeit halten
3. Fahren in Kurve ohne Objekt: langsam beschleunigen oder verzögern, bis komfortable Querbeschleunigung erreicht
4. Kurz nach Objektverlust in Kurve und Wunschgeschwindigkeit noch nicht erreicht: zuerst konstant weiterfahren, dann ganz langsam beschleunigen bis komfortable Querbeschleunigung erreicht
5. Kurz nach Objektverlust auf Gerade und Wunschgeschwindigkeit noch nicht erreicht: zuerst nicht beschleunigen, dann komfortabel beschleunigen bis Wunschgeschwindigkeit erreicht
6. Kurz nach Objektverlust und Blinker Rechts gesetzt: Geschwindigkeit halten, da möglicherweise Autobahnausfahrt
7. Kurz nach Objektverlust bei höherer Geschwindigkeit und Blinker Links gesetzt: Beschleunigen, da möglicherweise Überholvorgang durchgeführt wird
8. Kurz nach Objektverlust und Gaspedal vom Fahrer betätigt: zügig beschleunigen
9. Annähern an Kurve voraus: frühzeitig verzögern, so dass bei Kurveneintritt komfortable Kurvengeschwindigkeit erreicht wird
10. Bremspedal vom Fahrer betätigt: ACC ausschalten
11. Gaspedal vom Fahrer betätigt: ACC inaktiv, nach Loslassen des Gaspedals Übergang in Wunschgeschwindigkeit komfortabel gestalten
12. glatte Fahrbahn oder geringe Sichtweite: Wunschgeschwindigkeit anpassen, nur wenig beschleunigen
13. bei Veränderung der Wunschgeschwindigkeit durch Fahrer: komfortabel beschleunigen oder verzögern, bis neue Wunschgeschwindigkeit erreicht
Folgefahren: Objekt im Fahrschlauch
14. Gut erkanntes Objekt in der Nähe des Sollabstandes: Sollabstand halten, höchstens jedoch mit Wunschgeschwindigkeit fahren und nur komfortabel beschleunigen
15. Altes Objekt, näher als Sollabstand: deutlicher verzögern
16. Neues, etwa gleich schnelles Objekt, näher als Sollabstand: langsam Sollabstand wieder aufbauen
17. Neues, deutlich langsameres Objekt, näher als Sollabstand: verzögern, um Kollision zu vermeiden, jedoch nicht stärker als ca. -0.2g
18. Neues, schnelleres Objekt, näher als Sollabstand: gleichmäßig weiterfahren und ggf. Sollabstand aufbauen
19. Neues, deutlich langsameres Objekt, weiter als Sollabstand: konstant verzögern, jedoch nicht stärker als ca. -0.2g, bis Sollabstand erreicht, möglichst wenig „eintauchen“, danach Sollabstand halten
20. Neues, nur wenig langsameres Objekt, weiter als Sollabstand: mit geringer, konstanter Relativgeschwindigkeit annähern, dann aperiodisch in Sollabstand übergehen, danach Sollabstand halten
21. Neues, schnelleres Objekt, weiter als Sollabstand und Wunschgeschwindigkeit noch nicht erreicht: wie bisher weiterfahren, bis ggf. „neues, nur wenig langsameres Objekt, weiter als Sollabstand“ gilt.
22. Altes Objekt und Blinker Links gesetzt bei höherer Geschwindigkeit: Sollabstand etwas verkürzen, da möglicherweise Überholabsicht vorliegt
23. Altes Objekt und Fahren in Kurve: konstant folgen, aber nur langsam beschleunigen oder verzögern, komfortable Querbeschleunigung nicht überschreiten
24. Altes Objekt und glatte Fahrbahn oder geringe Sichtweite: Abstand etwas vergrößern, Wunschgeschwindigkeit anpassen, nur wenig beschleunigen
25. Im Stop&Go-Verkehr: gleichmäßig und langsam fahren, nur wenig beschleunigen
26. Bremspedal vom Fahrer betätigt: ACC ausschalten
27. Gaspedal vom Fahrer betätigt: ACC inaktiv, nach Loslassen des Gaspedals Übergang in Sollabstand sicher oder komfortabel gestalten

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 Wunschgeschwindigkeit komfortabel gestalten

Und es finden sich undefinierte Begriffe, wie hier beispielsweise „Wunschgeschwindigkeit anpassen“:

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 formuliert werden, sondern auch viele Inkonsistenzen und Unvollständigkeiten systematisch ausgerä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 ) 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 beschrieben, 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 Sitzes.
- Türschloss: Auf- und Zuschließen des Fahrzeugs über Schlüssel, Funksender oder Controller 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 Aussteigen.
- 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.

Abbildung in dieser Leseprobe nicht enthalten

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:

Abbildung in dieser Leseprobe nicht enthalten

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 Hardwarebauteile und Steckerelemente spezifiziert; dabei werden zur Spezifikation informelle Grafiken, Tabellen und Fließtext benutzt. Dadurch bietet diese Fallstudie ein breites Spektrum (bezüglich Inhalt, Form und Strukturierung) an Anforderungen.

Teil II Formalisierungskonzept

4. Auswahl der zu formalisierenden Anforderungen

Um angesichts der großen Heterogenität der Anforderungen Formalisierungsmethoden definieren zu können, die konkret genug sind, um tatsächlich anwendbar zu sein, beschränkt sich diese Arbeit auf eine prominente Teilmenge von Anforderungen, die Klasse der funktionalen Nutzeranforderungen. Grundlage für diese Auswahl ist eine formalisierungsspezifische Klassifikation aller Anforderungen; die unter einer Vielzahl möglicher Klassifikationen gewählte inhaltlich orientierte Klassifikation in Prozess-, Geschäfts-, Nutzer- und Systemanforderungen ist für die Formalisierung gut geeignet, weil die Inhalte über alle Formalisierungsschritte hinweg grundsätzlich unverändert bleiben, und weil so auf den Klassifikationen in Elicitation und Design, die üblicherweise ähnlich inhaltsorientiert sind, aufgebaut werden kann.

4.1 Notwendigkeit einer formalisierungsspezifischen Klassifizierung

Die Menge der Anforderungen, die heutzutage ein System beschreiben, ist sowohl bezüglich des Inhalts als auch bezüglich der Form sehr heterogen. So gibt es beispielsweise

- sehr allgemeine Anforderungen („Freude am Fahren“) und sehr konkrete Anforderungen („Dem System stehen nicht mehr als 20kB Arbeitsspeicher zur Verfügung“),
- ausformulierte textuelle Anforderungen und Grafiken oder Tabellen,
- Anforderungen, die sich direkt auf das Produkt beziehen, und solche, die sich auf den Entwicklungsprozess beziehen.

Die Vielfalt und Heterogenität der Anforderungen an komplexe eingebettete Systeme liegen darin begründet, dass Anforderungen vielfältige Aspekte eines Systems auf unterschiedlichen Abstraktionsebenen beschreiben müssen.

Vor dem Hintergrund dieser großen Heterogenität hat es sich bewährt, Anforderungen je nach aktuell anstehender Aufgabe zunächst entsprechend zu klassifizieren, um sie dann, abhängig von ihrer Klasse, spezifisch weiterbearbeiten zu können. Dies trifft auch auf die Aufgabe der Formalisierung von Anforderungen zu: Angesichts der großen Heterogenität der Anforderungen und der Tatsache, dass diesen Anforderungen zum Teil sehr unterschiedliche Denkmodelle zugrunde liegen, können nur dann Formalisierungsmethoden definiert werden, die konkret genug sind, um tatsächlich anwendbar zu sein, wenn die Anforderungen in geeignete formalisierungsspezifisch homogene Klassen zerlegt wurden. Eine für die Aufgabe der Formalisierung geeignete Klassifikation soll die Menge der informell vorliegenden Anforderungen partitionieren, um für jede Partition spezifische Formalisierungsregeln angeben zu können, die konkreter und hilfreicher sind als allgemeine Regeln, die für alle Anforderungen gelten müssten. Es muss also eine speziell für die Formalisierung gut geeignete Anforderungsklassifikation gefunden werden.

4.2 Kriterien für eine formalisierungsspezifische Klassifizierung

Der Vielfalt von Aufgaben im Requirements Engineering entsprechend gibt es bereits eine Vielzahl von Klassifikationen von Anforderungen. Beispielsweise finden sich in der Literatur und Praxis [SS97][Som01][VH+03] Klassifikationen :

- bezüglich ihrer Priorität

(zum Beispiel: hoch, niedrig)

- bezüglich ihrer Verbindlichkeit

(zum Beispiel: obligatorisch, optional)

- bezüglich ihrer Reife

(zum Beispiel: initial, abgestimmt, zurückgewiesen)

- bezüglich ihrer Quelle

(zum Beispiel: Kunden, Nutzer, Marketing)

- bezüglich ihrer Form

(zum Beispiel: Text, Grafik, Tabelle)

- bezüglich ihrer Formalität

(zum Beispiel: informell, semiformal, formal)

- bezüglich ihres Abstraktionsgrades

(zum Beispiel: Business Requirements, Usage Requirements , System Requirements)

- bezüglich ihres Bezugobjekts

(zum Beispiel: Fensterheberanforderungen, Türschlossanforderungen)

- bezüglich ihres Bezugsobjekttyps

(zum Beispiel: Produktanforderungen, Prozessanforderungen)

- bezüglich ihres Inhaltstyps

(zum Beispiel: nichtfunktionale Anforderungen, funktionale Anforderungen)

Von den vorgenannten zehn Klassifikationen sind die ersten vier eher organisatorisch begründet (Priorität, Verbindlichkeit, Reife, Quelle), die nächsten zwei eher syntaktisch begründet (Form, Formalität) und die letzten vier eher semantisch (inhaltlich) begründet (Abstraktionsgrad, Bezugsobjekt, Bezugsobjekttyp, Inhaltstyp).

Die für die Formalisierung wesentlichen Eigenschaften einer Anforderung sind ihre Semantik (die inhaltliche Aussage der Anforderung, die durch die Formalisierung grundsätzlich unverändert bleiben soll ) und ihre Syntax (die Form, in der die Anforderung aufgeschrieben wurde, die durch die Formalisierung verändert werden soll). Daher kommen für die Formalisierung zwei Klassifikationen in Frage:

- Syntax: Die Klassifikation der Anforderungen anhand der Form einer Anforderung (beispielsweise Unterscheidung, ob eine Anforderung als Text, Grafik, Tabelle oder Use-Case vorliegt). Die Formalisierung verändert die Form einer Anforderung, dabei spielt die Ausgangsform einer Anforderung eine wichtige Rolle; für eine Grafik müssen andere Formalisierungsmethoden angegeben werden als für eine Tabelle oder für einen freien Text.
- Semantik: Die Klassifikation anhand des Inhalts einer Anforderung. Hier kann beispielsweise unterschieden werden, ob es sich um Prozess- oder Produktanforderungen handelt; Produktanforderungen können wiederum unterschieden werden in Geschäfts-, Nutzer- und Systemanforderungen. Die Klassifikation nach diesem Gesichtspunkt ist sinnvoll, da die Formalisierung den Inhalt nicht verändern soll, der Inhalt der Anforderung also über alle Formalisierungsschritte hinweg gleich bleibt und somit eine Art Invariante im Formalisierungsprozess einer Anforderung darstellt.

In dieser Arbeit wird primär eine Klassifikation entlang der Inhalte einer Anforderung vorgenommen: für gleichartige Inhalte wird jeweils eine eigene Klasse definiert, für die die jeweils geeigneten Formalismen und Formalisierungsmethoden angegeben werden. Zum einen ist die Form einer Anforderung nur in den ersten Formalisierungsschritten ein wichtiger Faktor, da die Form bald durch die fortschreitende Formalisierung angeglichen werden soll. Zum anderen wird in den parallelen und späteren Bearbeitungsschritten in der Elicitation und im Design ebenfalls primär nach den Anforderungsinhalten klassifiziert. Denn bei der Entscheidung, wie nun konkret nach Inhalten klassifiziert werden soll, sind – neben der Eignung für die Formalisierung – zwei weitere Faktoren zu berücksichtigen:

4.2.1 Durchgängigkeit zur Klassifikation im Design

Die Anforderungsklassifikation soll sich zugunsten der Durchgängigkeit gut mit den Modellierungsebenen des Designs verknüpfen lassen. Unter den vielen möglichen Modellierungstechniken im Design wurden für diese Arbeit als Repräsentant die Modellierungsebenen der CAR-DL [HR+07] aus dem Projekt Mobilsoft gewählt, da dieser modellbasierte Ansatz einer der neuesten Ansätze ist, der aufbauend auf der EAST-ADL [Lön04] und in Zusammenarbeit mit führenden Automobilherstellern gezielt für die in dieser Arbeit betrachtete Domäne von eingebetteten Softwaresystemen in Fahrzeugen entwickelt wurde. Dieser Ansatz untergliedert das Design anhand inhaltlicher Kriterien in die folgenden Klassen:

- Nutzungsebene: Auf dieser Ebene wird das Verhalten des zu entwickelnden Systems auf einem sehr hohen Abstraktionsniveau formal beschrieben. Das System wird dabei als Black-Box behandelt, das auf und mit logischen Reaktionen mit seiner Umwelt interagiert (vgl. gemeinsames Systemmodell im Kapitel 5). Das hohe Abstraktionsniveau der Verhaltensbeschreibung und die Reduktion der Umwelt auf nur einen einzigen Datentyp (logische Aktion) soll „die Darstellung der Beziehungen zwischen System und Umwelt vereinfachen“ [HR+07].
- Funktionsebene: „Nachdem in der Nutzungsebene formal und eindeutig dargestellt wurde, was das System leisten soll, wird in der Funktionsebene bestimmt, wie dieses Verhalten erbracht werden kann. Dazu gehört neben der Entwicklung der Algorithmen auch die Entscheidung, welche Daten aus der Umwelt notwendig sind, um das gewünschte Verhalten zu erbringen. Zusätzlich wird hier die funktionale Struktur […] des Systems festgelegt“, also das System als ein „Netz von hierarchischen, kommunizierenden Funktionen“ dargestellt [HR+07].
- Clusterebene: Auf dieser Ebene wird das in der Funktionsebene modellierte System zu Clustern partitioniert. Jeder Cluster stellt eine abgeschlossene Einheit mit definierten Kommunikationsschnittstellen nach außen dar.
- Plattformebene: Auf dieser Ebene wird die Hardware miteinbezogen, es werden Steuergeräte, Aktuatoren und Sensoren, sowie deren Eigenschaften eingeführt, sofern sie für die Einbettung der Softwareanteile relevant sind.

4.2.2 Durchgängigkeit zur Klassifikation der Elicitation

Die formalisierungsspezifische Anforderungsklassifikation soll sich zugunsten einer engen Integration mit den anderen Teilprozessen des Requirements Engineering gut mit den Anforderungsebenen der Elicitation verbinden lassen. Diese Anforderungsebenen verfolgen zum einen das Ziel, große Anforderungsmengen übersichtlich darzustellen, zum anderen werden mit ihrer Hilfe systematisch Anforderungen abgeleitet. Es gibt eine Vielzahl solcher Anforderungsebenen [SS97, Som01], zum Teil auch speziell auf den Automotive Bereich zugeschnittene [VH+03, AI+07]; fast allen gemeinsam ist die grundsätzliche Klassifizierung in die folgenden Ebenen:

- Geschäftsanforderungen (Business Requirements)
- Nutzeranforderungen (User Requirements)
- Systemanforderungen (System Requirements)

4.2.3 Spezifische Eignung für die Formalisierung

Vor allem aber muss die formalisierungsspezifische Klassifikation zugunsten einer effektiven Formalisierung genau die Anforderungen in einer Klasse zusammenfassen, die sich mit ähnlichen Datenstrukturen und Aktivitäten bearbeiten lassen. Dazu wurden repräsentative Anforderungsmengen (siehe Fallstudien, Kapitel 3.3) und die Spezifika eingebetteter Systeme analysiert [FG+04a] und das verwendete Systemmodell (siehe Kapitel 5) berücksichtigt. Einflussfaktoren für formalisierungsspezifische Klassifikation, die aus der Analyse dieser Anforderungen kommen, sind:

- Form: Da durch die Formalisierung die Darstellungsform der Anforderungen verändert wird, ist die Ausgangsform der Anforderungen ein Faktor, der berücksichtigt werden muss.
- Inhalt: Die Formalisierung verändert zunächst die Form der Anforderungen; die rein formale Präzisierung und Vervollständigung der Anforderungen führt allerdings in den meisten Fällen zu einer (erwünschten) inhaltlichen Präzisierung und Vervollständigung der Anforderungen.
- Modell: Da die Formalisierung auf dem den Anforderungen zugrundeliegenden Denkmodell aufbaut, muss den Anforderungen, die in einer Formalisierungsklasse zusammengefasst sind, dasselbe Denkmodell zugrunde liegen.

Auf Grundlage dieser Kriterien – Durchgängigkeit zum Design, Durchgängigkeit zur Elicitation, Eignung für die Formalisierung – wurde im Rahmen dieser Arbeit eine Klassifikation entwickelt und verwendet, die im folgenden Abschnitt 4.3 vorgestellt wird.

4.3 Definition der formalisierungsspezifischen Klassifizierung

Entsprechend der im vorangegangenen Abschnitt erläuterten Kriterien wurde für diesen Ansatz der Formalisierung die Klassifizierung in die folgenden vier Klassen vorgenommen:

- Prozessanforderungen: Diese Anforderungen beschreiben das zu entwickelnde System als Gegenstand eines Entwicklungsprozesses. Es wird beschrieben, wie das zu entwickelnde System entwickelt werden soll. Es werden Vorgaben an den Entwicklungsprozess gestellt, die entweder individuell für das zu entwickelnde System gelten, oder sich aus Landesgesetzen oder Firmenregelungen ergeben.
- Geschäftsanforderungen: Diese Anforderungen beschreiben das zu entwickelnde System als Produkt. Beschrieben wird nicht, was das zu entwickelnde System tun muss, sondern warum es dies tun muss. Es wird beschrieben, welche strategischen oder finanziellen Ziele mit diesem Produkt verfolgt werden. Es wird der Markt beschrieben, für den dieses Produkt entwickelt wird, und wie es in diesen Markt hineinpassen soll.
- Nutzeranforderungen: Diese Anforderungen beschreiben das zu entwickelnde eingebettete System aus der Perspektive des Nutzers des Gesamtsystems (also auf logischer Abstraktionsebene und aus Black-Box-Perspektive) als eine Teilmenge von Diensten (Verhaltensmuster), die das Gesamtsystem erbringt. Es wird beschrieben, wie das System auf bestimmte Reize von außen reagiert (funktionale Anforderungen), und welche Eigenschaften diese Reaktionen haben (nichtfunktionale Anforderungen).
- Systemanforderungen: Diese Anforderungen beschreiben das zu entwickelnde eingebettete System als Teil eines Gesamtsystems aus der White-Box-Perspektive. Hier werden die Schnittstellen des eingebetteten Systems beschrieben: die Hardwarebauteile, mit denen es interagiert, die Signale, mittels denen es mit seiner Umwelt interagiert, sowie die relevante Hardware- und Softwarearchitektur des eingebetteten Systems und seiner Umgebung. Das Verhalten des Systems sollte durch die Nutzeranforderungen bereits weitgehend determiniert sein, durch den technischen Blick auf das System können aber auch weitere, detailliertere Verhaltensanforderungen (sowohl funktionale als auch nichtfunktionale) hinzukommen.

Somit werden Anforderungen mit ähnlichen inhaltlichen Aussagen in gleiche Klassen einsortiert, für die dann später spezifische Formalismen und Formalisierungsmethoden angegeben werden können. In den folgenden Abschnitten 4.3.1 bis 4.3.4 werden diese vier Formalisierungsklassen im Detail vorgestellt. Im darauf folgenden Abschnitt 4.4 wird auf die Konsequenzen dieser Klassifikation eingegangen, dabei unter anderen auch, inwiefern diese Klassifikation die in Abschnitt 4.2 diskutierten Kriterien erfüllt.

4.3.1 Prozessanforderung

Definition

Prozessanforderungen beschreiben das zu entwickelnde System als Gegenstand eines Entwicklungsprozesses. Es wird nicht beschrieben, was das System tun soll, oder welche Eigenschaften oder welchen Nutzen es hat, sondern es wird beschrieben, wie das System entwickelt werden soll. Es werden also Vorgaben an den Entwicklungsprozess gestellt, die entweder individuell für das zu entwickelnde System gelten, oder sich aus Landesgesetzen oder Firmenregelungen ergeben [FK+07].

Beispiele

Typische Anforderungen dieser Klasse enthalten Aussagen wie:

- „Zu jeder Anforderung muss mindestens ein Testfall definiert werden, mit welchem die Erfüllung dieser Anforderung getestet werden kann.“
- „Der Treibercode muss verifiziert werden“
- „Die Nutzerfreundlichkeit des Systems muss durch eine Evaluation von Sachverständigen oder durch eine empirische Studie mit nicht weniger als 200 Probanden nachgewiesen werden.“

4.3.2 Geschäftsanforderung

Definition

Geschäftsanforderungen beschreiben nicht, welchen Nutzen das System für den Nutzer bringen soll, sondern, welchen wirtschaftlichen oder strategischen Nutzen das System für den Hersteller des Systems bringen soll, und welche Rahmenbedingungen dafür gelten. Oft wird dabei von einem „Produkt“ statt von einem „System“ gesprochen [FK+07].

Beispiele

Typische Anforderungen dieser Klasse enthalten Aussagen wie

- „Mit diesem Produkt soll der Marktanteil um 10% erhöht werden.“
- „Das Produkt soll auch auf dem asiatischen Mark angeboten werden.“
- „Das System darf nicht mehr als 0,1% des Gesamtpreises des Fahrzeugs kosten.“

Solche Geschäftsanforderungen sind zuweilen nicht explizit als eigene Anforderungen formuliert, sondern implizit in den Begründungen von Anforderungen verborgen:

- „… weil das Produkt sonst nicht auf dem asiatischen Markt vertrieben werden darf.“
- „… um so die Akzeptanz für ältere Nutzer zu steigern.“

4.3.3 Nutzeranforderung

Definition

Nutzeranforderungen beschreiben das zu entwickelnde eingebettete System als eine Teilmenge von Diensten (Verhaltensmuster), die das Gesamtsystem für einen Nutzer (beispielsweise den Fahrer oder andere Systeme) erbringt. Es handelt sich um eine Black-Box-Sicht auf das System aus der Perspektive des Nutzers des Gesamtsystems.

Beispiele

Es wird beschrieben, welche äußeren Reize für das Gesamtsystem relevant sind, beispielsweise eine Auflistung, auf welche und mit welchen Reizen das Gesamtsystem reagiert,

- „Schlechte Wetterverhältnisse bedeutet, dass entweder die Fahrbahn nass ist oder schlechte Sicht herrscht.“

welche Gesetzmäßigkeiten auf diesen Reizen liegen, zum Beispiel, dass ein Fahrzeug nicht gleichzeitig beschleunigen und verzögern kann; oder dass das Gaspedal nicht gleichzeitig gedrückt und gelöst sein kann,

- „Das Fahrzeug kann nicht gleichzeitig beschleunigen und verzögern.“
- „Voraussetzung für das Loslassen des Bremspedals ist, dass es gedrückt ist.“
- „Das ACC ist entweder aktiv oder inaktiv oder ausgeschaltet.“

wie das Gesamtsystem auf bestimmte Reize von außen reagiert (funktionale Anforderungen), beispielsweise, dass das Fahrzeug bei Betätigung des Gaspedals (eingehender Reiz) abbremst (ausgehender Reiz),

- „Wenn ein neues Objekt im Fahrschlauch erkannt wird, dann muss ein Warnton erklingen.“
- „Wenn schlechte Sichtverhältnisse herrschen, dann darf nur noch langsam beschleunigt und gebremst werden.“

und welche Eigenschaften diese Reaktionen haben (nichtfunktionale Anforderungen), beispielsweise, dass ein Warnhinweis visuell sein muss, oder dass eine Reaktion innerhalb einer bestimmten Zeit erfolgen muss.

- „(dann muss) spätestens nach 5ms (ein Warnton erklingen)“
- „Ein Warnton darf nicht länger als 5 Sekunden erklingen.“

Funktionale und Nichtfunktionale Nutzeranforderungen

Im Abschnitt 2.4 auf Seite 30 wurde beschrieben, dass eingebettete Systeme vom Nutzer des Gesamtsystems meist nicht als eigenständiges System wahrgenommen werden, sondern als Teil des Verhaltens des Gesamtsystems, und dabei insbesondere oft repräsentiert durch die entsprechenden Teile des Nutzerinterfaces des Gesamtsystems (zum Beispiel wird die Blinkerfunktionalität meist nicht als Steuergerät im Fahrzeug wahrgenommen, sondern mit den Bedienelementen – Blinkeranzeige, akustisches Blinkersignal, Blinkerhebel – identifiziert).

Daher ist es sinnvoll, die Nutzeranforderungen noch einmal weiter zu klassifizieren in funktionale und nichtfunktionale Nutzeranforderungen:

- Funktionale Nutzeranforderungen beschreiben, wie das System, abhängig von der jeweiligen Situation (zum Beispiel Wetterlage, Verkehrslage) auf bestimmte Reize von außen (zum Beispiel Kurveneinfahrt oder Abbremsen des voranfahrenden Fahrzeugs) reagiert.
- Nichtfunktionale Nutzeranforderungen beschreiben, welche Eigenschaften diese Reaktionen haben. Dies beinhaltet zeitliche Eigenschaften der Reaktionen (Zeitraum, innerhalb dessen eine Reaktion eintreten muss, Dauer einer Reaktion), aber auch viele weitere Eigenschaften wie beispielsweise, ob das Verhalten „Warnen“ als visuelle oder akustische Warnung in Erscheinung tritt.

Die Trennung in funktionale und nichtfunktionale Anforderungen ist nicht immer ganz trennscharf [Gli07]; wichtig ist in diesem Zusammenhang aber, dass viele nichtfunktionale Eigenschaften sich auf das Nutzerinterface beziehen und wenig relevant sind für die Software des Steuergerätes.

4.3.4 Systemanforderung

Definition

Systemanforderungen beschreiben das zu entwickelnde eingebettete System als Teil eines Gesamtsystems. Hier werden die Schnittstellen des eingebetteten Systems beschrieben: die Hard- und Softwarekomponenten, mit denen es interagiert, die Signale, mittels denen es mit seiner Umwelt interagiert, sowie die relevante Hardware- und Softwarearchitektur des eingebetteten Systems und seiner Umgebung. Das Verhalten des eingebetteten Systems ist durch die Nutzeranforderungen bereits zu einem Großteil determiniert, durch den technischen Blick auf das System kommen nun aber auch weitere, detailliertere Verhaltensanforderungen (sowohl funktionale als auch nichtfunktionale) hinzu, insbesondere wenn das eingebettete System auch innerhalb des Gesamtsystems Dienste erbringt, die von außen nicht sichtbar sind.

Beispiele

- In den Systemanforderungen wird die Software- und Hardware-Umgebung des eingebetteten Systems definiert, beispielsweise die Nachbarsysteme, die Sensoren, Busse und Aktuatoren, mit denen das System kommuniziert.
- In den Systemanforderungen werden die technischen Schnittstellen des eingebetteten Systems, über die das System mit seiner Umwelt interagiert, definiert, beispielsweise Ports (auf den einzelnen Steckerverbindungen) und ihre Belegungen, sowie die eingehenden und ausgehenden Nachrichten und Busprotokolle.
- In den Systemanforderungen muss ein Mapping zwischen den auf Nutzerebene definierten Reizen und den technischen Signalen hergestellt werden, also muss beschrieben werden, wie die außerhalb des Gesamtsystems wahrgenommenen und ausgelösten logischen Aktionen zur technischen Schnittstelle des eingebetteten Systems gelangen.
- In den Systemanforderungen werden Reaktionsmuster und ihre Eigenschaften definiert, die das auf Nutzerebene beschriebene Verhalten verfeinern. Dies ist der Fall, wenn das Verhalten sich direkt auf technische Aspekte bezieht, die für den Nutzer nicht sichtbar sind.
- In den Systemanforderungen werden auch Einschränkungen der Hard- und Softwarewarearchitektur des eingebetteten Systems spezifiziert, die sich sowohl auf deren Existenz als auch deren Eigenschaften beziehen.

4.4 Konsequenzen dieser Klassifikation

4.4.1 Verzahnung von Anforderungsmanagement und Design

Mit dieser oben vorgestellten formalisierungsspezifischen Klassifizierung ist eine enge Verzahnung sowohl mit den Anforderungsebenen der Elicitation als auch den Modellierungsebenen des Designs möglich:

- Die Formalisierungsklassen unterscheiden sich von den typischen Anforderungsebenen der Elicitation (siehe beispielsweise [SS97, Som01, VH+03, AI+07], sowie Abschnitt 4.1) lediglich in der Sichtweise auf die einzelnen Klassen, die sich später in den unterschiedlichen Unterklassen zeigen wird: In der Elicitation steht die systematische Ableitung von Anforderungen im Vordergrund, daher werden Unterklassen beispielsweise oft entsprechend einer Systemdekomposition definiert [AI+07]. In der Formalisierung hingegen stehen die Anforderungsmuster und Elemente, an denen die Formalisierung ansetzt, im Vordergrund, daher werden Unterklassen entsprechend solcher Anforderungsmuster definiert.
- Bezüglich der Modellierungsebenen des Designs [HR+07] ist vor allem eine Verbindung vom Anforderungsmanagement zur ersten Modellierungsebene, der Nutzungsebene (Dienstebene), wichtig [HR07]. Diese Verbindung ist durch die Formalisierungsklasse der Nutzeranforderungen gegeben, deren Elemente durch die Formalisierungsmethodik direkt in die Dienstebene des Designs überführt werden. Der Übergang vom Anforderungsmanagement zum Design wird im Kapitel 10 detailliert beschrieben.

4.4.2 Atomarisierung von Anforderungen

Eine Anforderung kann nur zu genau einer Formalisierungsklasse ge¬hören. Wenn für eine Anforderung mehrere Klassen in Frage kommen und eine eindeutige Zuordnung nicht möglich ist, muss eine Atomarisierung der Anforderung durchgeführt werden. Dies kann nötig werden, da zum Teil die saubere Trennung insbesondere von Nutzer- und Systemanforderungen noch nicht gängige Praxis ist (siehe zum Beispiel die Fallstudie in Kapitel 3.3). Zudem ist zwar „Atomarität“ ein Qualitätskriterium für Anforderungen, das bereits in der Elicitation berücksichtigt werden sollte, aber in der Praxis sind etliche Anforderungen zunächst nicht atomar und müssen nachträglich noch in zwei oder mehrere Anforderungen zerlegt werden. Oft tauchen Inhalte, die der Klasse der Geschäftsanforderungen zuzuordnen sind, in Nutzeranforderungen auf (meist als begründender Nebensatz), und oft werden Nutzer- und Systemanforderungen vermischt. In der Klassifikation werden Anforderungen bei Bedarf so zerlegt, dass jede Anforderung eindeutig einer Formalisierungsklasse zugeordnet werden; das Ergebnis dieser Zerlegung ist noch nicht notwendigerweise eine atomare Anforderung, sodass im nächsten Formalisierungsschritt, der Formulierung, Anforderungen weiter analysiert und gegebenenfalls weiter zerlegt werden.

[...]