download - SPES 2020

- Deliverable D2.4.C: 

Evaluation des Ansatzes für die integrierte, modellbasierte Dokumentation von 

Anforderungen und Entwurf - 

Projektbezeichnung SPES 2020 

Version: 1.0 

Verantwortlich André Heuer, Bastian Tenbergen (Universtität Duisburg-Essen) 

QS-Verantwortlich Jessica Jung (Fraunhofer IESE) 

Erstellt am 10.01.2012 

Zuletzt geändert 25.01.2012 15:25 

Freigabestatus Vertraulich für Partner: ; ; … 

Projektöffentlich 

X Öffentlich 

Bearbeitungszustand in Bearbeitung 

vorgelegt 

X fertig gestellt

Weitere Produktinformationen 

Erzeugung André Heuer (AH), Bastian Tenbergen (BT) 

Mitwirkend Mark Rzepka (MR), Sebastian Gabrisch (SG), Jessica Jung (JJ) 

Änderungsverzeichnis 

Änderung 

Nr. Datum Version 

Geänderte 

Kapitel 

Beschreibung der 

Änderung 

Autor Zustand 

1 10.01.12 0.1 Alle Initiale Produkterstellung SG In Bearbeitung 

2 11.01.12 0.2 2, 3 Weitere Ausarbeitung BT In Bearbeitung 

3 13.01.12 0.3 3.1 Vervollständigung BT In Bearbeitung 

4 17.01.12 0.4 4 Vervollständigung AH In Bearbeitung 

5 19.01.12 0.5 3.2 Vervollständigung BT In Bearbeitung 

6 20.01.12 0.6 7, 2.3.1 Vervollständigung MR In Bearbeitung 

7 23.01.12 0.6 - Externes Review JJ Vorgelegt 

8 23.01.12 0.7 4 Überarbeitung nach Review AH In Bearbeitung 

9 25.01.12 1.0 Alle Überarbeitung nach Review MR/AH/BT Fertig gestellt

Deliverable D2.4.C: Evaluation des Ansatzes für die integrierte, modellbasierte 

Dokumentation von Anforderungen und Entwurf 

Kurzfassung 

Der Zweck dieses Dokumentes besteht darin, die im Rahmen von ZP-AP2 durchgeführten 

Evaluierungsaktivitäten darzustellen, zu erläutern und die Ergebnisse auszuwerten. 

Im Rahmen des Projektes wurden mehrere Evaluierungsaktivitäten durchgeführt. 

Zum einen wurde der Requirements-Engineering-Ansatz des ZP-AP2 durch Fallstudien 

evaluiert. Zum anderen wurden Benutzerstudien mit Praktikern aus der Industrie 

bzw. Software Engineering Studenten durchgeführt, die sowohl die Methodenakzeptanz 

bzw. Anwendbarkeit evaluieren. 

Die Evaluierungsaktivitäten haben eine Vielzahl von Verbesserung zur Folge gehabt. 

So haben die Ausarbeitungen der Fallstudien zu domänenspezifischen Anpassungen 

des Vorgehensmodells und der Artefakttypen des modellbasierten RE-Ansatzes geführt 

(siehe Anhang D). Ferner zeigt die Evaluierung zur Methodenakzeptanz ein 

tendenziell positives Bild. Insbesondere ist hervorzuheben, dass Praktiker den Ansatz 

als einfach anwendbar empfinden und der Ansicht sind, dass die richtigen notwendigen 

Artefakte durch den Ansatz zur Verfügung gestellt werden. Hinsichtlich der 

Hochwertigkeit der Ergebnisse evaluieren die Praktiker den RE-Ansatz ebenfalls positiv: 

der Ansatz erlaubt die Spezifikation von Artefakten mit hoher Qualität und Genauigkeit. 

Außerdem sind Praktiker tendenziell bereit, den Requirements- 

Engineering-Ansatz in ihrer täglichen Arbeit einzusetzen. Insgesamt lassen sich bzgl. 

der Methodenanwendbarkeit die folgenden Aussagen über den analysierten Ansatz 

festhalten: 

Die Probanden haben das Gefühl, durch die Nutzung des Ansatzes das zu 

analysierende System besser verstanden zu haben 

Die mit Hilfe des Ansatzes erstellte Dokumentation eines Systems ist nachvollziehbar 

Durch die Abstraktionsebenen haben die Probanden die Spezifikation beim 

Review besser verstanden. 

Durch die Evaluierungen zeigt sich allerdings auch das Potential für weitere Verbesserungsmöglichkeiten. 

Beispielsweise ist der Ansatz ohne Schulung durch einen Experten 

nur bedingt von Praktikern einsetzbar. Die Erkenntnisse zur Verbesserung ist 

Gegenstand zukünftiger Arbeiten. Zudem bedarf es weiteren Beispielen zur Anwendbarkeit 

des Ansatzes in industrieller Praxis. 

Zuletzt geändert: 27.04.2012 10:00 3/36



Inhalt 

1 Einordnung und Kurzbeschreibung ..................................................................... 5 

1.1 Motivation und Einordnung ............................................................................ 5 

1.2 Management Summary ................................................................................. 5 

1.3 Überblick ....................................................................................................... 6 

2 Überblick über die Evaluierungsaktivitäten in ZP-AP2 ........................................ 7 

2.1 Fragebogenstudie zur Erfassung der Methodenakzeptanz ........................... 7 

2.2 Benutzerstudie zur Erfassung der Methodenanwendbarkeit ......................... 7 

2.3 Weitere Evaluierungsaktivitäten .................................................................... 8 

3 Fragebogenstudie zur Erfassung der Methodenakzeptanz ............................... 10 

3.1 Planung der Evaluierung ............................................................................. 10 

3.2 Ergebnisse der Evaluierung ........................................................................ 13 

4 Benutzerstudie zur Erfassung der Methodenanwendbarkeit ............................. 17 

4.1 Planung und Durchführung der Evaluierung ................................................ 17 

4.2 Ergebnisse der Evaluierung ........................................................................ 20 

5 Zusammenfassung ............................................................................................ 24 

6 Literaturverzeichnis ........................................................................................... 26 

7 Anhang A – Möglichkeiten zur domänenspezifischen Anpassung des RE- 

Ansatzes auf Basis der Ergebnisse von Fallbeispiel Flugsteuerungssystem ........... 29 

7.1 Fallbeispiel Flugsteuerungssystem und die Herausforderungen der 

sicherheitskritischen Avionik-Domäne .................................................................. 29 

7.2 Erkannte Problembereiche und Verbesserungsvorschläge ......................... 30 

8 Anhang B – Fragebogen zur Methodenakzeptanz ............................................ 34 

9 Anhang C – Fragebögen zur Methodenanwendbarkeit ..................................... 35 

10 Anhang D – Ein Ansatz zur Spezifikation von Echtzeitanforderungen am Beispiel 

von Szenarien ........................................................................................................... 36 




1 Einordnung und Kurzbeschreibung 

In diesem Abschnitt wird der Zweck dieses Dokumentes kurz erläutert und in den 

Projektkontext eingeordnet. 

1.1 Motivation und Einordnung 

Die Aufgabe von ZP-AP2 im Laufe des SPES 2020-Projektes war die Erforschung 

und Entwicklung eines durchgängigen, modellbasierten Requirements-Engineering- 

Ansatzes. Dieser Ansatz baut auf Vorarbeiten der Uni Duisburg-Essen (siehe 

[SPES09a] sowie [Pohl10]) sowie eines systematischen Erhebung des Standes der 

Praxis (siehe [SPES10a], [SPES10b], [SPES10c], [SPES10d], [SPES10e], sowie 

[STP10], [STP11b] und STP11a]) auf und führten im Zuge des Projektes zu diversen 

methodischen Weiterentwicklungen (siehe [SPES11a], [SPES11b], [SPES11c], 

[SPES11d], [SPES11e]). 

Zur Sicherstellung der Qualität dieser Weiterentwicklungen wurde ein umfangreiches 

Evaluierungskonzept entwickelt, das verschiedene Evaluierungsaktivitäten beinhaltet. 

Diese Evaluierungsaktivitäten wurden teilweise im Rahmen der Arbeiten in ZP- 

AP2 und teilweise im Rahmen von Kooperationsarbeiten mit anderen ZP-APs und 

AWPs durchgeführt. Die im Rahmen von Kooperationsarbeiten entstandenen Evaluierungen 

wurden teilweise bereits veröffentlicht (siehe Abschnitt 2.3.1). 


Evaluierungsaktivitäten darzustellen, zu erklären und die Ergebnisse zu erläutern. 

1.2 Management Summary 


Evaluierungsaktivitäten darzustellen, zu erklären und die Ergebnisse zu erläutern. 

Im Rahmen des Projektes wurden mehrere Evaluierungsaktivitäten durchgeführt. 

Zum einen wurde der Requirements-Engineering-Ansatz des ZP-AP2 durch Fallstudien 

evaluiert. Zum anderen wurden Benutzerstudien mit Praktikern aus der Industrie 

bzw. Software Engineering Studenten durchgeführt, die sowohl die Methodenakzeptanz 

bzw. Anwendbarkeit evaluieren. 

Die Evaluierungsaktivitäten haben eine Vielzahl von Verbesserung zur Folge gehabt. 

So haben die Ausarbeitungen der Fallstudien zu domänenspezifischen Anpassungen 

des Vorgehensmodells und der Artefakttypen des modellbasierten RE-Ansatzes geführt 

(siehe Anhang D). Ferner zeigt die Evaluierung zur Methodenakzeptanz ein 

tendenziell positives Bild. Insbesondere ist hervorzuheben, dass Praktiker den Ansatz 

als einfach anwendbar empfinden und der Ansicht sind, dass die richtigen notwendigen 

Artefakte durch den Ansatz zur Verfügung gestellt werden. Hinsichtlich der 

Hochwertigkeit der Ergebnisse evaluieren die Praktiker den RE-Ansatz ebenfalls positiv: 

der Ansatz erlaubt die Spezifikation von Artefakten mit hoher Qualität und Genauigkeit. 

Außerdem sind Praktiker tendenziell bereit, den Requirements- 

Engineering-Ansatz in ihrer täglichen Arbeit einzusetzen. Insgesamt lassen sich bzgl. 

der Methodenanwendbarkeit die folgenden Aussagen über den analysierten Ansatz 

festhalten: 


analysierende System besser verstanden zu haben 

Die mit Hilfe des Ansatzes erstellte Dokumentation eines Systems ist nachvollziehbar 






Durch die Evaluierungen zeigt sich allerdings auch das Potential für weitere Verbesserungsmöglichkeiten. 

Beispielsweise ist der Ansatz ohne Schulung durch einen Experten 

nur bedingt von Praktikern einsetzbar. Die Erkenntnisse zur Verbesserung ist 

Gegenstand zukünftiger Arbeiten. Zudem bedarf es weiteren Beispielen zur Anwendbarkeit 

des Ansatzes in industrieller Praxis. 

1.3 Überblick 

In Abschnitt 2 wird ein Überblick über die in ZP-AP2 geleisteten Evaluierungsarbeiten 

gegeben. Abschnitte 3Fehler! Verweisquelle konnte nicht gefunden werden. und 

4Fehler! Verweisquelle konnte nicht gefunden werden. stellen die wichtigsten im 

Rahmen von ZP-AP2 durchgeführten Aktivitäten vor und stellt die Ergebnisse dar. 

Abschnitt 5 fasst die Ergebnisse zusammen. Weiterführende Materialien können den 

Anhängen entnommen werden. 




2 Überblick über die Evaluierungsaktivitäten in ZP-AP2 

Im Rahmen der Forschung im ZP-AP2 wurden eine Reihe gezielter Evaluierungen 

des Requirements-Engineering-Ansatzes und seiner Ergebnisartefakte durchgeführt. 

Des Weiteren wurden Evaluierungen der Methodik von ZP-AP2 im Rahmen von Kooperationen 

mit Anwendungsprojekten sowie anderen ZP-APs durchgeführt. In diesem 

Abschnitt wird ein kurzer Überblick über alle Evaluierungsaktivitäten im ZP-AP2 

gegeben und die Ziele jeder Evaluierungsaktivität vorgestellt. Die eingesetzten Methoden 

sowie die Ergebnisse der in Kooperationen durchgeführter Evaluierungsaktivitäten 

werden zusammengefasst und es wird auf das Ergebnisdokument der jeweiligen 

Evaluierungsaktivität verwiesen. 

Die folgenden Evaluierungsaktivitäten wurden im Rahmen von ZP-AP2 oder in Kooperation 

mit ZP-AP2 durchgeführt: 

- Fragebogenstudie zur Erfassung der Methodenakzeptanz 

- Benutzerstudie zur Erfassung der Methodenanwendbarkeit 

- Evaluierung anhand von Fallstudien 

- Anwendungsworkshops mit AWP-EN 

- Evaluierung der Integrierbarkeit mit AWP-AU-AP3 

Die Fragebogenstudie zur Erfassung der Methodenakzeptanz und die Benutzerstudie 

zur Erfassung der Methodenanwendbarkeit wird in den Abschnitten 2.1 und 2.2 

zunächst überblicksartig vorgestellt und dann in den Abschnitten 3 und 4 detailliert 

erläutert. Die restlichen Evaluierungsaktivitäten werden in Abschnitt 2.3 zusammengefasst, 

da sie in anderen Dokumenten bereits erläutert werden. 

2.1 Fragebogenstudie zur Erfassung der Methodenakzeptanz 

Ziel dieser Evaluierungsaktivität war es, die Akzeptanz des modellbasierten Requirements-Engineering-Ansatzes 

in industrieller Praxis zu untersuchen, sowie die Fähigkeit 

des Ansatzes zu prüfen, industrielle Aufgaben bewältigen zu können. Dazu 

wurde ein auf dem Technology Acceptance Model (siehe [TAM1], [TAM2], [TAM3]) 

und Task-Technology Fit Model ([TTF]) basierender Fragebogen erstellt und von 

Praktikern aus der Industrie, die mit dem RE-Ansatz intensiv vertraut sind, ausgefüllt. 

2.2 Benutzerstudie zur Erfassung der Methodenanwendbarkeit 

Die Anwendbarkeit des Ansatzes wurde in einer longitudinal angelegten Studie mit 

studentischen Probanden untersucht. Dazu wurde im Rahmen einer Lehrveranstaltung 

an der Universität Duisburg-Essen ein vereinfachter Ansatz der RE-Methode zur 

Entwicklung eines Systems genutzt. Die Spezifikation für das zu entwickelnde System 

wurde durch die Studenten entsprechend dokumentiert. Um die Verständlichkeit 

des spezifizierten Systems zu prüfen, hat eine andere Studentengruppe die Dokumentation 

ebenfalls auf Basis der RE-Methodik qualitätsgesichert. 

Das Ziel der Studie bestand darin zu untersuchen, wie sich die Aufwände für die 

Spezifikation des Systems und dem Review der Dokumentation über den Evaluationszeitraum 

hinweg verteilen. Des Weiteren wurde untersucht, ob der Ansatz die 

Analyse und die Modellierung des Systems erleichtert hat. Ebenso wurde untersucht, 

ob das Verständnis über und die Implementierung des geplanten Systems erleichtert 

wurde. 




2.3 Weitere Evaluierungsaktivitäten 

Im Folgenden werden weitere Evaluierungsaktivitäten aufgeführt, die in Kooperationen 

zwischen ZP-AP2 und anderen ZP-APs und AWPs durchgeführt und bereits 

veröffentlicht wurden. 

2.3.1 Evaluierung anhand von Fallbeispielen 

Die Evaluierungsaktivität anhand der Fallbeispiele hatte das Ziel, die Anwendbarkeit 

und die Industrietauglichkeit der Lösungskonzepte des Requirements-Engineering- 

Ansatzes zu evaluieren. 

In insgesamt fünf Fallbeispielen (siehe Tabelle 2-1) wurden vereinfachte Systeme 

anhand des Requirements-Engineering-Ansatzes von ZP-AP2 entwickelt und die 

Ausgabeartefakte durch Experten der Industriepartner begutachtet. Die Expertenmeinungen 

und Gutachten wurden im Rahmen von verschiedenen Workshops zu 

konkreten Verbesserungen für den Requirements-Engineering-Ansatz weiterentwickelt. 

Beispielsweise wurden spezielle Anpassungen des Ansatzes vorgenommen, 

um Echtzeiteigenschaften in Anforderungsmodellen zu berücksichtigen (siehe Anhang 

D). Des Weiteren wurde für jedes AWP Anpassungsmöglichkeiten und Ansätze 

zum domänenspezifischen Tailoring (siehe [SPES11a] und Anhang A) entwickelt. 

Eine Besonderheit stellt das Fallbeispiel „Motorsteuerung“ dar. Dieses wurde nach 

Absprache der Projektpartner durch ein weniger umfangreiches Fallbeispiel „Luftsystem“ 

ersetz, um konkretere Fragestellungen zu untersuchen. 

In Tabelle 2-1 ist eine Zusammenfassung aller Fallbeispiele durch Evaluierungsaktivitäten 

des Requirements-Engineering-Ansatzes mit ZP-AP2, deren Zugehörigkeit zu 

einem Anwendungsgebiet und das jeweils relevante SPES-Dokument gegeben. 

Fallbeispielname Kurzbeschreibung AWP Ergebnis (-dokument) 

Zylinderkopf- 

Fertigungsanlage 

Entwicklung einer Fertigungsanlage 

zur Produktion von Zylinderköpfen 

unter besonderer 

Berücksichtigung von Echtzeitaspekten 

sowie funktionaler, 

logischer und technischer Archi- 

tektur. 

Motorsteuerung Entwicklung einer Motorsteuerung 

für KFZ zur Regelung von 

Zündung, Einspritzung und 

Luftmasse. 

Luftsystem Entwicklung eines Steuergeräts 

zur Regelung der Luftmasse 

innerhalb einer Motorsteuerung 

Klimaanlage Entwicklung eines Klimakontrollsystems 

für die Fluggastkabine 

eines Passagierflugzeugs zur 

Regelung von Kabinendruck, 

Frischluftzufuhr und Innentem- 

peratur. 

Flugsteuerungssystem Entwicklung eines Flugsteuerungssystems 

zur Kontrolle der 

Flughöhe eines Flugzeugs, inkl. 

der sicherheitskritischen Anforderungen 

und damit verbundenen 

Redundanzmaßnahmen. 

Automatisierung 

[SPES11f] 

Automotive [SiPo10], [SPES12d] 

Automotive [SPES12d] 

Avionik [SPES12e] 

Avionik [SPES12b], [SPES12c], 

Anhang A 

Tabelle 2-1 Zusammenfassung der Fallbeispiele mit Beteiligung von ZP-AP2 




2.3.2 Anwendungsworkshops mit AWP-EN 

Im Anwendungsprojekt Energie wurde in drei aufeinander aufbauenden Workshops 

mit insgesamt ca. 30 Domänenexperten durchgeführt, in denen der RE-Ansatz angewandt 

wurde. 

Das Ziel der Evaluierung bestand darin, den Ansatz in Bezug auf die praktische Anwendbarkeit 

und den Nutzen für Projekte in der Domäne Energie zu prüfen. 

Zu diesem Zweck wurde ein Evaluierungskonzept entwickelt, welches die Anwendung 

des Ansatzes im Rahmen energiewirtschaftlicher Projekte untersucht. Zur Messung 

der Anwendbarkeit und des Nutzens wurde ein dreistufiges Fragebogenkonzept 

verfolgt, welches jeweils nach dem ersten, zweiten und dritten Workshop den Wissensgewinn 

mithilfe eine Meinungstests misst. 

Insgesamt zeigten die Ergebnisse eine positive Bewertung des Ansatzes. Dies blieb 

auch bei mehrfacher Anwendung des Ansatzes mit unterschiedlichen Teilnehmern 

konstant. Vor allem die verzahnte Entwicklung von Lösung und Anforderungen sowie 

die Einbeziehung der Ziel- und Szenarioanalyse überzeugten die Teilnehmer, dass 

die Methode im Rahmen der Anwendungsdomäne Energie zur Anwendung bei der 

Entwicklung der in dieser Domäne charakteristischen Systeme geeignet ist (siehe 

[SPES11g]. Allerdings zeigte sich, dass der Zusammenhang der Konzepte für die 

Befragten nicht immer direkt zu erkennen war. 

Probleme wurden vor allem in der Übertragbarkeit der Methodik auf andere Anwendungsfälle 

gesehen. So waren die Teilnehmer der Meinung, dass für die Anwendung 

der Methodik ein geschulter Moderator notwendig ist. Aus diesem Grunde erschien 

es den Befragten auch schwierig, den Ansatz aus deren aktuellem Kenntnisstand 

heraus Anderen zu vermitteln. Dies könnte jedoch auch in der relativ knappen Dauer 

für die Vermittlung und Anwendung der RE-Methode liegen, die in den einzelnen 

Workshops zur Verfügung stand. So entfiel relativ wenig Zeit auf den methodischen 

Schulungsteil im Verhältnis zum Anwendungsteil des Ansatzes. Eine tiefergehende 

Betrachtung der Ergebnisse lässt sich [SPES11g] und [SPES11h] entnehmen. 

2.3.3 Evaluierung der Integrierbarkeit mit AWP-AU-AP3 

Im Rahmen des SPES 2020-Projektes wurden zwei unterschiedliche Ansätze zur 

Erhebung und Dokumentation von Anforderungen für Eingebettete Systeme entwickelt. 

Neben dem Ansatz des ZP-AP2 gibt es auch einen Ansatz der Uni Paderborn 

und Hella, der im Rahmen von AWP-AU-AP3 entwickelt wurde. 

Der Ansatz aus AWP-AU-AP3 ist in der Lage, unter Verwendung von Satzmustern 

funktionale Architekturmodelle abzuleiten und zu validieren. Im Rahmen der Erhebung 

zum Stand der Praxis ([STP11a], [STP11b]) stellte sich heraus, dass die geringe 

Akzeptanz im industriellen Alltag modellbasierter RE-Ansätze sowie die Probleme, 

die im industriellen Alltag durch die Verwendung ausschließlich natürlichsprachlicher 

Anforderungen entstehen, durch eine geeignete Vereinigungen beider Dokumentationsformen 

in einem gemeinsamen RE-Ansatz überkommen werden können. 

Zu diesem Zweck wurde angestrebt, die RE-Ansätze des ZP-AP2 und des AWP-AU- 

AP3 auf deren Integrierbarkeit zu überprüfen, sodass eine Methode für den nahtlosen 

Übergang modellbasierter und natürlichsprachlicher RE-Prozesse zur Verfügung 

gestellt werden kann. Ergebnis der Prüf- und Integrationsarbeiten ist ein gemeinsamer 

RE-Ansatz, der durch Satzmuster eingeschränkte, funktionale Anforderungen 

auf Basis von modellbasierten, lösungsneutralen Anforderungen entwickeln und hierarchische 

Funktionsmodelle generieren kann [SPES12a]. 




3 Fragebogenstudie zur Erfassung der Methodenakzeptanz 

In diesem Kapitel wird die Evaluierungsaktivität zur Evaluierung der Methodenakzeptanz 

des modellbasierten Requirements-Engineering-Ansatzes erläutert. Eine Zusammenfassung 

ist in Abschnitt 2.1 enthalten. 

3.1 Planung der Evaluierung 

Die Evaluierung wurde als fragebogenbasierte Expertenbefragung durchgeführt. Um 

einen Fragebogen zu entwerfen, der das in Abschnitt 2.1 dargestellten Ziel der Bewertung 

der Nutzerakzeptanz und Anwendbarkeit des RE-Ansatzes im industriellen 

Kontext erreichen kann, wurden Evaluationsartefakte entwickelt, die im Folgenden 

kurz erläutert werden. 

3.1.1 Forschungsfragen und Evaluationsziel 

Folgende Forschungsfragen lagen der Evaluationsaktivität zu Grunde: 

Frage 1: Inwieweit wird der modellbasierte Requirements-Engineering-Ansatz 

von Praktikern in der Industrie akzeptiert? 

Frage 2: Inwieweit stellt der Ansatz richtige, hochqualitative und nützliche Informationen 

für die Arbeit der Praktiker in der Industrie bereit? 

Frage 3: Welche Bereitschaft existiert Praktikern in der Industrie, den Ansatz 

einzusetzen? 

Ziel war es nun, die in den Forschungsfragen enthaltenen Inhalte messbar zu machen 

und ein geeignetes Erhebungsinstrument zu erstellen. 

3.1.2 Variablen zur Messung der Forschungsfragen 

In nächsten Planungsschritt wurde eine strukturierte Literatursuche nach Möglichkeiten 

zum Messen dieser drei Forschungsfragen durchgeführt. Diese Suche ergab eine 

Vielzahl von Variablen, die über Items mit einer 7-stufigen Likert-Skalierung in einem 

Fragebogen messbar gemacht wurden. 

Variablen zu Forschungsfrage 1 

Die Literatursuche ergab, dass es die Faktoren „Perceived Usefulness“ (deutsch: 

Wahrgenommene Nützlichkeit) sowie „Perceived Ease of Use“ (deutsch: Wahrgenommene 

Einfachheit der Nutzung) zur Messung von Akzeptanz einer Technologie 

durch Praktiker (siehe Frage 1, Abschnitt 3.1.1) einen hohen Stellenwert haben (vgl. 

[TAM1]). Der Faktor „Perceived Usefulness“ beschreibt den Grad, zu dem eine Person 

glaubt, dass das Verwenden einer Technologie seine Arbeitsleistung verbessert 

[TAM1]. Der Faktor „Perceived Ease of Use“ beschreibt den Grad, zu dem eine Person 

glaubt, dass die Verwendung einer Technologie frei von Aufwand ist [TAM1]. 

Beide Faktoren beschreiben die Einfachheit der Verwendung einer Technologie. Die 

Einfachheit der Verwendung ist somit ein Kernaspekt von Nutzerakzeptanz [DBW89], 

die in einem Akzeptanzmodell, dem Technology Acceptance Model (TAM, siehe 

[TAM1]), zusammengefasst und durch Verwendung eines Fragebogens gemessen 

wird. Ein weiterer, im Task-Technology-Fit Model betrachteter Faktor, der die Ein- 




fachheit der Verwendung (als Voraussetzung für Akzeptanz) betrachtet, ist die Menge 

an formalem Training, welches für die Verwendung einer Technology notwendig 

ist [TTF]. Dieser Faktor ist Teil des Task-Technology-Fit (TTF) Modells, einem Akzeptanzmodell, 

welches die Eignung einer Technologie für einen bestimmten Zweck 

misst. Weitere Faktoren für Methodeneignung und Nutzerakzeptanz sind Lokalisierbarkeit 

der Artefakte, Zugreifbarkeit der Artefakte, Flexibilität der Repräsentation sowie 

Verständlichkeit der Präsentation aufgeführt [TTF]. Diese Faktoren zielen speziell 

auf die „Daten“ einer Technologie, bzw. im Falle des Requirements-Engineering- 

Ansatzes, auf die Artefakte ab und messen den Grad, wie einfach es ist, die Artefakte 

des Ansatzes im Vorgehensmodell zu finden, auf die darin enthaltenen Informationen 

zuzugreifen, deren Repräsentation anzupassen bzw. zu verstehen. 


Weitere Variablen, die die Artefakte des RE-Ansatzes bewerten, befassen sich mit 

der Richtigkeit, Qualität, und dem Nutzen der darin enthaltenen Informationen (siehe 

Frage 2, Abschnitt 3.1.1) und stellen eine Erweiterung des ursprünglichen Technology 

Acceptance Model dar [TAM2]. Zu diesen Variablen gehört „Output Quality“, welche 

den Grad misst, zu dem eine Person glaubt, dass eine Technologie Artefakte in 

hoher Qualität produziert und somit seine Aufgabe gut verrichtet [TAM2]. Ferner gehört 

zu diesen Variablen „Result Demonstrability“, welche den Grad misst, zu dem 

eine Person glaubt, dass eine Technologie, greifbare, erlebbare und kommunizierbare 

Ausgaben liefert (siehe [MoBe91], [TAM2]). Das Task Technology Fit Model beinhaltet 

ebenfalls eine Reihe von Variablen zur Messung der Informationsqualität des 

RE-Ansatzes: „Right Data“, „Right Level of Detail“ und „Accuracy“. Die Variablen 

„Right Data“ bzw. „Right Level of Detail“ messen den Grad, zu dem die notwendigen 

grundlegenden Informationen der Technologie produziert werden [TTF] bzw. ob diese 

Informationen mit dem richtigen Detailgrad zur Verfügung gestellt werden [TTF]. 

Zudem misst „Accuracy“, den Grad, zu dem die produzierten Informationen korrekt 

sind [TTF]. 


Frage 3 in Abschnitt 3.1.1 adressiert die Bereitschaft von Praktikern, den Ansatz für 

ihre Arbeit im industriellen Alltag einzusetzen. Dazu hat die Literaturrecherche ergeben, 

dass drei wesentliche Faktoren zu dieser Bereitschaft beitragen. Dies ist zum 

einen die Menge der Ressourcen, die die Verwendung einer Technologie fördern 

[VMDD03], zum anderen die Nutzerabsicht, eine Technologie einzusetzen [DBW89] 

sowie der Grad, zu dem die Verwendung einer Technologie freiwillig ist [MoBe91]. 

Diese Faktoren werden mit den Variablen „Perception of External Control“, „Behavioral 

Intention“ sowie „Voluntariness“ gemessen. 

Die der Literatur entnommenen Variablen und deren Zuordnung zu den Evaluierungsfragen 

aus Abschnitt 3.1.1 sind in Tabelle 3-1 zusammengefasst. 




Variable Abk. Definition Quelle Eval.- 

Frage 

Perceived Usefulness PU Der Grad, zu dem eine Person glaubt, 

dass das Verwenden einer Technologie 

die Arbeitsleistung verbessert. 

Perceived Eas of Use PEOU Der Grad, zu dem eine Person glaubt, 

dass die Verwendung einer Technologie 

frei von Aufwand ist. 

Training TRAIN Die Menge an formalem Training, welches 

notwendig ist, um die Technologie 

verwenden zu können. 

Lokalisierbarkeit LOC Der Grad, wie einfach es ist, notwendige 

Artefakte einer Technologie zu finden. 

Zugreifbarkeit ACC Der Grad, wie einfach es ist, auf notwendige 

Artefakte einer Technologie zuzufrei- 

fen. 

Flexibilität FLEX Der Grad, wie einfach es ist, die Repräsentation 

von Artefakten einer Technologie 

anzupassen. 

Präsentation PRES Der Grad, wie einfach es ist, die Artefakte 

der Technologie zu verstehen. 

Ouput Quality OUT Der Grad, zu dem eine Person glaubt, 

dass eine Technologie eine Aufgabe gut 

verrichtet. 

Result Demonstrability RES Der Grad, zu dem eine Person glaubt, 

dass eine Technologie greifbare, erlebba- 

re und kommunizierbare Ausgaben liefert. 

The Right Data DATA Der Grad, zu dem die notwendigen und 

grundlegenden Artefakte von einer Technologie 

produziert werden. 

The Right Level of Detail DET Der Grad, zu dem die Artefakte mit dem 

richtigen Detailgrad produziert werden. 

Accuracy ACCU Der Grad, zu dem die von der Technolo- 

Perception of External 

Control 

gie produzierten Artefakte korrekt sind. 

PEC Der Grad, zu dem eine Person glaubt, 

dass betriebliche und technische Ressourcen, 

die die Verwendung der Technologie 

unterstützen, verfügbar sind. 

[TAM1] Frage 1 


[TTF] Frage 1 

[TTF] Frage 1 

[TTF] Frage 1 

[TTF] Frage 1 

[TTF] Frage 1 


[MoBe91] Frage 2 

[TTF] Frage 2 

[TTF] Frage 2 

[TTF] Frage 2 

[VMDD03] Frage 3 

Behavioral Intention BI Das Ausmaß der Absicht einer Person, 

die Technologie zu verwenden. 

[DBW89] Frage 3 

Voluntariness VOL Der Grad, zu dem die Verwendung der 

Technologie als freiwillig oder ohne 

Zwang eingeschätzt wird. 

[MoBe91] Frage 3 

Tabelle 3-1 Zusammenfassung Variablen für jede Evaluierungsfrage. 

3.1.3 Messinstrument 

Nachdem die Variablen für jede Evaluationsfrage festgelegt worden sind, wurde ein 

Fragebogen entwickelt (siehe Anhang B). Zu jeder Variable existieren in der Literatur 

(vgl. Tabelle 3-1) eine Menge von Fragen/Items, welche die Variable messen. 

Diese Fragen stellen Aussagen dar, die mit Hilfe einer Skala bewertet werden sollen 

und zu einem Fragebogen zusammengestellt werden. Dabei wurde darauf geachtet, 

dass die Definition der Variablen sowie die Fragen, die zu jeder Variable gehören, 

sinnerhaltend ins Deutsche übersetzt wurden, da die Fragen größtenteils aus englischer 

Literatur stammen. Um Homogenität im Fragebogen zu gewährleisten 

[CoSt08], wurde bei der Fragebogenerstellung auf Einheitlichkeit der Antwortskalen 

geachtet, und alle Skalen auf eine 7-Punkt-Likert-Skala (1: „trifft nie zu“; 2: „fast nie“; 

3: „selten“; 4: „teils-teils“; 5: „oft“; 6: „häufig“; 7: „trifft immer zu“) umgestellt. 

Die verwendeten Variablen sind für die Anwendung auf ein konkretes Produkt, beispielsweise 

einer Softwarelösung, abgestimmt. Da in diesem Evaluierungsvorhaben 

eine Vorgehensweise anstelle einer konkreten Technologie Gegenstand der Evaluation 

war, war es notwendig, die zu den Variablen gehörenden Fragen für die Ver- 




wendung um Evaluationsfragebogen anzupassen. Dabei wurde darauf geachtet, 

dass jede Frage sinnerhaltend angepasst wurde. Dies konnte im Großteil der Fälle 

durch einfaches Austauschen der Objektwörter in den Fragen erledigt werden 1 . 

3.1.4 Durchführung 

An der Evaluation nahmen Praktiker aus dem AWP-AU teil. Die Praktiker waren bereits 

durch die Kooperation mit dem ZP-AP2 und der Ausarbeitung der Fallstudien 

„Motorsteuerung“ und „Luftsystem“ (siehe Abschnitt 2.3.1) mit der Vorgehensweise 

im Requirements-Engineering-Ansatz des ZP-AP2 vertraut. Das in Abschnitt 3.1.3 

beschriebene und in Anhang B gezeigte Messinstrument wurde im November 2011 

an die Praktiker per E-Mail verteilt. Die Teilnehmer wurden gebeten, binnen einer 

Woche den ausgefüllten Fragebogen zurückzusenden. Als Unterstützungsmaterial 

wurden eine Kurzzusammenfassung der Lösungskonzepte des RE-Ansatzes sowie 

eine umfangreiche Methodenbeschreibung zusammen mit dem Fragebogen ausgeteilt. 

Dieses Material stand während der Bearbeitungszeit der Fragebögen uneingeschränkt 

zur Verfügung. Die Rücklaufquote betrug 100%. 

3.2 Ergebnisse der Evaluierung 

In diesem Abschnitt werden die Ergebnisse der Evaluierung kurz zusammengefasst 

und mit den Ergebnissen der Studien zum Stand der Praxis im modellbasierten Requirements 

Engineering (siehe [STP11a] und [STP11b]) relationiert. Eine Liste der in 

Abbildung 3-1, Abbildung 3-2 und Abbildung 3-3 verwendeten Variablenabkürzungen 

sowie eine Erläuterung der Variablen kann Tabelle 3-1 entnommen werden. 

Die hier dargestellten Prozentwerte geben Grad der Erfüllung einer Variable an. Für 

jede Variable wird eine Menge von Fragen auf einer 7-Punkt-Likert-Skala (siehe Abschnitt 

3.1.3) bewertet. Die „Zustimmung“ der Fragen der jeweiligen Variablen werden 

addiert. Der Maximalwert einer Variable (also die Beantwortung aller Fragen der 

Variable mit dem Maximalwert „7“) wird mit der Anzahl der Teilnehmer multipliziert 

und anschließend durch die erreichte Punktzahl aller Teilnehmer der jeweiligen Variable 

geteilt. 

3.2.1 Ergebnisse zu Forschungsfrage 1 

In Abbildung 3-1 sind die Zustimmungswerte für die Variablen Perceived Usefulness 

(PU), Perceived Ease of Use (PEOU), Training (TRAIN), Lokalisierbarkeit (LOC, Zugreifbarkeit 

(ACC), Flexibilität (FLEX) und Präsentation (PRES) dargestellt. Werte 

unterhalb 50% stellen eine Ablehnung dar, Werte über 50% sind als Zustimmung zu 

interpretieren. 

1 Das Messinstrument sowie das unübersetzte Original werden von den Autoren auf Anfrage zur Ver- 

fügung gestellt. 




PU 

PEOU 

TRAIN 

LOC 

ACC 

FLEX 

PRES 

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 

46,429% 

42,857% 

60,714% 

57,143% 

57,143% 

57,143% 

66,667% 

Abbildung 3-1 Auswertung der Antworten zu den Variablen zu Forschungsfrage 1 

Die in Abbildung 3-1 dargestellten Ergebnisse zeigen, dass im Allgemeinen der Ansatz 

als tendenziell nützlich empfunden wird. Dies zeigt sich dadurch, dass die empfundene 

Nützlichkeit (PU), sowie Anpassbarkeit als der Repräsentationsform (FLEX) 

einen Zustimmungsgrad über 60% erhalten. Hinsichtlich der Verwendbarkeit der 

durch den Ansatz bereitgestellten Daten zeigt sich Potential zur Verbesserung. Sowohl 

die Variable hinsichtlich der guten bzw. einfachen Präsentation der Artefakte 

(PRES), sowie die Möglichkeit, notwendige Informationen schnell und einfach zu finden 

(LOC, ACC) erreichen lediglich einen Zustimmungsgrad von 57% bzw. 43%. 

Ebenfalls zeigt sich, dass die Verwendbarkeit des Ansatzes ohne Training eingeschränkt 

sein kann, da die entsprechende Variable lediglich eine Zustimmung von 

ebenfalls 57% erreicht. Dieses Ergebnis wird durch die Funde in [SPES11g] und 

[SPES11h] bestätigt: in der Evaluierung im Rahmen von AWP-EN zeigt sich, dass 

sich eine einführende Schulung durch einen Moderator positiv auf die Anwendbarkeit 

des Ansatzes auswirkt. Ferner wird dieses durch die empfundene Einfachheit der 

Nutzung des Ansatzes deutlich: in dieser VariableVariable wurde lediglich ein Zustimmungsgrad 

von 46% erreicht. 

Zusammenfassend kann gesagt werden, dass die Akzeptanz des Ansatzes durch 

Praktiker zwar überdurchschnittlich, jedoch keine herausragende Zustimmung erhält. 

Gründe hierfür liegen vor allem bei der Verwendbarkeit des Ansatzes. Weitere Evaluierungen 

[SPES11h] haben gezeigt, dass formales Training die Anwendbarkeit und 

Akzeptanz erhöhen. 


In Abbildung 3-2 sind die Zustimmungswerte für die Variablen Output Quality (OUT), 

Result Demonstrability (RES), The Right Data (DATA), The Right Level of Detail 

(DET) und Accuracy (ACCU) dargestellt. Werte unterhalb 50% stellen eine Ablehnung 

dar, Werte über 50% sind als Zustimmung zu interpretieren. 




OUT 

RES 

DATA 

DET 

ACCU 

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 

42,857% 

57,143% 

57,143% 

66,667% 

75,00% 


Bezüglich der Qualität der durch den Ansatz bereitgestellten Artefakte zeigt sich ein 

größtenteils hoher Zustimmungsgrad zu den Fragen der einzelnen Variablen (siehe 

Abbildung 3-2). Insgesamt werden die Datengenauigkeit (ACCU) sowie die allgemeine 

Qualität der zur Verfügung gestellten Artefakte (OUT) mit 57% Zustimmungsgrad 

als hochwertig angesehen. Zudem sind die Teilnehmer tendenziell der Ansicht, dass 

die durch den Ansatz zur Verfügung gestellten Artefakte die grundlegendsten und 

notwendigsten Informationen bereitstellen (DATA, 67% Zustimmung). Ein hoher 

Grad an kommunizierbaren Ergebnissen (RES, 75% Zustimmung) zeigt sich ebenfalls 

aus den Ergebnissen. Ein tendenziell geringer Zustimmungsgrad (43%) zeigt 

sich im Hinblick auf den Detailgrad der durch den Ansatz produzierten Artefakte 

(DET). Dies wurde bereits in vergangenen Studien (vgl. [SiPo10] und [STP11b]) 

deutlich: aktuelle industrielle Praxis wendet keine klare Vorgehensweise an, um Anforderungen 

auf unterschiedlichen Abstraktionsebenen zu spezifizieren. Obwohl der 

RE-Ansatz von ZP-AP2 hier Abhilfe schafft, zeigen die Ergebnisse zu Forschungsfrage 

1 (siehe Abschnitt 3.2.1), dass weitere Schulungen zum Umgang mit den Lösungskonzepten 

des Ansatzes notwendig wären (?). 

Aus den Daten kann geschlossen werden, dass hochqualitative und nützliche Informationen 

und die grundlegend richtigen Artefakte für den Benutzer vom Ansatz tendenziell 

bereitgestellt werden. Verbesserungspotential gibt es aus Sicht der Probanden 

bzgl. des Detailgrades, auf dem die Artefakte dargestellt werden. 


In Abbildung 3-3 sind die Zustimmungswerte für die Variablen Perception of External 

Control (PEC), Behavioral Intention (BI) und Voluntariness (VOL) dargestellt. Werte 

unterhalb 50% stellen eine Ablehnung dar, Werte über 50% sind als Zustimmung zu 

interpretieren. 

PEC 

BI 

VOL 

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 

23,810% 

71,429% 

76,190% 





Aus den in Abbildung 3-3 dargestellten Daten zeigt sich, dass die Teilnehmer der 

Ansicht sind, dass sie alle notwendigen Ressourcen haben, den Ansatz problemlos 

einsetzen zu können (PEC, 71% Zustimmung). Des Weiteren wird die Verwendung 

des Ansatzes weitestgehend als freiwillig, d.h. ohne Zwang durch Vorgesetzte oder 

organisatorische Richtlinien durchgeführt, wie der Zustimmungsgrad von 76% zeigt 

(VOL). Im Widerspruch dazu sind die Ergebnisse bzgl. der Variable „Behavioral Intention“ 

(BI). Hier zeigt sich nur eine geringe Zustimmung (24%), was bedeutet, dass 

trotz der tendenziell positiven Evaluierung des Ansatzes (siehe Abschnitte 3.2.1 und 

3.2.2) Praktiker in der absehbaren Zukunft den Ansatz nicht anwenden werden. Dies 

lässt sich dadurch erklären, dass Praktiker die Verwendung einer neuen, bisher nicht 

in der täglichen Praxis erprobten Methode als risikoreich ansehen [STP11b]. Es wäre 

daher vorteilhaft, praxisnahe Beispiele ähnlich den Fallbeispielen in Abschnitt 2.3.1 

zur Förderung der Methodenakzeptanz auszuarbeiten. 

Die Ergebnisse zu dieser Evaluationsfrage zeigen, dass Praktiker tendenziell bereit 

sind, den Requirements-Engineering-Ansatz einzusetzen. Es bedarf allerdings weiteren 

Beispielen zur Anwendbarkeit des Ansatzes in industrieller Praxis. 




4 Benutzerstudie zur Erfassung der Methodenanwendbarkeit 

Im Folgenden wird nun die Evaluation der Anwendbarkeit der RE Methodik 

beschrieben. Dazu wird zunächst beschrieben, wie die Evaluierung durchgeführt 

wurde. Darauf aufbauend werden die Ergebnisse der Evaluierung beschrieben und 

interpretiert. 

4.1 Planung und Durchführung der Evaluierung 

Zur Evaluierung der Anwendbarkeit der Methodik wurde die Veranstaltung Software 

Entwicklung & Programmierung (SEP) 2 an der Universität Duisburg-Essen genutzt. 

Die Veranstaltung wird in jedem Semester angeboten und hat einen Umfang von 

sechs ECTS Credit Points. Bei der Veranstaltung handelt es sich um ein Softwarepraktikum, 

welches im 2.Fachsemester der Bachelor Studiengänge Angewandte Informatik 

– Systems Engineering, Wirtschaftsinformatik und Lehramt Informatik liegt. 

Die Studierenden müssen in einer Neigungsgruppe von fünf Studierenden während 

des Semesters ein Software Projekt durchführen. Während dieses Projekts wird von 

den Studierenden entweder eine Anwendung, ein Spiel oder ein eingebettetes System 

mit Lego Mindstorms entwickelt. Begleitend finden zwei Mal pro Woche jeweils 

zweistündige Präsenzstunden statt, in der sich die Studenten mit dem Betreuer austauschen 

können, Feedback erhalten und neue Aufgaben bekommen. In der Veranstaltung 

wird ein auf dem V-Modell basierender Entwicklungsprozess genutzt, der 

auch eine umfangreiche Requirements Engineering Phase vorsieht (vgl. [LSP07]). 

Innerhalb dieser Requirements Engineering Phase wurde ein vereinfachter Ansatz 

der RE-Methode eingesetzt und evaluiert. 

4.1.1 Evaluierungsziele 

Das Ziel dieser Evaluierung ist die Untersuchung der Anwendbarkeit des Ansatzes. 

Dazu wird die Evaluierung in zwei Teile aufgeteilt. Während das Ziel des ersten Teils 

ist, den Aufwand zur Anwendung der Methodik zu untersuchen, fokussiert der zweite 

Teil auf die Anwendbarkeit des Ansatzes hinsichtlich Analyse und Implementierung 

des Systems. 

Bei der Nutzung des Ansatzes wird zunächst davon ausgegangen, dass der Aufwand, 

der in den einzelnen Phasen des Ansatzes benötigt wird, konstant ist. Ist der 

Aufwand in einem Bereich stark unterschiedlich, könnte daraus geschlossen werden, 

dass es in dieser Phase möglicherweise Probleme mit dem Ansatz gibt. Daher wird 

die folgende Hypothese aufgestellt: 

H10 Die Aufwandsverteilung der Teilnehmer über den gesamten 

Veranstaltungszeitraum ist nicht konstant. 

H1 Die Aufwandsverteilung der Teilnehmer über den gesamten 

Veranstaltungszeitraum ist konstant. 

Der Ansatz nutzt zur Spezifikation von Software-intensiven eingebetteten Systemen 

Modelle. Die durch den Ansatz entstandene Spezifikation dient den Entwicklern als 

Basis zur Implementierung des Systems. Daher muss das Ergebnis der Methoden 

für die Entwickler verständlich sein. Daher wurde bei der Evaluierung einerseits untersucht, 

ob der vereinfachte Ansatz die Analyse des Systems erleichtert. Andererseits 

sollte durch die Evaluierung untersucht werden, ob der Ansatz das Verständnis 

und die Implementierung des geplanten Systems erleichtert. Dazu wurden folgende 

Hypothesen aufgestellt: 

2 vgl. http://sep.icb.uni-due.de 




H20 Der Ansatz unterstützt nicht die Analyse und Modellierung des Systems. 

H2 Der Ansatz unterstützt die Analyse und Modellierung des Systems. 

H30 Der Ansatz unterstützt nicht das Verständnis und die Implementierung 

des geplanten Systems. 

H3 Der Ansatz unterstützt das Verständnis und die Implementierung des 

geplanten Systems. 

4.1.2 Vorgehensweise 

Die Veranstaltung SEP ist eine Pflichtveranstaltung welche Teil der Curricula der 

Studiengänge Angewandte Informatik – Systems Engineering, Wirtschaftsinformatik 

und Lehramt Informatik ist. In allen Studiengängen liegt die Veranstaltung im zweiten 

Fachsemester. Dementsprechend ist davon auszugehen, dass die teilnehmenden 

Studenten nur wenig bis keine Erfahrung in der Software Entwicklung haben. Daher 

wurden für die Evaluierung vereinfachende Annahmen getroffen. Der Ansatz wurde 

für die Teilnehmer der Veranstaltung in folgenden Punkten vereinfacht: 

es wurden drei rigide Abstraktionsebenen zur Spezifikation genutzt, um den 

Studenten die Abstraktion zu erleichtern, 

und es wurde eine grobe Reihenfolge zur Bearbeitung der Artefakte vorgegeben, 

um den Studierenden ein strukturiertes Vorgehen zu ermöglichen. 

Einen Überblick über die genutzten Artefakte findet sich Abbildung 4-1. 

Überblick 

Abbildung 4-1 Überblick über den vereinfachten Ansatz 3 

Um den Studenten ein strukturiertes Vorgehen zu ermöglichen, wurde ein grober 

Prozess vorgegeben. Die Vorgabe der Reihenfolge beschränkte sich hierbei auf die 

Abstraktionsebenen. Diese wurden im top-down Verfahren bearbeitet. Dabei was es 

den Studierenden jedoch ausdrücklich möglich Artefakte in den anderen Ebenen zu 

ergänzen. 

3 Hierbei handelt es sich um eine in der Veranstaltung genutzte Folie, die auch den Studenten zur 

Verfügung gestellt wurde. 

Lösungsneut rale 

Anforderungen 

Gesamt system • Prosaziele, die das System 

erfüllen soll 

Logisches 

System 

Technisches 

System 

• Zielbaum, enthält 

Prosaziele, definiert Ziele, 

die durch logische 

Komponenten erfüllt 

werden müssen 

• Verfeinert ggf. Prosaziele in 

Hard- und Softgoals 

• Zielbaum, ergänzt um 

technische Ziele 

• Ggf. Verfeinerung logischer 

Ziele und Hard-/Softgoals 

Lösungsbez ogene 

Anforderungen 

• Textuelle Szenarien, 

die die Erfüllung der 

Prosaziel beschreiben 

• Textuelle 

Anforderungen 

• Message Sequence 

Charts in Bezug auf 

das DFD und den 

Szenarien 

• Datenmodell der 

gespeicherten Daten 

• Zuordnung der 

Umsetzung der 

Funktionen auf 

technische 

Komponenten 

Lösungskonzept 

• Kontextmodell 

• Funktionsmodell 

(DFD) 

• Technisches 

Konzept 

Zuletzt geändert: 27.04.2012 10:00 18/36 

8 

© paluno



Auf Basis dieses vereinfachten Ansatzes wurde innerhalb der Veranstaltung SEP 

Methodenanwendbarkeit untersucht. Dazu ist im Folgenden das Evaluierungsvorgehen 

definiert. 

Zur Evaluation von H1 wurden Fragebögen und Protokolle genutzt, die im folgenden 

Abschnitt detailliert beschrieben werden. Zur Evaluierung von H2 und H3 wurden die 

Aufgaben jeder Gruppe zweigeteilt: Zunächst musste jede Gruppe ein System mit 

Hilfe des Ansatzes spezifizieren, womit H2 untersucht wird. Zur Untersuchung von 

H3 war es zudem die Aufgabe jeder Gruppe, die Spezifikation einer anderen Gruppe 

kontinuierlich zu prüfen, also ein Review vorzunehmen. Um eine gewissenhafte Prüfung 

der Spezifikation durch die Probanden zu gewährleisten, wurde zu Beginn des 

Praktikums kommuniziert, dass die prüfende Gruppe die geprüfte Spezifikation implementieren 

musste und die Spezifikation während der Implementierung nicht mehr 

geändert werden durfte. Bei der Vergabe der Programmieraufgaben wurde dementsprechend 

eine Überschneidung der gleichen Programmieraufgabe verhindert, so 

dass jeweils unterschiedliche Aufgaben spezifiziert und überprüft wurden. 

4.1.3 Messinstrument 

Als Messinstrumente wurden zur Messung von H1 wöchentliche Fragebögen und 

Protokolle genutzt. 

In einem wöchentlichen Fragebogen sollten die Probanden ihre subjektive Arbeitsbelastung 

hinsichtlich der Entwicklung eines Systems und dem Review einer Dokumentation 

angeben. Dazu wurde den Probanden eine Vorlage (siehe Abbildung 4-2) zur 

Verfügung gestellt, in der sie ihren aktuellen Aufwand in Minuten der Woche eintragen 

konnten. 

Abbildung 4-2 Vorlage für Protokoll zur Messung des Aufwands 

Zusätzlich zur quantitativen Messung des Aufwands wurde mit Hilfe des Fragebogens 

(siehe Anhang C) auch die subjektive Belastung der Probanden abgefragt. 

Zur Messung von H2 und H3 wurde auf demselben wöchentlichen Fragebogen, der 

auch nach dem Aufwand zur Hypothese H1 genutzt wird, der subjektive Nutzen der 

jeweiligen Artefakte und Konzepte hinsichtlich der Aufgabe der Entwicklung und Prüfung 

der Spezifikation abgefragt. Die jeweiligen Fragebögen wurden wöchentlich um 

die neu vorgestellten Artefakte erweitert, wodurch nach drei Wochen der Fragebogen 

vollständig aufgebaut war. 

Um das Protokoll den jeweiligen Fragebögen der Probanden zuordnen zu können, 

sollten die Probanden einen Code definieren, mit der die Fragebögen und das Protokoll 

einander zugeordnet werden konnten. 

Die Fragen auf den Fragebögen wurden nach einer 5-stufigen Likert Skala abgefragt: 

- Sehr zutreffend 1 

- Zutreffend 2 

- Mittel 3 




- Unzutreffend 4 

- Sehr unzutreffend 5 

Im Rahmen der Aufwandsbefragung wurden die Skala entsprechend angepasst von 

„sehr viel beschäftigt“ (1) bis „sehr wenig beschäftigt“ (5). Wobei noch die zusätzliche 

Antwortmöglichkeit „gar nicht beschäftigt“ hinzugefügt wurde. 

4.1.4 Durchführung 

Die Evaluierung wurde im Sommersemester 2011 in einem Zeitraum über sieben 

Wochen durchgeführt. An der Evaluierung nahmen 57 Studierende teil, von denen 

sich ca. 52% Studierende (30) im zweiten Fachsemester befanden. Weitere 19% 

(11) befanden sich im vierten Fachsemester und 21% (12) im sechsten Fachsemester. 

Die verbleibenden Probanden befanden sich gleichverteilt im ersten, fünften, 

achten, zehnten oder zwölften Fachsemester. Von den Probanden studierten ca. 

54% (31) den Studiengang Angewandte Informatik – Systems Engineering, ca. 28% 

(16) Wirtschaftsinformatik und ca. 16% (10) Lehramt Informatik. Im Rahmen der Veranstaltung 

fanden zwei Präsenztermine pro Woche statt. Der erste Termin fand an 

einem Montag oder Dienstag und der zweite Termin an einem Donnerstag oder Freitag 

statt, wobei der Fragebogen immer am Donnerstag oder Freitag bearbeitet wurde. 

Während die Probanden zu Beginn des Semesters Interesse an der Evaluierung und 

der dahinterstehenden Forschungsfrage zeigten, ist die Motivation im weiteren Verlauf 

der Befragung stark gesunken. Dies wurde z.B. durch Fragen der Probanden 

nach dem Sinn des Ausfüllens des immer gleichen Fragebogens deutlich. Trotzdem 

blieb die Teilnehmerzahl konstant. 

4.2 Ergebnisse der Evaluierung 

In diesem Abschnitt werden die Ergebnisse der Evaluierung zusammenfassend dargestellt, 

beschrieben und interpretiert 4 . Zunächst werden dazu zu den in Abschnitt 

4.1.1 beschriebenen Hypothesen die entsprechenden Fragen in den Fragebögen 

präsentiert. 

4.2.1 Ergebnis und Interpretation zur Hypothese H1 

Zur Messung der Hypothese H1 wurde in den wöchentlichen Fragebögen die Arbeitsbelastung 

der Probanden abgefragt. Tabelle 4-1 zeigt eine Übersicht über die 

Fragen und gibt die Anzahl der gültigen Messwerte über die gesamte Evaluationsdauer 

an. Der Median liegt bei beiden Fragen bei 3. 

Fragestellung # Messwerte Median σ 

332 3 3,64 

Die Arbeitsbelastung für die Entwicklung in dieser 

Woche empfand ich als... 

Die Arbeitsbelastung für das Review in dieser Woche 

empfand ich als... 

Tabelle 4-1 Fragen bezogen auf Hypothese H1 

4 Die Rohdaten werden von den Autoren auf Anfrage zur Verfügung gestellt. 

316 3 2,91 




Abbildung 4-3 zeigt den Mittelwert der Arbeitsbelastung der Probanden durch die 

Entwicklung (rote Kurve) und durch das Review (grüne Kurve) pro Woche. Die 

schwarzen Linien stellen lineare Trendlinien dar. 

5 

4 

3 

2 

1 

Woche 1 Woche 2 Woche 3 Woche 4 Woche 5 Woche 6 Woche 7 

Arbeitsbelastung Entwicklung Arbeitsbelastung Review 

Linear (Arbeitsbelastung Entwicklung) Linear (Arbeitsbelastung Review) 

Abbildung 4-3 Diagramm über die Arbeitsbelastung pro Woche 

Anhand der Trendlinie ist zu erkennen, dass sich die subjektive Arbeitsbelastung der 

Probanden für die Entwicklung und das Review über die Zeit hinweg unterschiedlich 

entwickeln. Bei der Interpretation des Diagramms in Abbildung 4-3 ist dabei zu berücksichtigen, 

dass eine sinkende Kurve eine Steigerung der Arbeitsbelastung darstellt, 

da eine 1 („sehr hoch“) eine Zustimmung zur Aussage darstellt. Dies bedeutet, 

dass die Arbeitsbelastung bei der Entwicklung über die sieben Wochen hinweg ansteigt, 

während die Arbeitsbelastung beim Review abnimmt. Die Steigerung der Arbeitsbelastung 

bei der Entwicklung hängt damit zusammen, dass die Probanden zusätzlich 

zur Spezifikation im Verlauf der Evaluationsphase auch mit der Implementierung 

begonnen haben. Somit spiegelt diese Kurve die kumulierte Arbeitsbelastung 

der Probanden durch die Spezifikation und der Implementierung dar. Dahingegen 

sinkt die Arbeitsbelastung durch das Review im Verlauf der Evaluierung. Dies ist als 

positiv zu bewerten. Eine Erklärungsmöglichkeit kann darin liegen, dass die Probanden 

sich möglicherweise an die Anwendung des Ansatzes gewöhnt haben und 

dadurch ein besseres Verständnis für den Ansatz und somit auch für das Review 

bekommen haben. 

Zur Validierung der Hypothese H1 wäre es wünschenswert, einen Signifkanztest, 

z.B. durch einen T-Test, durchzuführen. Die vorliegenden Daten sind jedoch nicht 

normalverteilt, was durch einen Kolmogorov-Smirnov- und Shapiro-Wilk-Test festgestellt 

wurde. Daher lassen sich die Daten nur qualitativ interpretieren. Die lineare 

Trendlinie der Arbeitsbelastung durch das Review weist nur eine minimale Steigung 

auf. Daher kann hier davon ausgegangen werden, dass die Arbeitsbelastung über 

die Zeit hinweg relativ konstant blieb. Wie schon oben beschrieben, steigt die Arbeitsbelastung 

aus o.g. Gründen jedoch bei der Entwicklung. Aufgrund der vorliegenden 

Daten ist jedoch keine Bereinigung dieses Einflusses an dieser Stelle möglich. 

Es wäre jedoch möglich, dass nach einer Bereinigung der Daten, eine ebenfalls 

nahezu konstante Arbeitsbelastung bei der Entwicklung entstehen würde. 

Insgesamt lässt sich somit sagen, dass die Hypothese H1 im Hinblick auf die Arbeitsbelastung 

beim Review gehalten werden kann. Zu der Arbeitsbelastung hinsicht- 




lich der Entwicklungsaktivitäten, ohne Berücksichtigung der Implementierung, kann 

keine definitive Aussage getroffen werden. 


Zur Überprüfung der Hypothese H2 wurden die in Tabelle 4-2 gelisteten Fragen 

ebenfalls wöchentlich abgefragt. Für jedes Item sind die Anzahl der gültigen Messwerte, 

die Mittelwerte sowie die relative Zustimmung der Probanden zu der Frage 

angegeben. Als Zustimmung wird dabei ein Wert kleiner oder gleich 2 gewertet. Die 

Fragen adressieren die Diskussion und Kommunikation der Probanden untereinander. 

Eine Diskussion in der Gruppe deutet darauf hin, dass der Ansatz den Probanden 

hilft und unterstützt, das System zu analysieren und zu modellieren. 

Da die Stichproben nicht normalverteilt sind, ist eine Signifikanzanalyse auf den Ergebnissen 

nicht möglich. 

Alle Fragen aus Tabelle 4-2 erhalten etwa 50% Zustimmung, wobei der Median (bis 

auf Frage 4) bei 3 liegt. Das bedeutet, dass ca. die Hälfte der Probanden empfunden 

hat, dass sie durch den Ansatz überdurchschnittlich unterstützt wurden. Der Median 

bei den Fragen 1 bis 3 und 5 liegt bei 3. Dies bedeutet, dass die Probanden der Aussage 

weder zustimmen, noch die Aussage ablehnen. Lediglich Frage 4 hat einen 

Median 2. Auch hat diese Frage eine höhere Zustimmung. Dies deutet darauf hin, 

dass die Probanden das subjektive Gefühl haben, dass sie durch die Anwendung 

des Ansatzes das System besser verstanden haben. 

Zusammenfassend lässt sich aufgrund der vorliegenden Daten die Hypothese H2 

weder annehmen noch verwerfen. Aufgrund der hohen Zustimmungswerte lässt sich 

jedoch eine Tendenz zur Zustimmung der Hypothese feststellen. 

Nr Fragestellung # Messwerte Median σ Zs 

1 Die Methodik hat eine zielgerichtete Diskussion 

unterstützt. 

321 3 0,874 49,5% 

2 Die Methodik hat mir geholfen meine Gedanken 

über die Aufgabe zu kommunizieren. 

319 3 0,873 48,6% 

3 Die Methodik hat mir geholfen, zielgerichtete 

Fragen zu stellen. 

328 3 0,89 44,8% 

4 Durch die Anwendung der Methodik habe ich 

das Gefühl, das System besser verstanden zu 

haben. 

307 2 0,933 54,1% 

5 Ich habe das Gefühl, dass ich mit der Methodik 

Sicherheit im Umgang mit der Aufgabenstellung 

bekommen habe. 

302 3 0,947 47,4% 

Tabelle 4-2 Fragen zur Evaluierung von Hypothese H2 


Die Hypothese H3 untersucht, ähnlich wie die Hypothese H2, inwiefern der untersuchte 

Ansatz das Verständnis und die Implementierung des Systems unterstützt. 

Dazu wurden zum einen Fragen hinsichtlich der Diskussion innerhalb der Gruppe 

gestellt (Fragen 6-8). Zusätzlich wurde nach der Verständlichkeit der geprüften Spezifikation 

gefragt. 

Zunächst ist hier die geringere Anzahl an Messpunkten auffällig. Dies lässt sich jedoch 

damit erklären, dass ein Review der Spezifikation z.B. in der ersten Woche 

nicht möglich und nötig war, wodurch die entsprechenden Fragen nicht beantwortet 

werden konnten. 

Für die Fragen 6 bis 8 sowie 11 bis 14 haben die Probanden weder der Aussage zugestimmt, 

noch diese abgelehnt. Daher ist davon auszugehen, dass zwar der Ansatz 

das Verständnis und die Implementierung des Systems nicht zwangsläufig unter- 




stützt, aber das Verständnis als auch Implementierung nicht explizit negativ beeinflusst. 

Bezüglich der Hypothese 3 zeigt sich keine eindeutige Tendenz, sie kann nicht 

beibehalten aber auch nicht eindeutig abgelehnt werden. 

Im Unterschied dazu wird den Fragen 9 und 10 hingegen zugestimmt (63,8% bzw. 

55,9%). Somit kann H3 beibehalten werden: die Spezifikation ist für Probanden 

nachvollziehbar. 

Die Spezifikation besteht aus den Modellen, die durch die Anwendung des Ansatzes 

entstanden sind. Daher ist davon auszugehen, dass durch die in der Spezifikation 

genutzten Modelle, das Verständnis der Spezifikation erhöht wurde. Daher hat die 

Nutzung des Ansatzes das Verständnis des Systems bzw. der Spezifikation erhöht. 

Frage 10 fokussiert auf die Nutzung der Abstraktionsebenen durch den Ansatz. Mit 

einer Zustimmung zu dieser Aussage bestätigten die Probanden, dass ihnen die 

Abstraktionsebenen aus der Sicht der Reviewer geholfen haben, das zu spezifizierte 

System zu verstehen. Dieser Aussage stimmen 63,8% der Probanden zu. Daher ist 

davon auszugehen, dass insbesondere die Nutzung von Abstraktionsebenen durch 

den Ansatz die Verständlichkeit hinsichtlich der Spezifikation erhöht. Dies wird auch 

durch Frage 14 gestützt, da nur wenige Probanden Rückfragen bzgl. der Spezifikation 

hatten. 

Zusammenfassend lässt sich allerdings nicht sagen, ob die Hypothese H3 bestätigt 

oder verworfen werden muss. Aufgrund der nicht vorliegenden Normalverteilung der 

Stichproben lässt sich kein aussagekräftiger Hypothesentest durchführen. Es lässt 

sich jedoch ein positiver Trend feststellen, der zu einer Bestätigung der Hypothese 

führen könnte. 

Nr Fragestellung # Messwerte Median σ Zs 

6 Die Methodik hat eine zielgerichtete Diskussion 

unterstützt. 

286 3 0,866 45,4% 

7 Die Methodik hat mir geholfen meine Gedanken 

über die Aufgabe zu kommunizieren. 

283 3 0,894 41,9% 

8 Die Methodik hat mir geholfen, zielgerichtete 

Fragen zu stellen. 

276 3 0,895 39,2% 

9 Die Spezifikation ist für mich als Reviewer nachvollziehbar. 

278 2 0,845 63,8% 

10 Die Abstraktionsebenen haben mir als Reviewer 

geholfen das zu entwickelnde System zu verstehen. 

235 2 0,894 55,9% 

11 Die Einteilung in lösungsneutrale Anforderungen, 

lösungsbezogene Anforderungen und Lösungskonzept 

haben für mich als Reviewer das 

Verständnis der Spezifikation erhöht. 

276 3 0,904 41,6% 

12 Durch die Methodik war es mir möglich, ein 

strukturiertes Review durchzuführen. 

278 3 0,866 43,1% 

13 Durch die Methodik war es mir als Reviewer 

möglich, ein strukturiertes Feedback an die andere 

Gruppe zu geben. 

273 3 0,903 47,8% 

14 Ich hatte viele Rückfragen an die andere Gruppe 

bezüglich ihrer Spezifikation. 

272 3 1,008 27,5% 

Tabelle 4-3 Fragen zur Evaluierung der Hypothese H3 




5 Zusammenfassung 

Im Rahmen von ZP-AP2 wurden mehere Evaluationsaktivitäten zur Prüfung der Akzeptanz 

und Anwendbarkeit des modellbasierten Requirements-Ansatzes durchgeführt. 

Diese Evaluationen entstanden durch Kooperationen mit Anwendungsprojekten, 

anhand von Fallstudien sowie durch eine Fragebogenstudie und eine Benutzerstudie. 

: 

In einer Fragebogenstudie zur Methodenakteptanz wurden Praktiker des AWP-AU 

befragt, inwiefern 

der modellbasierte Requirements-Engineering-Ansatz von Praktikern in der 

Industrie akzeptiert wird; 

der Ansatz richtige, hochqualitative und nützliche Informationen für die Arbeit 

der Praktiker in der Industrie bereitstellt; und 

Welche Bereitschaft bei Praktikern in der Industrie existiert, den Ansatz einzusetzen. 

Die Ergebnisse der Fragebogenstudie zur Methodenakzeptanz hat ergeben, dass 

Praktiker den Ansatz tendenziell als positiv empfinden. Insbesondere ist hervorzuheben, 

dass Praktiker den Ansatz als einfach anwendbar empfinden und der Ansicht 

sind, dass die richtigen notwendigen Artefakte durch den Ansatz zur Verfügung gestellt 

werden. Allerdings zeigt die Evaluierung, dass zur Anwendung in der Praxis 

formales Training notwendig ist. Hinsichtlich der Qualität der Ergebnisse evaluieren 

die Teilnehmer den RE-Ansatz ebenfalls positiv: der Ansatz erlaubt die Spezifikation 

von Artefakten mit hoher Qualität und Genauigkeit. Allerdings gibt es Verbesserungspotential 

bei der Verwendung unterschiedlicher Abstraktionsstufen (vgl. 

[STP11b]). Ferner zeigt sich, dass Praktiker tendenziell bereit sind, den Requirements-Engineering-Ansatz 

einzusetzen. Es bedarf allerdings weiteren Beispielen zur 

Anwendbarkeit des Ansatzes in industrieller Praxis. 

Die Evaluation der Methodenanwendbarkeit erfolgte durch eine wöchentliche Befragung 

in einem Softwarepraktika an der Universität Duisburg-Essen, welches von 

Studierenden im zweiten Fachsemester besucht wurde. Innerhalb dieser Befragung 

wurden die Probanden regelmäßig nach ihrer aktuellen Arbeitsbelastung und der 

Verständlichkeit der Spezifikationen, die mit Hilfe des RE-Ansatzes erstellt worden 

sind, befragt. 

Aufgrund der vorliegenden Daten und den durchgeführten Analysen bei der Evaluierung 

zur Methodenanwendbarkeit lassen sich keine definitiven Aussagen über die 

Hypothesen treffen. Hypothese H1 kann hinsichtlich der Review Aktivitäten beibehalten 

werden. Das bedeutet, dass die Arbeitsbelastung der Probanden durch die Anwendung 

der Methode über den Entwicklungszeitraum konstant geblieben ist. Eine 

Aussage hinsichtlich der Arbeitsbelastung bei der Entwicklung kann jedoch gemacht 

werden, wobei es hier eine positive Tendenz hin zur konstanten Arbeitsbelastung 

gibt, womit die Hypothese H1 bestätigt werden würde. 

Die Hypothesen H2 und H3 konnten weder verworfen noch angenommen werden. 

Bei beiden Hypothesen konnte jedoch eine positive Tendenz festgestellt werden. 

Insgesamt lassen sich die folgenden Aussagen über den analysierten Ansatz festhalten: 


analysierende System besser verstanden zu haben. 

Die mit Hilfe des Ansatzes erstellte Dokumentation eines Systems ist nachvollziehbar. 






Andere Aussagen können weder bestätigt noch wiederlegt werden. 

Aufgrund einer nicht vorliegenden Normalverteilung der Stichproben (festgestellt 

durch den Kolmogorov-Smirnov- und Shapiro-Wilk-Test), konnten die vorliegenden 

Daten nicht auf ihre Signifikanz getestet werden. Dies könnte daran liegen, dass die 

Fragebögen von den Probanden nicht gewissenhaft ausgefüllt worden sind. Dies 

wird auch von einigen Aussagen der Probanden unterstützt, die die Probanden in 

einem Freitextfeld auf den Fragebögen abgeben konnten. 

Die in diesem Dokument vorgestellten Evaluierungsarbeiten des Requirements- 

Engineering-Ansatzes des ZP-AP2 haben eine Vielzahl von Ergebnissen hervorgebracht, 

die zur Verbesserung des Ansatzes beigetragen haben bzw. in Zukunft zur 

Verbesserung beitragen werden. So haben die Ausarbeitungen der Fallstudien zu 

domänenspezifischen Anpassungen des Vorgehensmodells und der Artefakttypen 

des modellbasierten RE-Ansatzes geführt. Ein Beispiel für eine solche Anpassung ist 

in Anhang D gegeben. Ferner zeigen die Evaluierungen zur Methodenakzeptanz und 

Methodenanwendbarkeit ein tendenziell positives Bild. Allerdings bleiben weitere 

Verbesserungsmöglichkeiten bestehen. Um diese genauer zu untersuchen sind weitere, 

detailliertere Studien notwendig. 




6 Literaturverzeichnis 

[CoSt08] Corbin J, Strauss A (2008) Qualitative Research, 3 rd Ed. Sage 

Publications, California, USA. 

[DBW89] Davis, F. D.; Bagozzi, R. P.; Warshaw, P. R. (1989). User acceptance 

of computer technology: A comparison of two theoretical 

models. Management Science 35:982-1002. 

[LSP07] Lauenroth, Kim; Sikora, Ernst; Pohl, Klaus. Positive Effekte von 

Szenarien und Features in einem Softwarepraktikum. In: Andreas 

Zeller, Marcus Deininger (Eds.): Software Engineering im Unterricht 

der Hochschulen, SEUH 10, Stuttgart, Germany, 22. und 23. 

Februar 2007. dpunkt 2007, ISBN 3-89864-458-8. 

[MoBe91] Moore, G. C.; Benbasat, I. (1991). Development of an instrument 

to measure the perceptions of adopting an information technology 

innovation. Information Systems Research 2:192-222. 

[Moody2009] Moody, Daniel. The “Physics” of Notations: Toward a Scientific 

Basic for Constructing Visual Notations in Software Engineering. 

In: IEEE Transactions on Software Engineering 35 (6). 2009. 

[Pohl10] Pohl, Klaus (2010). Requirements Engineering – Foundations, 

Principles, Techniques. Springer, Germany/USA. 

[SiPo10] Sikora, Ernst; Pohl, Klaus. Evaluation eines modellbasierten Requirements-Engineering-Ansatzes 

für den Einsatz in der Motorsteuerungs-Domäne. 

Proceedings of ENVISION2020 2010. 

[SPES09a] Lauenroth, Kim; Sikora, Ernst; Stallbaum, Heiko; Tenbergen, Bastian. 

Initialer modellbasierter Requirements Engineering Ansatz für 

Embedded Systems. SPES 2020 Teilergebnis, Version 0.92 vom 

13.11.2009. 

[SPES10a] Lauenroth, Kim; Gabrisch, Sebastian; Sikora, Ernst; Tenbergen, 

Bastian. Beschreibung der Durchführung der Studie zum Stand 

der Praxis im Requirements Engineering für Embedded Systems. 

SPES 2020 Teilergebnis, Version 1.0 vom 16.07.2010. 

[SPES10b] Daun, Marian; Sikora, Ernst; Lauenroth, Kim. Stand der Praxis im 

modellbasierten Requirements Engineering. SPES 2020 Deliverable 

D2.1.A, 2010. 

[SPES10c] Stallbaum, Heiko Sikora, Ernst; Lauenroth, Kim; Tenbergen, Bastian. 

Stand der Praxis zur Prüfungs von Anforderungen. SPES 

2020 Deliverable D2.2.A, 2010. 

[SPES10d] Tenbergen, Bastian; Sikora, Ernst; Lauenroth, Kim. Stand der 

Praxis zur Spezifikation von Echtzeitanforderungen. SPES 2020 

Deliverable D2.3.A, 2010. 

[SPES10e] Sikora, Ernst; Gabrisch, Sebastian: Stand der Praxis – Verzahnung 

von Requirements Engineering und Architekturentwurf von 

Embedded Systemen. SPES Deliverable D2.4.A, 2010. 




[SPES11a] Avramova, Nadezhda; Tenbergen, Bastian. Untersuchung des 

State-of-the-Art zur Erstellung von Domänenspezifischen Modellierungssprachen 

und UML/SysML-Profilen. SPES 2020 Teilergebnis 

des ZP-AP2, Version 1.0 

[SPES11b] Tenbergen, Bastian; Daun, Marian. UML/SysML-Profil und MDG- 

Plug-In für Enterprise Architect zur Modellierung von KAOS- 

Zieldiagrammen auf Basis von UML/SysML. Version 1.2 vom 

13.10.2010 

[SPES11c] Avramova, Nadezhda; Daun, Marian; Tenbergen, Bastian; Weyer, 

Thorsten. SysML-Profil und MDG-Plug-In für Enterprise Architect 

zur Szenariomodellierung auf Basis von SysML. SPES 2020 Teilergebnis 

des ZP-AP2, Version 1.0 vom 02.03.2011 

[SPES11d] Daun, Marian; Gabrisch, Sebastian; Tenbergen, Bastian; Weyer, 

Thorsten. SysML-Profil und MDG-Plug-In für Enterprise Architect 

zur Modellierung von lösungsorientierten Anforderungen auf Basis 

von SysML. SPES 2020 Teilergebnis des ZP-AP2, Version 1.1 

vom 12.04.2011 

[SPES11e] Tenbergen, Bastian; Daun, Marian; Bohn, Philipp. Leitfaden und 

Projektschablonenbeschreibung für die modellbasierte Dokumentation 

von Anforderungen und Entwurf für Embedded Systems 

über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen 

Modellierungswerkzeugs. SPES Deliverable D2.4B, Version 

1.0 vom 29.04.2010. 

[SPES11f] Eder, Sebastian; Vogelsang, Andreas; Feilkas, Martin; Gezgin, 

Tayfun; Daun, Marian; Tenbergen, Bastian; Weyer, Thorsten. 

Seamless Modeling of an automation example using the SPES 

methodology. SPES Teilergebnis, Draft Version 0.3 vom 

27.05.2011. 

[SPES11g] Fasse, Friedrich-W.; Lauenroth, Kim; Heuer, André: Durchführung 

der Evaluierung. SPES Deliverabe D-EN-2.1b, Version 1.0. 

[SPES11h] Laskowski, Michael; Fasse, Friedrich-W.; Heuer, André: Zusammenfassung 

der Evaluierung. SPES Deliverable D-EN-2.1c. Version 

1.0. 

[SPES12a] Daun, Marian; Fockel, Markus; Holtmann, Jörg, Tenbergen, Bastian. 

Integration der Requirements-Engineering-Ansätze 

von ZP-AP2 und AWP-AU-AP3. SPES 2020 Teilergebnis, Januar 

2012. 

[SPES12b] Rzepka, Mark; Bandyszak, Thorsten. Fallbeispiel Flugsteuerungssystem. 

SPES 2020 Teilergebnis v1.0 vom 11.01.2012. 

[SPES12c] Dieudonne, Laurent; Haider, Oliver. Fallbeispiel AV-FB1: Frühe 

Validierung der Anforderungen (Testbarkeit) Teil 2: Modellbasierte 

Anforderungen des Flugsteuerungssystems Bewertung. SPES 

2020 Teilergebnis vom 16.01.2012 v1.0. 

[SPES12d] Tenbergen, Bastian; Daun, Marian; Gabrisch, Sebastian: Fallbeispiel 

Luftsystem. SPES 2020 Teilergebnis v1.0 vom 19.01.2012. 

[SPES12e] Daun, Marian; Föcker, Felix; Tenbergen, Bastian: Fallbeispiel Klimakontrollsystem. 

SPES 2020 Teilergebnis vom 20.01.2012 v1.0. 




[STP10] Sikora, Ernst; Tenbergen, Bastian; Pohl, Klaus (2010). Modellbasiertes 

Requirements Engineering – Eine Situationsanalyse zum 

Stand der Praxis. Softwaretechnik Trends 30(1). 

[STP11a] Sikora, Ernst; Tenbergen, Bastian; Pohl, Klaus (2011). Requirements 

Engineering – An Investigation of Industry Needs. Proceedings 

of Requirements Engineering: Foundations for Software 

Quality REFSQ 2011. 

[STP11b] Sikora, Ernst; Tenbergen, Bastian; Pohl, Klaus (2011). Industry 

Needs and Research Directions in Requirements Engineering for 

Embedded Systems. Requirements Engineering Journal. DOI: 

10.1007_s00766-011-0144-x. 2011. 

[TAM1] Davis, F. D. (1989). Perceived usefulness, perceived ease of use, 

and user acceptance of information technology. MIS Quarterly 

13:319-340. 

[TAM2] Venkatesh, V.; Davis, F. D. (2000). A theoretical extension of the 

technology acceptance model: Four longitudinal field studies. Management 

Science 46:186-204. 

[TAM3] Venkatesh, V.; Bala, H. (2008). Technology Acceptance Model 3 

and a Research Agenda on Interventions. Decision Sciences 

39(2): 273-315. 

[TTF] Goodhue, D. (1998). Development and Measurement Validity of a 

Task-Technology Fit Instrument for User Evaluations or Information 

Systems. Decision Sciences 29(1):105-138 

[VMDD03] Venkatesh, V.; Morris, M. G.; Davis, G. B.; Davis, F. D. (2003). 

Use acceptance of information technology: Toward a unified view. 

MIS Quarterly 27:425-478. 




7 Anhang A – Möglichkeiten zur domänenspezifischen 

Anpassung des RE-Ansatzes auf Basis der Ergebnisse 

von Fallbeispiel Flugsteuerungssystem 

In diesem Anhang werden Möglichkeiten zur domänenspezifischen Anpassung des 

Requirements Engineering-Ansatzes (im Folgenden RE-Ansatz genannt) aufgezeigt. 

Diese Anpassungsmöglichkeiten stellen keine Evaluation im eigentlichen Sinn dar, 

es sind generell Erkenntnisse die auf den gesammelten Erfahrungen bei der Modellierung 

eines Fallbeispiels basieren. Diese Erkenntnisse werden zusätzlich durch 

eine Bewertung von domänenerfahrenen Industriepartnern angereichert. Deswegen 

erschien es wertvoll die Anpassungsmöglichkeiten zusätzlich im Anhang zu beschrieben. 

Die vorgestellten Anpassungsmöglichkeiten sind das Ergebnis des Fallbeispiels 

Flugsteuerungssystem [SPES12b] und des das Fallbeispiel bewertenden Analysedokumentes 

[SPES12c]. Dieses Fallbeispiel ist eines der Fallbeispiele, die zur Evaluierung 

des RE-Ansatzes aufgesetzt wurden (siehe hierzu Abschnitt 2.3.1). Das Fallbeispiel 

Flugsteuerungssystem (auch „1-D Flight Control System Specification“ genannt) 

verfolgt das Ziel, Anforderungen an ein Avionik-System, ein beispielhaftes und in der 

Funktion reduziertes Flugsteuerungssystem, modellbasiert nach dem RE-Ansatz zu 

spezifizieren. Die speziellen Rahmenbedingungen der Avionik-Domäne stellen den 

als theoretische Grundlage dienenden RE-Ansatz vor neue Herausforderungen, da 

spezielle Sicherheitsanforderungen und darauf basierende Entwurfsentscheidungen 

bei der Modellierung berücksichtigt werden müssen. Nicht zuletzt spielen auch die 

umfangreichen Erfordernisse im Zusammenhang mit der Zertifizierung, entsprechend 

den in der Avionik vorgeschriebenen Sicherheitsstandards, eine wichtige Rolle. Die 

Erkenntnis, die aus der modellbasierten Spezifikation des Flugsteuerungssystems 

gewonnen wird, zeigt, dass der angewandte RE-Ansatz um einige domänenspezifische 

Aspekte der Avionik ergänzt bzw. angepasst werden sollte. Die Möglichkeiten 

zur Anpassung an domänenspezifische Avionikaspekte werden in diesem Anhang 

vorgestellt. 

Dieser Anhang ist folgenderweise aufgebaut: Im nächsten Abschnitt wird das Fallbeispiel 

Flugsteuerungssystem mit seinen Ergebnissen vorgestellt, wobei ein besonderes 

Augenmerk auf die Herausforderungen der sicherheitskritischen Avionik-Domäne 

gerichtet wird. Anschließend werden im Abschnitt 7.2 die Möglichkeiten zur Anpassung 

des RE-Ansatzes aufbauend auf den Ergebnissen und Erfahrungen, die im 

Fallbeispiel gesammelt worden sind, beschrieben. 

7.1 Fallbeispiel Flugsteuerungssystem und die Herausforderungen 

der sicherheitskritischen Avionik-Domäne 

In diesem Abschnitt wird das Fallbeispiel Flugsteuerungssystem, sowie die mit der 

Domäne des Fallbeispiels verbundenen Herausforderungen beschrieben. Das Fallbeispiel 

ist Teil der übergeordneten Avionik-Fallstudie und gehört zum Teilbereich 

der Modellierung und frühen Validierung von Anforderungen. Das Fallbeispiel wurde 

von dem Unternehmen Liebherr Aerospace in Zusammenarbeit mit der Universität 

Duisburg-Essen getragen und ausgearbeitet. Das Fallbeispiel besteht aus folgenden 

vier Ergebnissen: (1) textuelle Spezifikation (2) modellbasierte Spezifikation (3) Beschreibung 

der modellbasierten Spezifikation [SPES12b] (4) Analyse der modellbasierten 

Spezifikation [SPES12c]. 

Das Fallbeispiel verfolgt das Ziel, Anforderungen an ein Avionik-System, hier ein beispielhaftes 

Flugsteuerungssystem, modellbasiert zu spezifizieren; dies bildet die 




Grundlage für die Betrachtung der übergeordneten Forschungsgegenstände Modellierung, 

Frühvalidierung und Testbarkeit von Anforderungen. Aus organisatorischer 

Sicht wurden die zur Ausarbeitung des Fallbeispiels notwendigen Aufgaben klar abgegrenzt 

und den beiden Partnern zugewiesen; die Firma Liebherr lieferte mit der 

textuellen Spezifikation des Flugsteuerungssystems den Input für die anschließende 

Modellierung der spezifizierten Anforderungen, welche von Mitarbeitern der Universität 

Duisburg-Essen durchgeführt wurde. Die Schritte wurden nicht einmalig, sondern 

in mehreren Iterationen und unter kontinuierlichem Austausch von Informationen 

zwischen beiden Seiten ausgeführt. Durch eine gegenseitige Qualitätssicherung der 

beiden Dokumente bzw. Artefakte wurde eine hohe Qualität der textuellen Anforderungen 

und der Modelle sichergestellt. 

Bei dem spezifizierten „1-D Flight Control System“ handelt es sich um ein hypothetisches 

Flugsteuerungssystem, das den Flug des Flugzeugs steuert und dazu keinerlei 

mechanische Verbindung zwischen den Eingaben des Piloten und den Steuerflächen 

benötigt („fly by wire“). Zur Komplexitätsreduktion dient das System lediglich 

der Steuerung des Flugzeugs entlang der Nickachse; die zwei weiteren Achsen des 

zugrunde liegenden Koordinatensystems, Roll- und Gierachse, werden nicht berücksichtigt. 

Außerdem konzentriert sich die Spezifikation des hypothetischen Flugsteuerungssystems 

auf die Steuerung des Flugzeugs in der Luft, d. h. Start und Landung 

des Flugzeuges werden nicht betrachtet. 

Eine Besonderheit der Avionik-Domäne stellen die Safety-Anforderungen dar. Aufgrund 

der erforderlichen Sicherheit aller am Fluge beteiligten Personen, der extremen 

physikalischen Rahmenbedingungen und der daraus resultierenden hohen Anforderungen, 

sowohl an Hard- und Software-Bauteile des Flugzeugs als auch an die 

Qualifikation und Aufmerksamkeit des Piloten, unterliegen Avionik-Systeme speziellen 

regulatorischen Rahmenbedingungen und Qualitätsanforderungen. Die Verlässlichkeit 

von Avionik-Systemen hat dabei eine vorrangige Bedeutung. Da besonders 

Flugsteuerungssysteme im Hinblick auf einen sicheren Flug als kritisch einzustufen 

sind, wird ebenfalls eine sehr hohe Integrität dieser Avionik-Systeme erwartet. Entsprechend 

muss die Eintrittswahrscheinlichkeit von Fehlern extrem gering sein, 

weswegen beispielsweise redundant ausgelegte Systemkomponenten oder redundante 

Informationsübertragungswege benötigt werden. An dieser Stelle wird auf den 

DO-178B-Standard verwiesen, der sich speziell auf die Entwicklung von Avionik- 

Software bezieht. 

Um die Ursachen für die in den genannten Sicherheitsaspekten begründeten, speziellen 

Entwurfs-Entscheidungen nachvollziehbar zu machen, werden Safety- 

Anforderungen im Rahmen der modellbasierten Spezifikation [SPES12b] in dedizierten 

Diagrammen abgebildet. Die Modellierung von Redundanzen ist außerdem eine 

der größeren Herausforderungen der Fallstudie und wird entsprechend mittels erweiterten 

Modellierungstechniken behandelt. 

Die nach dem RE-Ansatz modellierten Anforderungen wurden abschließend vom 

SPES-Industriepartner Liebherr Aerospace auf die Eignung für den praktischen Einsatz 

in der sicherheitskritischen Avionik-Domäne bewertet. Das Ergebnis dieser Bewertung 

wird im Dokument [SPES12c] festgehalten. Diese Bewertung dient als Anregung 

für die Erarbeitung von Möglichkeiten zur Avionik-spezifischen Anpassung 

des RE-Ansatzes, die im nächsten Abschnitt vorgestellt werden. 

7.2 Erkannte Problembereiche und Verbesserungsvorschläge 

In diesem Abschnitt werden die Möglichkeiten zur domänenspezifischen Anpassung 

des RE-Ansatzes auf Basis der Ergebnisse des oben beschriebenen Fallbeispiels 

Flugsteuerungssystem vorgestellt. Die Hauptmotivation hierfür liefert das Analysedo- 




kument [SPES12c] in dem die in der Fallstudie erstellten Anforderungsmodelle auf 

Eignung für den Einsatz in der Avionik-Domäne bewertet worden sind. Dabei werden 

nur die Punkte aus dem Analysedokument berücksichtigt, die den RE-Ansatz vor 

neuen Herausforderungen stellen. Die meisten restlichen Punkte aus dem Analysedokument 

sind auf konkrete Modellierungsprobleme innerhalb der Fallstudie nur bezogen 

und lassen sich durch eine Korrektur der Fallstudienmodelle beheben. 

Im den folgenden Unterabschnitten werden die einzelnen Anpassungsmöglichkeiten 

geschildert, indem jeweils das erkannte Problembereich und dazu ein Verbesserungsvorschlag 

beschrieben werden. 

7.2.1 Modellierung von Redundanzen 

Problem: Im Bereich der Avionik wird eine dedizierte Berücksichtigung von Redundanzen 

in den Anforderungs- und Entwurfsmodellen benötigt; der RE-Ansatz liefert 

hierfür keine konkreten Anweisungen. Im Rahmen der Fallstudie wurde eine initiale 

Technik zur Modellierung von Redundanzen prototypisch ausgearbeitet und eigesetzt. 

So hat es sich bezüglich der Lesbarkeit der Diagramme bewährt, Redundanzen 

zusätzlich zu einer redundanzfreien Perspektive zu modellieren und – falls möglich 

– von einer eindeutigen Identifikation redundanter Systembestandteile abzusehen, 

um den Diagrammen einen allgemeingültigen Charakter zu verleihen (für Einzelheiten 

über die prototypische Technik siehe [SPES12b] und dort insbesondere 

das Kapitel 18). 

Bei der Bewertung der Modelle hat sich jedoch herausgestellt, dass die prototypische 

Technik nicht ausreichend ist, und so ist die Redundanz immer noch „zu komplex 

dargestellt. Warum müssen die redundanten Elemente dupliziert werden? […] Nur in 

wenigen Fällen sollte eine Duplikation der grafischen Elemente erscheinen. Z.B. 

wenn ein Requirement die Herkunft von Signalen explizit benutzt. Dann müssen die 

Signalnamen eindeutig identifiziert werden.“ [SPES12c] 

Verbesserungsvorschlag: Es müssen noch konkrete Regeln oder Heuristiken zur 

Behandlung von Redundanzen als Anpassung/Ergänzung des Ansatzes definiert 

werden. Insbesondere wird vorgeschlagen Modellierungskonstrukte wie 

„SysML/UML-“{Constraint}“ oder ein “Tagged-Value {Redundant = xxx}““ [SPES12c] 

zu verwenden. 

7.2.2 Modellierung von Safety-Anforderungen 

Problem: „Der verwendete RE-Ansatz sieht keine dedizierte Betrachtung von Safety- 

Anforderungen vor. Dies ist im Hinblick auf das spezifizierte Flugsteuerungssystem 

problematisch, da den Safety-Anforderungen, bei sicherheitskritischen Avionik- 

Systemen eine besondere Bedeutung zukommt. Mit ihnen wird u. a. die Einführung 

von redundanten Systemkomponenten begründet.“ [SPES12b] 

„Zudem ist nicht immer nachvollziehbar durch welche Modellierungsaspekte (Control/Monitor-Architektur, 

Redundanzen, …) die […] Safety-Requirements im Design 

umgesetzt und abgedeckt werden.“ [SPES12c] 

Verbesserungsvorschlag: In der Fallstudie wurde initialerweise eine einfache Modellierungstechnik 

der Safety-Anforderungen mittels SysML- 

Requirementsdiagrammen aufgesetzt (siehe [SPES12b] und dort u.a. Abschnitt 4.3). 

Diese Technik könnte weiterentwickelt werden, um beispielsweise die Zuordnung 

von Fehlertoleranzmaßnahmen zu Safety-Anforderungen expliziter darzustellen. 




7.2.3 Explizite Dokumentation der Nachvollziehbarkeit zwischen verschiedenen 

Artefakten, Modellen und Modellelementen 

Problem: „Die Traceability-Methodik sollte […] erläutert werden. Gegebenenfalls ist 

diese durch die Namensgebung vorhanden. Dann sollten aber Aussagen bzgl. des 

Aufbaus (Pre-/Suffix), … dargestellt werden. Empfohlen wird jedoch die Verwendung 

von Tracepoints und Verlinkungstabellen, da sich diese Mittel in der Praxis sehr bewährt 

haben (hohe Eindeutigkeit, geringe Verwechslungsgefahr, einfache Handhabung, 

…). 

Ohne eine eindeutige und einfache Verlinkung von einzelnen Requirements, ist die in 

der Luftfahrt geforderte Nachweisführung bzgl. Erfüllung und Verifikation der Anforderungen 

nur schwer umsetzbar.“ [SPES12c] 

Verbesserungsvorschlag: Es gibt konkrete Überschneidungen zwischen verschiedenen 

Artefakttypen, die im RE-Ansatz ausgenutzt werden. Diese Überschneidungen 

stellen den Übergang zwischen den Artefakten dar. Die explizite Darstellung der 

Übergänge müsste noch weiter ausgebaut werden. Ein Beispiel hierfür wird in Abschnitt 

2.9 in [SPES12c] vorgestellt. 

7.2.4 Stärkere Integration von natürlichsprachlichen Anforderungen 

und Anforderungsmodellen 

Problem: „Ohne eine eindeutige und einfache Identifizierung von einzelnen Requirements, 

ist die in der Luftfahrt geforderte Nachweisführung bzgl. Erfüllung und Verifikation 

der Anforderungen nur schwer umsetzbar.“ [SPES12c] 

Dabei erleichtert die traditionell an textuellen Dokumenten orientierte Nachweisführung 

erheblich, wenn die Anforderungen gleichzeitig neben den Anforderungsmodellen 

auch mittels textuellen Anforderungen spezifiziert werden. So könnten die Anforderungsmodelle 

den Entwicklungsprozess unterstützen, und die textlichen Spezifikationen 

den Zertifizierungsprozess vereinfachen. 

Verbesserungsvorschlag: Der RE-Ansatz macht genaue Angaben, an welchen 

Stellen schablonenbasierte, komplementäre textuelle (natürlichsprachliche) Anforderungen 

eingesetzt werden können/müssen. Die praktischen Erfordernisse gehen 

aber über den komplementären Einsatz von Anforderungsmodellen und natürlichsprachlichen 

Anforderungen hinaus und Zielen auf parallele und gleichwertige 

Entwicklung von beiden Artefaktentypen. Hierbei wäre eine besondere Herausforderung 

(und ggf. auch ein Nachteil) die Synchronität der beiden Artefaktentypen im 

Laufe eines Entwicklungsprojektes zu erhalten. 

7.2.5 Klarere Trennung von Anforderungen und Design 

Problem: „Die Unterscheidung zwischen Anforderung und Design sollte ggf. klarer 

dargestellt werden.“ [SPES12c] 

Verbesserungsvorschlag: Ein Vorschlag zur klareren Trennung entsprechend den 

aus der Avionik kommenden Erfordernissen wird in Kapitel 2.9 in [SPES12c] vorgestellt. 

Das Beispiel stellt es nicht deutlich heraus, wie zwischen Anforderungen und 

Design (werden hier als Abstraktionsebenen bezeichnet) unterschieden werden soll. 

Aus den Traceability-Tabellen in Kapitel 2.9 kann man schließen, dass unter Anforderungen 

nur die Umgebungsdiagramme (der Kontext) fallen und die lösungsorientierten 

Anforderungen zusammen mit den Architekturdiagrammen das Design ('White-Box'-Betrachtung) 

bilden. Hier entsteht ggf. eine Verschiebung im Verständnis der 

Konzepte. Beim RE-Ansatz gehören nämlich die lösungsorientierten Anforderungen 

zu der Anforderungsperspektive. 




Hier wäre eine Untersuchung notwendig, wo genau die Unterschiede zwischen Avionik- 

und RE-Ansatz-Perspektiven in der Betrachtung der Trennung zwischen (bzw. 

Verzahnung von) Anforderungen und Design liegen. Darauf aufbauend kann im zweiten 

Schritt ein Verbessrungsvorschlag ausgearbeitet werden. 




8 Anhang B – Fragebogen zur Methodenakzeptanz 

(auf der nächsten Seite) 


- Fragebogen zur Evaluierung des in ZP-AP2 entwickelten modellbasierten 

Requirements-Engineering-Ansatzes - 


Verantwortlich Bastian Tenbergen 

QS-Verantwortlich 



Version: 1.0 


X Projektöffentlich 

Öffentlich 


vorgelegt 

X fertig gestellt 

1/9


Erzeugung Sebastian Gabrisch (SG), Bastian Tenbergen (BT) 

Mitwirkend Marian Daun (MD) 


Änderung 


Geänderte 

Kapitel 

Beschreibung der Änderung Autor Zustand 

1 10.10.11 0.1 Alle Initiale Produkterstellung SG In Bearbeitung 

2 17.10.11 0.2 Alle Überarbeitung und Erweiterung BT In Bearbeitung 

3 11.11.11 0.3 Alle Finalisierung und Fertigstellung BT In Bearbeitung 

4 02.12.11 1.0 Alle Review und Qualitätssicherung MD Fertig gestellt 

2/9

Vielen Dank für Ihre Teilnahme an unserer Evaluierung! 

Ziel dieses Fragebogens ist, eine Evaluierung des Requirements-Engineering-Ansatzes 

hinsichtlich bestimmter Evaluierungskriterien quantitativ zu ermöglichen. 

Bitte lesen Sie das Ihnen zur Verfügung gestellte Informationsmaterial durch und füllen Sie 

den Fragebogen möglichst vollständig durch ankreuzen von genau einer Antwortmöglichkeit 

aus. Selbstverständlich werden alle Ihre Antworten vertraulich und anonym behandelt. 

Falls Sie eine Frage aus betriebsinternen oder anderen Gründen nicht beantworten können, so 

vermerken Sie dies bitte an der Frage. 

Für Fragen, die eine 7-Punkt-Skala vorgeben, gilt grundsätzlich das folgende Schema: 

1 = trifft nie zu 

2 = trifft in den seltensten Fällen zu 

3 = trifft eher selten zu 

4 = teils-teils (trifft genauso oft zu, wie es nicht zutrifft) 

5 = trifft eher oft zu 

6 = trifft in den meisten Fällen zu 

7 = trifft immer zu 

3/9

ID Frage 

4 Ich finde den Ansatz nützlich für meinen Job. 

81 

14 

86 

Es gibt nicht genug Trainingsmaterial zum Ansatz, damit ich die Artefakte 

schnell und einfach finden, verstehen und damit arbeiten kann. 

Ich habe Zugriff auf die notwendigen Ressourcen, um den Ansatz 

verwenden zu können. 

Die Artefakte werden in einem lesbaren und nützlichen Format 

dargestellt. 

3 Die Verwendung des Ansatzes erhöht meine Effektivität in meinem Job. 

39 In meinem Job ist es wichtig, den Ansatz verwenden zu können. 

63 

Es ist einfach, mit dem Ansatz bestimmte Informationen in den 

Artefakten zu finden, selbst wenn ich den Ansatz noch nie verwendet 

habe. 

1 Der Ansatz verbessert meine Leistung in meinem Job. 

33 Ich verwende den Ansatz freiwillig. 

16 

Der Ansatz ist nicht kompatibel zu anderen Verfahren, die ich bei meiner 

Arbeit verwende. 

40 In meinem Job ist es relevant, den Ansatz verwenden zu können. 

4/9 

1 

trifft 

nie zu 

2 

fast nie 

3 

selten 

4 

teils- 

teils 

5 

oft 

6 

häufig 

7 

trifft 

immer zu 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O

ID Frage 

53 

11 

46 

55 

Dem Ansatz fehlen wichtige Artefakte, die notwendig sind, um meine 

Arbeit zu vereinfachen. 

Ich könnte meine Arbeit mit dem Ansatz durchführen, wenn mir jemand 

vorher zeigt, wie es geht. 

Ich glaube, dass ich mit anderen über die Konsequenzen der Nutzung des 

Ansatzes reden könnte. 

Es ist deutlich schwieriger, meine Aufgaben mit dem Ansatz als ohne den 

Ansatz zu erledigen, da der Ansatz wichtige Artefakte nicht bereitstellt. 

5 Den Ansatz anzuwenden ist klar und verständlich. 

34 Meine Vorgesetzten zwingen mich nicht, den Ansatz zu verwenden. 

54 

Die Artefakte, die der Ansatz bereitstellt sind genau die Richtigen, um 

meine Aufgaben erledigen zu können. 

13 Ich habe die Kontrolle über die Arbeit mit dem Ansatz. 

35 

Auch wenn er hilfreich ist, die Verwendung des Ansatzes ist nicht 

verpflichtend in meinem Job. 

44 Ich schätze die Ausgabeartefakte des Ansatzes als exzellent ein. 

82 

Mir steht ausreichend Training zur Verfügung, um meine Arbeit mit dem 

Ansatz effektiv durchführen zu können. 

5/9 

1 

trifft 

nie zu 

2 

fast nie 

3 

selten 

4 

teils- 

teils 

5 

oft 

6 

häufig 

7 

trifft 

immer zu 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O

ID Frage 

66 Es ist einfach, Zugriff auf die Artefakte, die ich brauche, zu erhalten. 

51 Ich plane, den Ansatz in den nächsten 12 Monaten zu verwenden. 

12 

47 

57 

Ich könnte meine Arbeit mit dem Ansatz durchführen, wenn ich zunächst 

mit einem anderen Ansatz aus dem SPES-Projekt gearbeitet hätte. 

Die Arbeitsergebnisse durch Nutzung des Ansatzes erschließen sich mir 

leicht. 

Der Ansatz beinhaltet Artefakte mit dem für meine Zwecke richtigen 

Detaillierungsgrad. 

43 Die Qualität der Ausgabeartefakte des Ansatzes ist unproblematisch. 

67 

88 

41 

64 

48 

Der Ansatz ist zu unflexibel, um mir schnell andere Artefakte zur 

Verfügung zu stellen, wenn ich spontan ein anderes Artefakt benötige. 

Die Artefakte werden in so vielen verschiedenen Kategorien eingeordnet, 

dass es schwierig ist, zu verstehen, wie sie effektiv zu nutzen sind. 

Die Verwendung des Ansatzes ist unabdingbar für verschiedene Aufgaben 

in meinem Job. 

Es ist einfach, unter Verwendung des Ansatzes Informationen über das zu 

entwickelnde System zu erhalten. 

Ich würde Schwierigkeiten haben, meinen Kollegen den Mehrwert durch 

die Nutzung des Ansatzes zu erklären. 

58 Die Artefakte des Ansatzes sind für meine Zwecke genau genug. 

6/9 

1 

trifft 

nie zu 

2 

fast nie 

3 

selten 

4 

teils- 

teils 

5 

oft 

6 

häufig 

7 

trifft 

immer zu 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O

ID Frage 

65 

Ich kann auf Artefakte schnell und einfach zugreifen, wenn ich sie 

brauche. 

8 Ich finde es einfach, mit dem Ansatz das zu tun, was ich tun möchte. 

49 

85 

45 

56 

Unter der Voraussetzung, dass ich den Ansatz verwenden kann, plane ich, 

diesen auch zu verwenden. 

Die Artefakte, die ich benötige werden mir durch den Ansatz in einer 

verständlichen Form zur Verfügung gestellt. 

Ich habe keine Schwierigkeiten mit anderen über die Ausgabeartefakte 

des Ansatzes zu reden. 

Der Ansatz sorgt dafür, dass Artefakte ausreichend detailliert 

dokumentiert werden. 

6 Den Ansatz zu verwenden erfordert wenig mentale Anstrengung. 

50 Ich werde sicherlich den Ansatz in Zukunft verwenden. 

87 

69 

Es gibt so viele Artefakte, dass es schwierig ist, zu verstehen, in welcher 

Situation welche Artefakte einzusetzen sind. 

Ich mache keinen schnellen Fortschritt, wenn ich schnell auf neue 

Artefakte zugreifen muss. 

2 Der Ansatz erhöht meine Produktivität in meiner Arbeit. 

7/9 

1 

trifft 

nie zu 

2 

fast nie 

3 

selten 

4 

teils- 

teils 

5 

oft 

6 

häufig 

7 

trifft 

immer zu 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O

ID Frage 

10 

59 

68 

9 

42 

15 

Ich könnte meine Arbeit unter Verwendung des Ansatzes durchführen, 

wenn mir nur die Dokumentation (bspw. Kapitel „Requirements View“) 

zur Verfügung steht. 

Bei der Verwendung des Ansatzes gibt es Probleme mit der Genauigkeit 

der bereitgestellten Artefakte. 

Wenn sich Geschäftsanforderungen ändern, ist es einfach mit dem Ansatz 

die Anforderungen an das System zu ändern. 

Ich könnte meine Arbeit mit dem Ansatz durchführen, wenn ich 

niemanden hätte, der mir die Verwendung erklärt. 

Die Qualität der Ausgabeartefakte, die ich durch den Ansatz erhalte, ist 

hoch. 

Wenn man die Ressourcen, Möglichkeiten und das Wissen bedenkt, die 

man benötigt, den Ansatz zu verwenden, dann wäre es einfach für mich, 

dies auch zu tun. 

7 Ich finde, dass der Ansatz leicht zu verwenden ist. 

8/9 

1 

trifft 

nie zu 

2 

fast nie 

3 

selten 

4 

teils- 

teils 

5 

oft 

6 

häufig 

7 

trifft 

immer zu 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O 

O O O O O O O

Vielen Dank nochmals für Ihre Teilnahme! 

Wenn Sie uns nun noch Kommentare oder Meinungen mitteilen möchten, dann können Sie 

dies auf dieser Seite gerne tun. 

9/9



9 Anhang C – Fragebögen zur Methodenanwendbarkeit 



EvaSys Paluno - The Ruhr Institute of Software Technology (Woche 7) 

Markieren Sie so: Bitte verwenden Sie einen Kugelschreiber oder nicht zu starken Filzstift. Dieser Fragebogen wird maschinell erfasst. 

Korrektur: Bitte beachten Sie im Interesse einer optimalen Datenerfassung die links gegebenen Hinweise beim Ausfüllen. 

ID/PIN 

Liebe/r Student/in, 

um die folgenden Fragebögen immer der gleichen Person zuzuordnen und um trotzdem anonym zu bleiben, hast du dir im ersten 

Fragebogen eine ID ausgedacht. Bitte gib ihn im folgenden Feld wieder an. Unser Hinweis vom ersten Fragebogen war: 

Erster Buchstabe vom Geburtsnamen deiner Mutter + letzte zwei Ziffern deiner Telefonnummer + Initialien deines Großvaters 

mütterlicherseits + letzten beiden Ziffern deiner Postleitzahl" (Beispiel: M34HM57) 

Aufwandsabschätzung 

In der letzten Woche habe ich mich mit dem folgenden Artefakt... 

...Ziele sehr wenig sehr viel 

beschäftigt 

...Zielbaum sehr wenig sehr viel 

beschäftigt 

...Szenarien sehr wenig sehr viel 

beschäftigt 

...textuelle Anforderungen sehr wenig sehr viel 

beschäftigt 

...Kontextmodell sehr wenig sehr viel 

beschäftigt 

...Hard- und Softgoals sehr wenig sehr viel 

beschäftigt 

...Message Sequence Charts (MSCs) sehr wenig sehr viel 

beschäftigt 

...Datenflussdiagramme (DFDs) sehr wenig sehr viel 

beschäftigt 

...logische und technische Ziele sehr wenig sehr viel 

beschäftigt 

...Datenmodell sehr wenig sehr viel 

beschäftigt 

...technisches Konzept sehr wenig sehr viel 

beschäftigt 

Insgesamt habe ich mich schon mit den folgenden Artefakten beschäftigt: 

Ziele Zielbaum Szenario 

Datenmodell Kontextmodell technisches Konzept 

Message Sequence Charts (MSCs) Datenflussdiagramme (DFDs) logische und technische Ziele 

textuelle Anforderungen 

Die Arbeitsbelastung für die Entwicklung in dieser Woche empfand ich 

als... 

Die Arbeitsbelastung für das Review in dieser Woche empfand ich 

als... 

F462U39373P1PL0V0 

Artefakttyp nicht 

verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 

zu niedrig zu hoch 

zu niedrig zu hoch 

21.06.2011, Seite 1/4


Förderung der Diskussion (aus Perspektive des Modellierers) 

Die Methodik hat eine zielgerichtete Diskussion unterstützt. stimme völlig 

zu 

Die Methodik hat mir geholfen meine Gedanken über die Aufgabe zu 

kommunizieren. 

F462U39373P2PL0V0 

stimme völlig 

zu 

Die Methodik hat mir geholfen, zielgerichtete Fragen zu stellen. stimme völlig 

zu 

Die Methodik hat den fachlichen Austausch innerhalb der Gruppe 

gefördert. 

In der zurückliegenden Woche haben wir uns innerhalb der Gruppe 

intensiv über das System ausgetauscht. 

In der zurückliegenden Woche haben wir uns zwischen den Gruppen 



zu 


zu 


zu 

Die Arbeit in der Gruppe schätze ich als konstruktiv ein. stimme völlig 

zu 

Nützlichkeit der Methodik 

Ziele waren für mich nützlich bei meiner 

Arbeit in der vergangenen Woche. 

Zielbäume waren für mich nützlich bei 

meiner Arbeit in der vergangenen Woche. 

Szenarien waren für mich nützlich bei 


Textuelle Anforderungen waren für mich 

nützlich bei meiner Arbeit in der vergangenen 

Woche. 

Das Kontextmodell war für mich nützlich bei 


Message Sequence Charts (MSCs) waren 

für mich nützlich bei meiner Arbeit in der 

vergangenen Woche. 

Datenflussdiagramme (DFDs) waren für 

mich nützlich bei meiner Arbeit in der 


Hard- und Softwaregoals waren für mich 


Woche. 

Logische und technische Ziele waren für 

mich nützlich bei meiner Arbeit in der 


Das Datenmodell war für mich nützlich bei 


Das technische Konzept war für mich 


Woche. 


zu 


zu 


zu 


zu 


zu 


zu 


zu 


zu 


zu 


zu 


zu 

Durch die Anwendung der Methodik habe ich das Gefühl, das System 

besser verstanden zu haben. 

Ich habe das Gefühl, dass ich mit der Methodik Sicherheit im Umgang 

mit der Aufgabenstellung bekommen habe. 

Förderung der Diskussion (aus Perspektive des Reviewers) 


zu 


zu 

Die Methodik hat eine zielgerichtete Diskussion unterstützt. stimme völlig 

zu 

Die Methodik hat mir geholfen meine Gedanken über die Aufgabe zu 

kommunizieren. 


zu 

Die Methodik hat mir geholfen, zielgerichtete Fragen zu stellen. stimme völlig 

zu 

stimme überhaupt 

nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


verwendet 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 

21.06.2011, Seite 2/4


Förderung der Diskussion (aus Perspektive des Reviewers) [Fortsetzung] 

Die Methodik hat den fachlichen Austausch innerhalb der Gruppe 

gefördert. 

In der zurückliegenden Woche haben wir uns innerhalb der Gruppe 


In der zurückliegenden Woche haben wir uns zwischen den Gruppen 


F462U39373P3PL0V0 


zu 


zu 


zu 

Die Arbeit in der Gruppe schätze ich als konstruktiv ein. stimme völlig 

zu 

Verständlichkeit der Spezifikation aus der Sicht des Reviewers 

Die Spezifikation ist für mich als Reviewer nachvollziehbar. stimme völlig 

zu 

Die Abstraktionsebenen haben mir als Reviewer geholfen das zu 

entwickelnde System zu verstehen. 

Die Einteilung in lösungsneutrale Anforderungen, lösungsbezogene 

Anforderungen und Lösungskonzept haben für mich als Reviewer das 

Verständnis der Spezifikation erhöht. 

Durch die Methodik war es mir möglich, ein strukturiertes Review 

durchzuführen. 

Durch die Methodik war es mir als Reviewer möglich, ein strukturiertes 

Feedback an die andere Gruppe zu geben. 

Ich hatte viele Rückfragen an die andere Gruppe bezüglich ihrer 

Spezifikation. 

Bitte bewerte, wie hilfreich das folgende Artefakt für dich beim Review war... 


zu 


zu 


zu 


zu 


zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 


nicht zu 

...Ziele sehr hilfreich gar nicht hilfreich Artefakttyp nicht 

verwendet 

...Zielbaum sehr hilfreich gar nicht hilfreich Artefakttyp nicht 

verwendet 

...Szenarien sehr hilfreich gar nicht hilfreich Artefakttyp nicht 

verwendet 

...textuelle Anforderungen sehr hilfreich gar nicht hilfreich Artefakttyp nicht 

verwendet 

...Kontextmodell sehr hilfreich gar nicht hilfreich Artefakttyp nicht 

verwendet 

...Hard- und Softgoals sehr hilfreich gar nicht hilfreich Artefakttyp nicht 

verwendet 

...Message Sequence Charts (MSCs) sehr hilfreich gar nicht hilfreich Artefakttyp nicht 

verwendet 

...Datenflussdiagramme (DFDs) sehr hilfreich gar nicht hilfreich Artefakttyp nicht 

verwendet 

...logische und technische Ziele sehr hilfreich gar nicht hilfreich Artefakttyp nicht 

verwendet 

...Datenmodell sehr hilfreich gar nicht hilfreich Artefakttyp nicht 

verwendet 

...technisches Konzept sehr hilfreich gar nicht hilfreich Artefakttyp nicht 

verwendet 

21.06.2011, Seite 3/4


Sonstige Fragen 

Mir hat in dieser Woche am besten gefallen: 

Zur Spezifikation des zu entwickelnden Systems wären für mich noch folgende Modelle wichtig gewesen: 

Für das Verständnis der Spezifikation wären für mich folgende Informationen oder Artefakte noch interessant gewesen: 

Alles weitere, was ich noch sagen wollte: 

F462U39373P4PL0V0 

Vielen Dank für deine Teilnahme an dieser Befragung! 

21.06.2011, Seite 4/4



10 Anhang D – Ein Ansatz zur Spezifikation von Echtzeitanforderungen 

am Beispiel von Szenarien 



Ein Ansatz zur Spezifikation von Echtzeitanforderungen 


Version: 1.0 

Verantwortlich Thorsten Weyer (Universität Duisburg-Essen) 

QS-Verantwortlich 




Projektöffentlich 

X Öffentlich 


vorgelegt 

X fertig gestellt


Erzeugung Nadezhda Avramova (NA), Björn Wolfahrt (BW), Thorsten Weyer (TW) 

Mitwirkend 


Änderung 


Geänderte 

Kapitel 

Beschreibung der Änderung Autor Zustand 

1 17.02.11 0.1 Alle Produkterstellung NA, BW Vorgelegt 

2 28.04.11 1.0 - Review und Finalisierung TW, NA Fertig gestellt

Kurzfassung 

In diesem Dokument wird eine Erweiterung der COSMOD-RE Methode nach 

[Pohl10] präsentiert. Dabei sollen sich zusätzlich Echtzeitanforderungen durch die 

Methode in die Spezifikation eines eingebetteten Systems aufnehmen lassen. Die 

Erweiterung basiert auf einem semantischen Modell für Formalisierung von zeitbehafteten 

Message Sequence Charts. Das Dokument zeigt auch die Anwendung dieser 

Erweiterung an einem Beispiel. 


Inhalt 

1 Einordnung und Kurzbeschreibung ..................................................................... 5 

1.1 Motivation und Einordnung ........................................................................... 5 

1.2 Management Summary ................................................................................ 5 

1.3 Überblick ...................................................................................................... 5 

2 Einführung in die Modellierung von Eingebetteten Systemen ............................. 6 

2.1 Eingebettete Systeme .................................................................................. 6 

2.2 Die COSMOD-RE Methode .......................................................................... 6 

2.3 Problemstellung............................................................................................ 7 

2.4 Verwandte Literatur ...................................................................................... 7 

2.4.1 ROOM ................................................................................................... 7 

2.4.2 UML-SPT .............................................................................................. 7 

2.4.3 MSCs .................................................................................................... 8 

3 Modellierung von Echtzeitanforderungen in CODMOD-RE ................................. 9 

3.1 Basic Message Sequence Charts ................................................................ 9 

3.2 High-Level Message Sequence Charts ...................................................... 11 

3.3 Zeitbehaftete MSCs .................................................................................... 11 

3.4 Semantisches Modell für zeitbehaftetete MSCs zur Spezifikation von 

Echtzeitanforderungen in der COSMOD-RE Methode .......................................... 13 

3.4.1 Partialordnungsmodell für (Zeitbehaftete) MSCs ................................ 14 

3.4.2 Semantik der Partialordnung für Zeitbehaftete MSCs ......................... 16 

3.4.3 Besonderheiten der Basic MSC (bMSC) ............................................. 16 

3.4.4 Besonderheiten von MSC mit Strukturen ............................................ 17 

3.4.5 Besonderheiten der High-Level MSC (hMSC)..................................... 18 

4 Beispiel .............................................................................................................. 19 

4.1 Anwendungskontext ................................................................................... 19 

4.2 Spezifikation der Echtzeiteigenschaften ..................................................... 19 

4.2.1 Anforderungen an das SOAHarbor-System ........................................ 19 

4.2.2 Formale Spezifikation des Anwendungbeispiels ................................. 20 

5 Zusammenfassung ............................................................................................ 24 

6 Literaturverzeichnis ........................................................................................... 25 


1 Einordnung und Kurzbeschreibung 

1.1 Motivation und Einordnung 

Das vorliegende Dokument beschreibt eine Erweiterung der COSMOD-RE Methode 

um die Möglichkeit zur Spezifikation von Echtzeitanforderungen an eingebettete Systeme. 

Dieses Dokument betrachtet die COSMOD-RE Methode sowie andere Ansätze 

zur Spezifikation von Echtzeitanforderungen an eingebettete Systeme. Die vorgestellte 

Erweiterung berücksichtigt die Besonderheiten der COSMOD-RE Methode. 

1.2 Management Summary 

1.3 Überblick 

Abschnitt 2 dieses Dokuments beschreibt die eingebettete Systeme und ihre Eigenschaften, 

die COSMOD-RE Methode, mit der sich Anforderungen an eingebettete 

Systeme spezifizieren lassen und die verwandte Literatur zum Problem der Spezifizierung 

von Echtzeitanforderungen in Modellen für eingebettete Systeme. Im Abschnitt 

3 wird die Erweiterung der COSMOD-RE Methode detailliert beschrieben, indem 

zuerst eine Übersicht über die Message Sequence Charts gegeben wird, und 

danach auf die eigentliche Erweiterung eingegangen wird. Abschnitt 4 zeigt die Anwendung 

der beschriebenen Erweiterung an einem Beispiel. 


2 Einführung in die Modellierung von Eingebetteten Systemen 

2.1 Eingebettete Systeme 

Eingebettete Systeme sind Computersysteme, die nicht als solche wahrgenommen 

werden [ELLS97]. Sie sind auch dadurch charakterisiert, dass in ihnen Mikroprozessoren 

eingesetzt werden [Wolf94]. Viele Autoren sind sich einig, dass für eingebettete 

Systeme eine enge Beziehung zwischen Hardware und Software typisch ist (siehe 

[ELLS97, Wolf94, Pohl10]). Beispiele für eingebettete Systeme sind Mikrowellengeräte, 

automatische Türen in Gebäuden oder Fahrzeugen, mobile Telefongeräte, 

elektronische Systeme in Autos und Flugzeugen. 

Eine spezielle Art eingebettete Systeme sind diese, an denen auch Echtzeitanforderungen 

gestellt werden. Dies bedeutet, dass alle oder ein Teil der Funktionen im System 

innerhalb eines fest definierten Zeitrahmens ausgeführt werden sollen. Beispiele 

für solche Systeme sind Motorsteuersysteme in Automobilen, Herzschrittmacher, 

mobile Telefongeräte, Drucker, usw. (siehe [Kope97]). 

2.2 Die COSMOD-RE Methode 

COSMOD-RE (siehe [Pohl10]) ist eine Methode zur Unterstützung der Entwicklung 

von eingebetteten Systemen und der Hardware-Software Codesign. Der letzte Begriff 

bezeichnet die parallele Entwicklung von Hardware- und Softwarekomponenten für 

eingebettete Systeme, da diese eng miteinander interagieren und deren separate 

Entwicklung nicht umsetzbar ist. 

Die Spezifizierung eines eingebetteten Systems nach der COSMOD-RE Methode 

erfolgt durch verschiedene Abstraktionsebenen. Diese sind Systemanforderungsebene, 

Systemgrobarchitektur-, Funktionsgruppenanforderungen-, HW/SW- 

Grobarchitektur-, HW/SW-Anforderungs- und SW-Deployment-Ebene. Der Detailierungsgrad 

der erarbeiteten Artefakte steigt in jeder Ebene. So, z.B. werden in der 

Systemanforderungsebene die Anforderungen für das gesamte Systeme spezifiziert, 

auf der Funktionsgruppenebene – für einzelne Funktionsgruppen, d.h. Teile des Systems. 

Aus dem Namen der einzelnen Abstraktionsebenen wird ersichtlich, dass Anforderungen 

und Architektur parallel entwickelt und entlang der Abstraktionsebenen 

verfeinert werden. 

Die COSMOD-RE Methode besteht aus drei Codesign-Prozesse, die Entwicklung 

von eingebetteten Systemen auf den Abstraktionsebenen bestimmen. Diese sind: 

System-Codesign 

Funktionsgruppen-Codesign 

Komponenten-Codesign 

In jedem dieser Codesign-Prozesse werden Ziele und Szenarien, Anforderungen und 

Architektur parallel entwickelt. Die Ziele und Szenarien werden entlang der Abstraktionsebenen 

verfeinert. Sie dienen in jedem Codesign-Prozess als Grundlage für die 

Spezifizierung der Anforderungen auf die jeweilige Abstraktionsebene. Aus den Anforderungen 

wird dann die entsprechende Architektur, wiederum pro Abstraktionsebene 

entwickelt. Am Ende der Codesign-Prozesse stehen Ziele und Szenarien, An- 


forderungen und Architektur für jede Abstraktionsebene, wobei jede Artefakt in jeder 

Abstraktionsebene verfeinert wird. Die Verfeinerungen, sowie die Artefakte untereinander 

müssen konsistent sein. 

2.3 Problemstellung 

Wie bisher angemerkt, ist es möglich, dass eingebettete Systeme Zeitaspekte enthalten. 

Diese sollen in die Spezifikation angegeben werden, damit sie validiert werden 

können, so dass eventuelle Fehler so früh wie möglich entdeckt werden. 

Die COSMOD-RE Methode ist für die Spezifizierung von eingebetteten Systemen 

dadurch vorteilhaft, dass sie die enge Beziehung zwischen Hardware und Software 

beim Spezifikationsprozess berücksichtigt. Problematisch bei dieser Methode ist, 

dass sie keine Möglichkeit bietet, Zeitaspekte in der Spezifikation zu notieren. In dieser 

Arbeit soll dieses Problem gelöst werden, indem eine Erweiterung der COSMOD- 

RE Methode entwickelt wird, mit der sich Zeitaspekte in die Spezifikation aufnehmen 

lassen. 

Es ist anzumerken, dass Zeitaspekte in der Spezifikation nur diejenigen Modelle betreffen, 

die dynamische Prozesse des Systems spezifizieren. Solche sind z.B. die 

Verhaltens-, Kontrollfluss-, Sequenzmodelle, etc. Modelle aus der Spezifikation, die 

die Systemstruktur spezifizieren enthalten in der Regel keine Zeitaspekte. In der 

COSMOD-RE Methode sind die Szenariomodelle die einzige Modellgruppe, die dynamische 

Prozesse des Systems abbildet. Daher wird sich die geplante Erweiterung 

des COSMOD-RE in diesem Deliverable nur auf die Szenariomodelle auswirken. 

2.4 Verwandte Literatur 

2.4.1 ROOM 

Mit der Real-Time Object-Oriented Modeling Methode (ROOM) (siehe [Seli96]) lassen 

sich Echtzeitsysteme modellieren. Der Fokus dieser Methode ist in der strukturellen 

Modellierung der Komponente eines Echtzeitsystems. Komponenten werden 

als Vierecke im Modell angegeben, die durch Ports und Links miteinander verbunden 

werden können. Jede Verbindung verweist auf einem Kommunikationsprotokoll, der 

zwischen den beiden verbundenen Komponenten, stattfinden kann. Zeitaspekte werden 

in dieser Methode relativ durch ein Sequenzdiagramm modelliert. Das Sequenzdiagramm 

repräsentiert die zeitliche Reihenfolge der Ereignisse, die in einem Kommunikationsprotokoll 

gegeben sind. Durch State Charts werden die möglichen Ereignisse, 

die das Echtzeitsystem zu erwarten hat, sowie ihr Antwortoptionen, modelliert. 

2.4.2 UML-SPT 

Das UML-Profil für Schedulability, Performance and Time Specification (SPT) (siehe 

[OMG05]) ist die meist verwendete UML-Erweiterung zur Spezifikation von Zeitaspekten. 

Da das SPT Profil die UML Sprache erweitert, ist es für viele Zwecke, aber 

auch für die Modellierung von Echtzeit-Eingebetteten Systemen geeignet. Das Profil 

bietet die Möglichkeit Zeitschranken, reale Zeit, Ereigniseintrittszeitpunkte und Dauer 

anzugeben. Dies geschieht in Form von Annotationen an alle möglichen UML- 


Modellierungselemente, für die Zeit relevant sein kann. Solche Elemente können z.B. 

Aktionen, Transitionen, Nachrichten oder Zustände sein. Die Zeitangaben an den 

Modellen erweitert diese um die zu beachtenden Zeitaspekten. 

2.4.3 MSCs 

Die Message Sequence Charts (MSCs) sind eine szenariobasierte Modellierungssprache, 

die hauptsächlich zur Spezifikation von Kommunikation und Verhalten eingesetzt 

wird [Itut04]. Diese Sprache ähnelt sehr der Sequenzdiagramme aus UML, 

bietet aber auch die Möglichkeit Zustandsübergänge entsprechend dem Nachrichtenaustausch 

zu modellieren. Der Eignung der MSCs für die Spezifikation von eingebetteten 

Systemen wird z.B. in [KGSB98] festgestellt. Die MSCs sind eine standardisierte 

Sprache und nach dem Jahr 2000 ist es möglich mit ihnen auch Zeitaspekte im 

Verhalten zu modellieren. Zeitaspekte werden an den Diagrammen in Form von Zeitintervallen 

angegeben, die beim Eintritt von einem Ereignis anfangen oder enden. 

Die MSCs bieten auch die Möglichkeit absolute und relative Zeit zu spezifizieren, 

Zeitintervalle anzugeben, in denen ein Ereignis eintreten soll, etc. 


3 Modellierung von Echtzeitanforderungen in CODMOD-RE 

In diesem Abschnitt wird die Erweiterung der COSMOD-RE Methode vorgestellt, die 

die Methode um die Möglichkeit zur Spezifizierung von Echtzeitanforderungen von 

eingebetteten Systemen erweitern soll. Wie bisher angemerkt, beziehen sich Zeitaspekte 

nur auf die dynamischen Modelle einer Spezifikation. Das sind die Modelle, die 

Verhalten oder Nachrichtenaustausch im Laufe einer bestimmten Zeit ausdrücken. In 

der COSMOD-RE Methode sind das lediglich die Szenariomodelle, die Interaktionen 

zwischen den Komponenten und/oder Akteuren eines eingebetteten Systems abbilden. 

Die anderen Modellarten, die in COSMOD-RE eine Rolle spielen, sind die Zielmodelle 

und die Modelle über lösungsorientierte Anforderungen. Diese Modelle enthalten 

die Ziele eines eingebetteten Systems und seine Anforderungen unter der 

Funktionsperspektive (siehe [Pohl10]). Bei beiden Modellen spielt die Zeit keine Rolle. 

Aus diesem Grund sind die bei der Erweiterung der COSMOD-RE Methode um 

Zeitaspekte nicht relevant. 

Für die Modellierung von Szenarien wird durch die COSMOD-RE Methode die Verwendung 

entweder von UML-Sequenzdiagrammen oder von MSCs empfohlen. In 

diesem Abschnitt wird die Erweiterung der COSMOD-RE Methode auf der Basis der 

MSCs erfolgen. Dies kann dadurch argumentiert werden, dass diese Modellierungssprache 

einfach in der Anwendung ist, gute Möglichkeiten zur Strukturierung der einzelnen 

Modelle anbietet und als Spezifikationssprache für eingebettete Systeme bekannt 

ist. 

Im Folgenden werden zuerst die Besonderheiten der MSCs vorgestellt und danach 

potentielle Probleme mit der Modellierung der Zeitaspekte in eingebetteten Systemen 

hervorgehoben. Anschließend wird die vorgeschlagene Erweiterung der COSMOD- 

RE Methode beschrieben. 

3.1 Basic Message Sequence Charts 

Die MSC Diagramme können in bMSC (Basic Message Sequence Charts) und 

hMSCs (High-level Message Sequence Charts) untergliedert werden. bMSCs spezifizieren 

die Nachrichtenkommunikation zwischen verschiedenen Instanzen – Akteure, 

Systemkomponenten, etc. – und deren Zustandswechsel nach Erhalt der Nachrichten. 

Wenn nur der Begriff MSC verwendet wird, wird darunter eine bMSC verstanden. 

hMSCs dienen zur Organisation der bMSCs und geben an, wie die einzelnen 

bMSCs voneinander abhängen. 

Ein Beispiel eines bMSC kann man Abbildung 3-1 (siehe [Itut04]) entnehmen: 


Abbildung 3-1 – Basic Message Sequence Chart 

Jeder am Szenario teilnehmender Akteur wird innerhalb des bMSC durch eine Instanz 

und das korrespondierende grafische Notationselement repräsentiert 

(s. Abbildung 3-1). Die Instanzen werden durch Rechtecke repräsentiert 

() mit dem entsprechenden Namen (). 

Senkrecht unter jeder Instanz wird eine Zeitachse in Form einer Linie angegeben. An 

dieser kann der Verlauf der Nachrichtenkommunikation im Laufe der Zeit für jede 

Instanz verfolgt werden (). Die Kommunikation zwischen den 

Akteuren wird durch Nachrichten und dem korrespondierenden grafischen Notationslelement 

definiert (s. Abbildung 3-1). Die Nachrichten werden als 

Pfeile dargestellt (), an denen der Name der Nachricht angegeben 

wird (). Das Senden einer Nachricht ist der Anfang eines Pfeils, der 

an der Zeitachse der sendenden Instanz angegeben ist (). An 

der Zeitachse der empfangende Instanz wird das Ende des Nachrichtenpfeils angegeben 

(). In bMSCs sind das Senden und der Empfang einer 

Nachricht asynchrone Events. Dabei wird angenommen, dass die Umwelt des MSCs 

Nachrichten vom MSC empfangen und Nachrichten zum MSC senden kann (s. 

[Itut04]). 

Neben den vorgestellten Basiselementen des MSC gibt es noch einige weitere Notationselemente, 

die für diese Arbeit von Bedeutung sind. Dazu gehören vor allem die 

strukturellen Konzepte der MSC-Sprache repräsentiert durch Inline Expressions und 

References. Mit Inline Expressions kann die Komposition der Ereignisstrukturen innerhalb 

eines MSC definiert werden. Die Operatoren beziehen sich dabei auf die alternative, 

parallele und sequentielle Komposition, Iteration, Ausnahmen und optionale 

Regionen. Unter Berücksichtigung der zuvor gewählten Reihenfolge werden folgende 

Schlüsselwörter für die grafische Repräsentation der Operatoren benutzt: alt, 

par, seq, loop, exc und opt. 

Eine MSC reference wird benutzt, um andere MSCs des MSC-Dokuments zu referenzieren. 

Durch das wird eine MSC-Referenz grafisch notiert. 

MSC-Referenzen sind Objekte von dem Typ, der durch das referenzierte MSC 

vorgegeben ist. Eine MSC-Referenz kann ein einzelnes MSC oder eine MSC reference 

expression referenzieren. [Itut04] 


3.2 High-Level Message Sequence Charts 

High-Level MSCs (hMSCs) stellen Hilfsmittel zur Verfügung, um grafisch definieren 

zu können wie eine Menge von bMSCs kombiniert werden können. Ein hMSC ist ein 

gerichteter Graph in dem jeder Knoten entweder: 

ein Startsymbol (in jedem hMSC gibt es nur ein Start symbol), 

ein Endsymbol, 

eine MSC-Reference, 

eine Condition, 

ein Connection Point, oder 

ein hMSC inline expression frame ist. 

Die Knoten in einem hMSC stellen Referenzen zu bereits spezifizierten bMSCs. Die 

Knoten im hMSC werden durch Pfeile verbunden, die deren möglichen Sequenzen 

anzeigen. Eingehende Pfeile werden immer mit der oberen Ecke des Knotensymbols 

verbunden, wohingegen ausgehende Pfeile stets mit der unteren Ecke des Knotensymbols 

verbunden werden. Gibt es mehr als einen ausgehenden Pfeil von einem 

Knoten, dann handelt es sich um eine Alternative. 

Abbildung 3-2 – High-level Message Sequence Chart 

In Abbildung 3-2 (siehe [Itut04]) ist ein Beispiel eines hMSC gegeben. Die Ausführung 

des hMSC beginnt beim Startsymbol (). Nach der Condition 

„when disconnected“, kann entweder das refenrezierte bMSC „failure“ oder 

„connection“ ausgeführt werden, abhängig davon, wie die Condition ausgewertet 

worden ist (). Das hMSC endet beim Endsymbol (), wenn die Condition „connected“ () erfüllt worden 

ist. 

3.3 Zeitbehaftete MSCs 

Wie bereits angemerkt, führt die neueste MSC-Spezifizierung (s. [MSC‘2000- 

Standard]) Zeitkonzepte zur Notation quantifizierter Zeit in MSCs ein. Dies ermöglicht 


die Anordnung von Ereignissen (d.h. Senden oder Empfangen von Nachrichten) zu 

quantifizieren und führt zu einer ausdrucksstärkeren Beschreibung von Echtzeitsystemen. 

Im MSC‘2000-Standard existieren folgende Zeitkonzepte (siehe [Itut04, 

ZhKH02]): 

Pro Message Sequence Chart wird eine globale Uhr angenommen. Entlang 

jeder Instanz-Achse verläuft die Zeit von oben nach unten. Sofern nicht anders 

gekennzeichnet, unterliegen alle Ereignisse einer absoluten, zeitlichen 

Reihenfolge entlang jeder Instanz-Achse. Ereignisse von unterschiedlichen 

Instanzen werden durch Nachrichten geordnet (s. [Kerb07]). 

Der Zeitverlauf ist für alle Instanzen eines MSC gleich. 

Es ist zu beachten, dass die Zeitbedingungen nur die Anordnung von Ereignissen 

quantifizieren und die Zeit beschränken, in der bestimmte Ereignisse 

eintreten können. MSC-Ereignisse selbst, können nicht durch Zeitbedingungen 

spezifiziert werden, da diese ohne Verzögerung eintreten und keine Zeit 

verbrauchen. 

Der Zeitbereich kann dicht oder diskret sein. Der Zeitbereich muss eine Gesamtordnung 

sein und mit einem kleinsten Element oder mit der Zeit 0 beginnen. 

Die MSC-Spezifikation beschreibt eine relative und eine absolute Zeitberechnung. 

Die relative Zeitberechnung benutzt Ereignispaare – vorhergehendes 

und nachfolgendes Ereignis – und dient zur Spezifikation der Verzögerung 

zwischen zwei Ereignissen (relative Verzögerung). Die absolute Zeitberechnung 

wird benutzt, um das Eintreten von Ereignissen in Relation zum Wert der 

globalen Uhr zu definieren (absolute Verzögerung). 

Ein weiteres wichtiges Konzept sind die Zeitintervalle. Sie können verwendet 

werden, um eine relative oder absolute Verzögerung mithilfe einer minimalen 

oder maximalen Schranke zu spezifizieren. Sie definieren die Zeitbedingungen 

für das Eintreten von Ereignissen. 

Zur Spezifikation einer relativen Verzögerung kann ein Zeitintervall mit minimaler 

und maximaler Schranke oder ein konkreter Zeitwert benutzt werden. 

Zum Beispiel wird eine relative Verzögerung von 4 bis 5 Sekunden durch [4s, 

5s] repräsentiert. Beträgt die relative Verzögerung exakt 3 Sekunden, so wird 

dies durch [3s] spezifiziert. 

Ähnliches gilt für die Spezifikation der absoluten Verzögerung, die nur eine 

leicht abweichende Notation verwendet. Tritt ein Ereignis beispielsweise zwischen 

der vierten und fünften Sekunde (in Relation zur globalen Uhr) ein, so 

wird dies wie folgt notiert: @[4s, 5s]. Wenn das Ereignis hingegen exakt zur 

dritten Sekunde eintritt, ist [@3s] zu notieren. 

Abbildung 3-3 (angelehnt an [ZhKH02]) zeigt die grafische MSC-Notation der erwähnten 

Beispiele für Zeitbedingungen. MSCs mit Zeitbedingungen, die zu einer 

Quantifizierung der Ereignisanordnung führen werden als Zeitbehaftete bzw. Timed 

MSCs bezeichnet (s. [ZhKH02, AlHP96]). Die in der Abbildung dargestellten Ereignisse 

sind mit a, b, c, d, e und f benannt. Das MSC spezifiziert den Nachrichtenaustausch 

zwischen den Instanzen i und j, wobei die Anordnung der gekennzeichneten 

Ereignisse durch die Verwendung relativer und absoluter Verzögerungen quantifiziert 

ist. Relative Verzögerungen sind zwischen den Ereignissen a und d, b und c und e 

und f spezifiziert. Der jeweilige Eintritt der Ereignisse a, c und d ist durch absolute 

Verzögerungen spezifiziert. 


Abbildung 3-3 – Zeitbehaftetes Message Sequence Chart 

Die Semantik von Zeitbehafteten MSCs wird in der MSC-Spezifikation durch sogenannte 

Traces mit speziellen Zeitereignissen zwischen den anderen Ereignissen repräsentiert. 

Beispielsweise ist der Trace für das MSC, repräsentiert in Abbildung 3-3, 

{a, t1, b, t2, c, t3, d, e, t5, f}. Befindet sich zwischen zwei normalen Ereignissen kein 

Zeitereignis, wie dies zwischen den Ereignisse d und e der Fall ist, so treten diese 

simultan ohne Zeitverzögerung ein. Diese Semantik wird in der MSC-Spezifikation 

allerdings informal und unvollständig beschrieben. Um die Semantik von Zeitbehafteten 

MSCs vollständig und formal definieren zu können, bedarf es eines adäquaten 

semantischen Modells, mit dem alle möglichen Traces eines (zeitbehafteten) MSCs 

abgebildet werden können. Ein solches semantisches Modell wird im folgenden Abschnitt 

vorgestellt. 

3.4 Semantisches Modell für zeitbehaftetete MSCs zur Spezifikation 

von Echtzeitanforderungen in der COSMOD-RE Methode 

Semantische Modelle werden benötigt, um die Benutzung von MSCs zu unterstützen. 

Sie bedienen sich einer formalen Semantik, welche die zugrundeliegende Sprache 

präzise definiert. Dies verhindert vor allem Mehrdeutigkeiten in der Interpretation. 

Angestoßen durch die neuste Version des MSC-Standards, MSC‘2000 (s. []), wurden 

weitere formale Semantiken bzw. semantische Modelle entwickelt, um die neu eingeführten 

Konzepte der MSC-Spezifikation abzudecken. Eines der neu eingeführten 

Konzepte sind die Zeitbedingungen, die eine adäquate Spezifikation von u. a. Echtzeitsystemen 

erlauben. In [ZhKH02] wird ein semantisches Modell zur Definition von 

MSCs mit Zeitbedingungen, den sogenannten Zeitbehafteten MSCs, vorgestellt. Dieses 

Modell basiert auf dem Partialordnungsmodell von [Heym98], den lposets (labelled 

partially ordered set), und erweitert dieses um einen Zeitbereich. Es ermöglicht 


die Definition der Semantik von Zeitbehafteten MSCs. Als konkretes semantisches 

Modell wurden die Zeitbehafteten bzw. Timed lposets definiert. 

In dieser Arbeit wird der in [ZhKH02] formulierten Meinung gefolgt, dass ein MSC die 

partielle Anordnung zwischen Ereignissen definiert und diese Anordnung durch Zeitbedingungen 

quantifiziert. Aus diesem Grund werden die Zeitbehafteten lposets in 

dieser Arbeit als semantisches Modell für die Definition der formalen Semantik der 

Zeitbehafteten MSCs herangezogen. In den nächsten Abschnitten wird das semantische 

Modell aus [ZhKH02] näher erläutert. 

3.4.1 Partialordnungsmodell für (Zeitbehaftete) MSCs 

Um die Anforderungen eines Zeitbehafteten MSC zu erfüllen, werden die lposets um 

zwei Verzögerungsfunktionen angereichert. Des Weiteren wird Time zur Repräsentation 

des Zeitbereichs verwendet, welcher aus einer Menge von nicht-negativen, reellen 

oder ganzen Zahlen bestehen kann. Dabei ist P(Time) die Potenzmenge von Time. 

Mit diesen Erweiterungen kann nun das Zeitbehaftete lposet definiert werden. 

Ein Zeitbehaftetes lposet ist ein Tupel (A, E, ≤, l, D, T), in dem 

A die Menge der Label ist. 

E die Menge der Ereignisse ist. 

≤: eine Partialordnung über E ist. 

l: eine Labeling-Funktion ist, welche ein Ereignis zu einem Label assoziiert. 

Es kann eine partielle Funktion sein. 

D: eine absolute Verzögerungsfunktion ist, welche ein Ereignis 

zu einer Menge von Zeitwerten assoziiert. Sie definiert einen Bereich, in dem 

ein Ereignis eintreten kann. 

T: eine relative Verzögerungsfunktion ist, welche ein Ereignispaar 

zu einer Menge von Zeitwerten assoziiert. Sie definiert mögliche Verzögerungen 

zwischen zwei Ereignissen. 

Die Menge der Labels A definiert die „Bedeutung“ eines Ereignisses. Für das zugrundeliegende 

Modell kann ein Ereignis ein Nachrichteneingang, Nachrichtenausgang, 

eine interne Aktion, Timerstart, Timerstop oder Timeout sein. Somit können die 

Labels wie folgt definiert werden: 

send(i, j, m): Instanz i sendet eine Nachricht m an Instanz j, 

receive(i, j, m): Instanz i empfängt eine Nachricht m von Instanz j, 

action(i, a): Instanz i führt eine interne Aktion a aus, 

starttimer(i, T, n): Instanz i setzt einen Timer T mit der Timeout-Periode n, 

stoptimer(i, T): Instanz i bricht den Timer T ab, 

timeout(i, T): Der Timer T in der Instanz i läuft ab. 

Jedes Ereignis wird mit einem eindeutigen Label versehen. So wird zwischen jeder 

Nachricht (unabhängig vom Inhalt) und jedem Timer (unabhängig vom Wert) eindeutig 

differenziert. Ein Trace eines Zeitbehafteten lposet wird definiert als eine Sequenz 

von Zeitbehafteten Events (e1, t1), (e2, t2), …, (en, tn) mit , so dass für 

alle i und j, : 

wenn 

wenn 

Informal, repräsentieren i und j die Positionen der Ereignisse in einem Trace. Die erste 

Bedingung drückt die Erfüllung der Partialordnung zwischen zwei Ereignissen in 


einem Trace aus. Die zweite Bedingung garantiert Zeitkonsistenz. Die beiden anderen 

Bedingungen bedeuten, dass Ereignisse ihre Zeitbedingungen erfüllen müssen. 

Die Menge der Traces eines Zeitbehafteten lposet lp ist definiert als Tr(lp) = {w | w ist 

ein Trace von lp}. 

Ein Ereignis e ist ein minimales Element in E entsprechend ≤, wenn es kein Ereignis 

gibt, so dass . Ein Ereignis e ist ein maximales Element in E 

entsprechend ≤, wenn es kein Ereignis gibt, so dass . Aufgrund 

der Partialordnung kann es verschiedene minimale und maximale Elemente in 

E geben. 

Wird verwendet um die leere Menge zu repräsentieren, so kann ein lposet ε = (A, 

E, ≤, l, D, T) als ein Identitäts-lposet in dem A, E, ≤, l, D und T = sind, definiert werden. 

Um ein MSC mit einem Deadlock zu repräsentieren, wird ein lposet (A, E, ≤, l, 

D, T) als δ notiert, wenn Dies bedeutet, dass δ keinen Trace hat. 

Für alle Ereignisse in einem MSC für die keine absolute oder relative Verzögerung 

explizit spezifiziert wurde, gilt eine Verzögerung von [0, ∞). 

Ein Zeitbehaftetes lposet kann benutzt werden um ein Ereignis in einem MSC, einen 

Teil des MSC oder das gesamte MSC zu repräsentieren. Um dies tun zu können, 

gibt es verschiedene definierte Operationen, die auf lposets durchgeführt werden 

können: die sequentielle, alternative und parallele Komposition. 

Seien zwei lposets p und q gegeben, deren Ereignisse auf verschiedenen Instanzen 

oder der gleichen Instanz angesiedelt sein mögen. Formal beschrieben, seien p = 

(Ap, Ep, ≤p, lp, Dp, Tp) und q = (Aq, Eq, ≤q, lq, Dq, Tq) zwei Zeitbehaftete lposets in denen 

Ap und Aq disjunkt und ≤p , ≤q sind. Für eine Relation S, wird S + zur Repräsentation 

der transitiven Hülle von S benutzt. Die sequentielle Komposition ( ) von 

p und q ist dann ein lposet, das definiert ist als: 

in dem 

1) 

2) sind die Mengen der Ereignisse, die bei Instanz i auftreten, 

3) 

Informal, bedeutet dies für: 

1) Wenn ein Ereignis das Senden einer Nachricht referenziert und ein anderes Ereignis 

das Empfangen dieser Nachricht referenziert, dann ist eine neue Anordnung 

zwischen diesen Ereignissen einzufügen. 

2) Wenn zwei Ereignisse auf der gleichen Instanz angesiedelt sind, dann ist eine 

neue Anordnung zwischen diesen Ereignissen einzufügen. 

3) Wenn ein Ereignis das Starten eines Timer mit einer Timeout-Periode beschreibt 

und ein anderes Ereignis das Beenden oder Ablaufen des Timer repräsentiert, 

dann ist eine Zeitbedingung zwischen diesen Ereignissen einzufügen. 

+ 

Des Weiteren definiert die Semantik, wenn 

keine Partialordnung 

ist, dass die sequentielle Komposition von zwei lposets als δ in der definiert ist. 

Und dass die sequentielle Komposition von δ und einem beliebigen lposet stets δ ist. 

Für das Identitäts-lposet ε wird definiert, dass seine sequentielle Komposition mit ei- 


+ ,

nem beliebigen lposet p stets p ist. Für zwei Mengen von lposets 

und , wird die sequentielle Komposition definiert als: 

Die alternative Komposition ( ) von zwei lposets p und q ist definiert als eine Menge 

von lposets: 

Für zwei Mengen von lposets und , ist die alternative 

Komposition definiert als: 

Die parallele Komposition ( ) von zwei lposets p und q ist definiert als: 


, 

In der parallelen Komposition wird gefordert, dass und disjunkt sind, was dazu 

führt dass auch und disjunkt sind. Wird eine Nachricht m zwischen den gleichen 

Instanzen in p und q ausgetauscht, so muss diese in m1 und m2 umbenannt 

werden. Die Instanzen in p und q können die gleichen sein. Für zwei Mengen von 

lposets und , wird die parallele Komposition 

definiert als: 

3.4.2 Semantik der Partialordnung für Zeitbehaftete MSCs 

Die Semantik für Zeitbehaftete MSCs aus [ZhKH02] fordert eine Differenzierung zwischen 

bMSCs, MSCs mit Strukturen (z.B. Inline Expressions) und HMSCs. Die Differenzierung 

ist hierbei wie folgt zu verstehen: Ein bMSC beinhaltet ein oder mehrere 

Ereignisse und ein HMSC beinhaltet ein oder mehrere bMSCs, während dessen ein 

MSC mit Strukturen sowohl Ereignisse als auch bMSCs enthalten kann. Somit komponiert 

ein bMSC, Ereignisse, ein HMSC, bMSCs, und ein MSC mit Strukturen sowohl 

Ereignisse als auch bMSCs. Diese Struktur führt zu der Annahme, dass Ereignisse 

anstatt bMSCs die kleinsten zu betrachtenden Einheiten sind. Ein lposet repräsentiert 

somit ein Ereignis, als kleinste Einheit, einen Teil eines MSC oder ein komplettes 

MSC. 

3.4.3 Besonderheiten der Basic MSC (bMSC) 

Es wird an dieser Stelle angenommen, dass bMSCs nur Ereignisse beinhalten. Da 

diese Ereignisse die Basiseinheiten darstellen, kann ein bMSC mit Hilfe von Ereignissen, 

durch Verwendung der sequentiellen Komposition definiert, über lposets 

komponiert werden. Dabei ist es wichtig, dass die einzelnen Ereignisse eindeutig benannt 

werden. Die Semantik des bMSC wird über ein lposet definiert, das alle Ereignisse 

beinhaltet und deren Reihenfolge spezifiziert. Entlang jeder Instanz-Achse sind 

Ereignisse von oben nach unten zu ordnen. Zwischen verschiedenen Instanzen, 

muss ein Nachrichtenausgangsereignis vor dem korrespondierenden Nachrichteneingangsereignis 

auftreten.

3.4.4 Besonderheiten von MSC mit Strukturen 

Ein MSC mit Strukturen kann mit einem lposet oder mit einer Menge von lposets repräsentiert 

werden. Dann ist die Semantik eines MSC mit Strukturen die sequentielle 

Komposition dieser Strukturen und den anderen Ereignissen im MSC. 

Eine MSC-Reference wird benutzt um ein einzelnes MSC oder MSC-Expression zu 

referenzieren. Eine MSC-Reference kann durch Zeitintervalle bedingt werden. Ein 

Zeitintervall spezifiziert die Zeitdauer zwischen dem ersten und letzten Ereignisses 

einer MSC-Reference. Dabei ist zu beachten, dass eine Referenz mehrere erste und 

letzte Ereignisse beinhaltet kann, so dass die Zeitdauer jedes dieser Ereignispaare 

durch das definierte Zeitintervall spezifiziert wird. 

Im MSC-Standard werden verschiedene Operatoren spezifiziert um MSCs zu definieren. 

Im semantischen Modell nach [ZhKH02] werden folgende Operatoren definiert, 

die für die Spezifikation von Echtzeiteigenschaften relevant sind: sequence (seq), 

alternation (alt), parallel (par) und iteration (loop). Diese Operationen können auf die 

Operationen der lposets abgebildet werden. Dies führt für zwei MSCs oder Inline- 

Operanden A und B zu folgenden Abbildungen: 

Für den noch ausstehenden Operator loop, ist die Abbildung der Semantik aufgrund 

der absoluten Verzögerungen etwas komplizierter. Wird M benutzt, um ein bMSC zu 

repräsentieren, dann könnte ein beliebiges Ereignis in M, welches durch eine absolute 

Zeitbedingung näher spezifiziert ist, Auswirkungen auf die Anzahl der Ausführungen 

von M haben. Eine absolute Verzögerung könnte im Konflikt mit der Iterationsgrenze 

stehen. Aus diesem Grund darf ein MSC in einer Iteration nur einmal ausgeführt 

werden, sobald ein Ereignis durch einen absoluten Zeitpunkt bedingt ist. Wenn 

alle Ereignisse in einem MSC durch keine absolute Verzögerung eingeschränkt sind, 

dann ist die Anzahl der Ausführungen des MSC in einer Iteration nur durch die Iterationsgrenze 

beschränkt. Somit kann ohne die Wahl des Zeitbereichs einschränken zu 

wollen die Semantik des loop-Operators durch folgende Mengen von lposets definiert 

werden: 

Hier repräsentiert m die aktuelle Anzahl der Ausführungen von A. Die Bestimmung 

von m erfolgt durch die absoluten Zeitbedingungen der Ereignisse in A. Wenn die 

absolute Verzögerung eines Ereignisses ein Zeitpunkt ist, dann gilt stets m = 1. Im 

Zeitbereich der ganzen Zahlen kann m kleiner als j oder sogar als i sein. Für k > 0 

wird definiert: 

Wird M[A k ] berechnet, so ist es notwendig alle Nachrichten- und Timer-Ereignisse so 

umzubenennen, dass jedes dieser Ereignisse eindeutig für die Iteration ist. Wenn ein 

loop unendlich ist, kann die Menge eine unendliche Anzahl an lposets beinhalten. 


3.4.5 Besonderheiten der High-Level MSC (hMSC) 

Ein HMSC ist ein gerichteter Graph, in dem MSCs als Knoten repräsentiert sind und 

Geraden die Knoten verbinden, um die möglichen Ausführungssequenzen entlang 

der Knoten zu definieren. Die seq-, alt- und par-Operatoren können in HMSCs verwendet 

werden. Die Iteration kann in einem hMSC durch Verwendung des loop- 

Operators umschrieben werden. Somit ist es möglich ein hMSC zu einem MSC- 

Ausdruck zu transformieren. Die Conditions in hMSCs werden außer Acht gelassen. 

Der Vorgang der Transformation eines HMSC in einen MSC-Ausdruck wird in 

[ZhKH02] näher beschrieben. 

Für ein HMSC H, das die Menge von lposets besitzt, wird die Menge der 

Traces von H wie folgt definiert: 

für jedes 

Im nächsten Abschnitt wird das semantische Modell für zeitbehaftete MSCs am Beispiel 

einer Anwendung für eingebettete Systeme angewendet. 


4 Beispiel 

In diesem Abschnitt wird die Umsetzung des Vorgehens zur Spezifikation von Echtzeiteigenschaften 

in eingebetteten Systemen illustriert. Dazu wird ein Beispiel genommen. 

4.1 Anwendungskontext 

Das Anwendungsbeispiel stammt aus der Domäne der Logistik. Konkret geht es um 

einen automatisierten Containerhafen. Dieses Anwendungsbeispiel ist angelehnt an 

SOAHarbor (s. [SOAH10]), eine Plattform, die eine Service-orientierte Architektur 

(SOA) für eingebettete Systeme realisiert. In diesem Projekt wurde eine SOA für einen 

Miniaturhafen zur Steuerung der Entladung und Beladung von Containern entwickelt. 

Dazu wurden Lego Mindstorms (Roboter, die mit Hilfe einer Java-Engine programmiert 

werden können) eingesetzt, die ein sensorbasiertes Dock, eine Ladebrücke, 

ein Containerfließband, einen Containeraufzug und einen Gabelstapler als eingebettetes 

System repräsentieren. Des Weiteren beinhaltet das Containerhafensystem 

ein Informationssystem, das systemrelevante Daten zu Verfügung stellt. 

Das sensorbasierte Dock erkennt über einen RFID-Sensor, dass ein neues Containerschiff 

in den Hafen eingelaufen ist und startet einen Prozess zum Entladen und 

Beladen des Schiffs. Die Ladebrücke ist für die Entladung des eingelaufenen Containerschiffs 

zuständig und steuert alle dazu notwendigen Interaktionen mit den anderen 

Robotern des Containerhafens. Die Beladung des Containerschiffs und die dafür 

notwendigen Interaktionen werden vom Gabelstapler gesteuert. 

4.2 Spezifikation der Echtzeiteigenschaften 

Dieser Abschnitt behandelt die Spezifikation des Anwendungsbeispiels durch ein 

zeitbehaftetes MSC nach dem im Abschnitt 3 vorgestellten semantischen Modell. Im 

Folgenden werden die Anforderungen an das System beschrieben. 

4.2.1 Anforderungen an das SOAHarbor-System 

Folgende natürlich-sprachliche Anforderungsbeschreibung an das SOAHarbor- 

System liegt vor: 

A1) Sobald ein neues Containerschiff in den Hafen eingelaufen ist, wird der 

Entladungsprozess initialisiert. 

A2) Basierend auf der ID des Containerschiffs, wird der zu entladene Container 

anhand der korrespondierenden Container-ID identifiziert. 

A3) Bevor mit der Entladung des Containers begonnen werden kann, ist die 

Ladebrücke zu kalibrieren und in die Ausgangslage zu bringen, um die 

Voraussetzungen für eine fehlerfreie Entladung zu schaffen. 

A4) Sind die in A3) beschriebenen Voraussetzungen geschaffen, ist mit der 

Entladung des Containers zu beginnen. 

Dabei sind folgende Echtzeitanforderungen zu erfüllen: 

EA1) Die Entladung eines Containers soll im ungünstigsten Fall bei günstigen 

Randbedingungen (keine technischen Defekte oder unerwarteten Störungen) 

innerhalb von 420 Sekunden erfolgen. Diese Zeitbedingung ist 

Voraussetzung für die Einhaltung der maximalen Gesamtentladungszeit 

des Containerschiffs. 


EA2) Die Ladebrücke darf frühestens zur 32.Sekunde zur Entladung des 

Containers aufgerufen werden. Eine Überschreitung dieser Deadline 

könnte dazu führen, dass die Kalibrierung der Ladebrücke noch nicht 

abgeschlossen ist oder diese sich noch nicht am definierten Ausgangspunkt 

befindet und somit die Anforderung A3) nicht erfüllt werden kann. 

Die Echtzeiteigenschaften an das zu spezifizierende System sind nicht Teil der Anforderungsbeschreibung, 

da diese durch äußere Umstände wie z. B. die Performance 

der Hardware-Plattform und der zugrundeliegenden technischen Infrastruktur 

vorgegeben sind. Die konkreten Zeitwerte der Echtzeiteigenschaften des Systems 

bzw. der eingebetteten Aktivitäten können über durchgeführte Messungen oder Befragung 

von Domänenexperten gewonnen werden. Die Modellierung und Spezifikation 

dieser Echtzeiteigenschaften des zugrundeliegenden Anwendungsbeispiels werden 

im nächsten Unterkapitel vorgestellt. 

4.2.2 Formale Spezifikation des Anwendungbeispiels 

Die Spezifikation des Anwendungsbeispiels wird in Abbildung 4-1 und Abbildung 4-2 

repräsentiert. Fehler! Verweisquelle konnte nicht gefunden werden. Abbildung 

4-1 zeigt die bMSC-Spezifikationen der eingebetteten Basisaktivitäten, die von der 

hMSC-Spezifikation unload_container referenziert werden. Die hMSC-Spezifikation 

definiert die Ausführungsstruktur der referenzierten Basisaktivitäten, die im Folgenden 

beschriebenen werden. Die bMSC-Spezifikation receive_RS definiert die Instanziierung 

eines zentralen Systemsteuerungsprozesses (Process) zur 0.Sekunde, 

durch das sensorbasierte Dock (RS), das die Schiffs-RFID an den Prozess übermittelt. 

Der danach folgende assign Operator kopiert den Inhalt der Variablen RFID in die 

Variable shipRFID, was im bMSC assign_1 modelliert wird. Das bMSC invoke_IS 

spezifiziert die Identifizierung des zu entladenden Containers anhand der bekannten 

shipRFID durch Aufruf des Informationssystems (IS) und Empfang der Variablen 

RFID. Nachdem es bekannt ist, welcher Container entladen werden muss, ruft der 

zentrale Systemsteuerungsprozess die Ladebrücke (LB) auf, um die Kalibrierung der 

Ladebrücke zu initialisieren. Diese antwortet dem Prozess, sobald mit der Kalibrierung 

begonnen wurde. Diese Interaktion wird durch das bMSC invoke_LB_1 spezifiziert. 


Abbildung 4-1 - bMSC-Spezifikationen des Anwendungsbeispiels 

Das Kopieren des Inhalts der Variablen RFID in die Variable containerRFID und das 

Blockieren des Prozesses für 20 Sekunden wird mit Hilfe einer parallele Komposition 

der bMSCs wait_1 und assign_2 im hMSC unload_container spezifiziert (s. Abbildung 

4-2). Diese parallele Komposition bewirkt zum einen eine Verringerung der Gesamtausführungszeit 

des zentralen Systemsteuerungsprozesses (gegenüber einer 

sequentiellen Komposition der beiden entsprechenden bMSCs) und zum anderen die 

geforderte Wartezeit für die Kalibrierung der Ladebrücke. Danach wird die Entladung 

des Containers durch Aufruf der Ladebrücke angestoßen. Die Ladebrücke sendet 

dem zentralen Systemsteuerungsprozess eine Antwort, sobald die Entladung des 

Containers abgeschlossen wurde. Der Empfang dieser Antwortnachricht repräsentiert 

das Endereignis des gesamten Prozesses. Die zuletzt beschriebene Interaktion 

wird im bMSC invoke_LB_2 spezifiziert. 


Abbildung 4-2 – hMSC-Spezifikation des Anwendungsbeispiels 

Tabelle 4-1 – Beziehung zwischen Spezifikation und AnforderungenTabelle 4-1 skizziert 

die Beziehungen zwischen den Anforderungen und der Spezifikation SOAHarbor 

Systems. Die Tabelle stellt die Anforderungen den assoziierten MSC- 

Spezifikationen gegenüber. 

Tabelle 4-1 – Beziehung zwischen Spezifikation und Anforderungen 

Anforderung Spezifikation 

A1) MSC reveive_RS 

A2) 

A3) 

A4) 

MSCs invoke_IS, assign_1 

MSCs invoke_LB_1, wait_1 

MSCs invoke_LB_2, assign_2 

Ob auch die Echtzeitanforderungen an das SOAHarbor System erfüllt werden, kann 

erst durch die Validierung der Echtzeiteigenschaften des Prozesses überprüft werden. 

Die Echtzeitanforderung EA1) wird durch die relative Zeitbedingung [tmin_bq, 

420s] in Abbildung 4-2 repräsentiert. Die absolute Zeitbedingung @[32s, Tmax_n] im 


HMSC unload_container spezifiziert die Echtzeitanforderung EA2). Die vorgegebenen 

Echtzeiteigenschaften des SOAHarbor Systems sind in den BMSC- 

Spezifikationen in Abbildung 4-1 spezifiziert. 


5 Zusammenfassung 

In diesem Dokument wurde eine Erweiterung der COSMOD-RE Methode vorgestellt, 

die das Ziel hat, Instrumente für die Modellierung von Echtzeitanforderungen in eingebetteten 

Systemen anzubieten. Diese Erweiterung kann dazu helfen, dass früh 

erkannte Zeitaspekte zusammen mit den anderen Anforderungen an das eingebettete 

System validiert werden. Da Zeitaspekte in den Anforderungen nur die dynamischen 

Modelle einer Spezifikation betreffen, wirkt sich die Erweiterung der 

COSMOD-RE Methode nur auf die Szenariomodelle aus. Dabei ist die Erweiterung 

an einem semantischen Modell zur formalen Spezifikation von zeitbehafteten Message 

Sequence Charts angelehnt. Die erläuterten Konzepte in diesem Dokument 

wurden im letzten Abschnitt 4 an einem Beispiel evaluiert. 


6 Literaturverzeichnis 

Seli96Seli96AlHP9 

6 

Alur, Rajeev; Holzmann, Gerard J.; Peled, Doron. An Analyzer 

for Message Sequence Charts. Lecture Notes in Computer 

Science, Volume 1055/1996, 35-48, Springer Berlin/Heidelberg. 

1996. 

ELLS97 Edwards, Stephen; Lavagno, Luciano; Lee, Edward A.; Sangiovanni–Vincentelli, 

Alberto. Design of Embedded Systems: 

Formal 

Models, Validation, and Synthesis. Proceedings of the IEEE, 

Band 85, Heft 3, S. 366-390. März 1997. 

Heym98 Heymer, Stefan. A Non-Interleaving Semantics for MSC. Proceedings 

2. Workshop of the SDL Forum Society on SDL and 

MSC - SAM’98. Berlin, Deutschland. Juni 1998. 

Itut04 ITU-T Z.120. Series Z: Languages and General Software Aspects 

for Telecommunication Systems, Formal description 

techniques (FDT) – Message Sequence Chart (MSC). 

. April 2004 

Kerb07 Kerber, Kai Lennard. Performance Message Sequence Chart – 

Sprache zur Leistungsvorhersage mittels der Generierung eines 

Prototypen im Kontext des Protokollentwurfs mit SDL und 

MSC, Dissertation Universität Erlangen-Nürnberg, 2007. 

Kope97 Kopetz, Hermann. Real-Time Systems: Design Principles for 

Distributed Embedded Applications. Kluwer International Series 

in Engineering & Computer Science. 1997. 

OMG05 Object management Group (OMG). UML Profile for Schedulability, 

Performance, and Time Specification. Version 1.1, formal/05-01-02. 

Januar 2005. 

Pohl10 Pohl, Klaus. Requirements Engineering – Foundations, Principles, 

Techniques. Springer, 2010. 

Seli96 Selic, Bran. Tutorial: Real-Time Object-Oriented Modeling 

(ROOM). 

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=0050953 

8. 1996 

SOAH10 Projekt-Blog: SOAHarbor - SOA for embedded systems, < 

http://soaharbor.blogspot.com/> 2010. 

Wolf94 Wolf, Wayne H. Hardware-Software Co-Design of Embedded 

systems. Proceedings IEEE, Band 82, Heft 7, S. 967-989. Juli 

1994 

ZhKH02 Zheng, Thong; Khendek, Ferhat; Helouet, Loic. A Semantics 

forTimed MSC, Elsevier Science B. V., 2002. 

KGSB98 Krüger, Ingolf; Grosu, Radu; Scholz, Peter; Broy Manfred. 

From MSCs to Statecharts. Proceedings DIPES’98, IFIP 

WG10.3/WG10.5 International Workshop on distributed and 

parallel Systems. 1998.

download - SPES 2020

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?