Entwicklung Eines Leitfadens Für Das Requirements Engineering

See discussions, stats, and author proﬁles for this publication at: https://www.researchgate.
net/publication/215569487
Entwicklung eines Leitfadens für das Requirements Engineering

softwareintensiver Eingebetteter Systeme
Article · January 2009
CITATION READS
1 131
8 authors, including:
Peter Braun Mark Müller

Validas AG Robert Bosch GmbH
37 PUBLICATIONS 395 CITATIONS 4 PUBLICATIONS 27 CITATIONS
SEE PROFILE SEE PROFILE
Birgit Penzenstadler Klaus Pohl

California State University University of Duisburg-Essen
127 PUBLICATIONS 904 CITATIONS 288 PUBLICATIONS 9,533 CITATIONS
SEE PROFILE SEE PROFILE
Some of the authors of this publication are also working on these related projects:
CrESt - Collaborative Embedded Systems View project
NaPiRE: Naming the Pain in Requirements Engineering View project
All content following this page was uploaded by Birgit Penzenstadler on 21 May 2014.
The user has requested enhancement of the downloaded ﬁle.

TUM
I N S T I T U T F Ü R I N F O R M A T I K
Entwicklung eines Leitfadens für das
Requirements Engineering softwareintensiver
Eingebetteter Systeme
Peter Braun, Manfred Broy, Frank Houdek, Matthias
Kirchmayr, Mark Müller, Birgit Penzenstadler, Klaus Pohl,
Thorsten Weyer (Hrsg.)
TUM-I0934
Dezember 09
T E C H N I S C H E U N I V E R S I T Ä T M Ü N C H E N
TUM-INFO-12-I0934-0/1.-FI
Alle Rechte vorbehalten
Nachdruck auch auszugsweise verboten
c 2009
!
Druck: Institut für Informatik der

Technischen Universität München
Entwicklung!eines!Leitfadens!für!das!!
modellbasierte!Requirements"Engineering!!
softwareintensiver!Eingebetteter!Systeme!
Zusammenfassender!inhaltlicher!Abschlussbericht!zum!
BMBF"Verbundprojekt!„REMsES“!
!
Peter!Braun!
Manfred!Broy!
Frank!Houdek!
Matthias!Kirchmayr!
Mark!Müller!
Birgit!Penzenstadler!
Klaus!Pohl!
Thorsten!Weyer!
(Hrsg.)!
!
!
!
REMsES!Konsortium:"
U ni ve r s i tä t! D u i s b u r g " E s s en!
Software!Systems!Engineering!
Prof.!Dr.!Klaus!Pohl!!
( P r oj ek tl ei tu ng)!
D a i ml e r! A G , ! U l m!
Dr. !Ma tthias !Ki rchmay r !
R o be r t ! B os c h ! G m bH , ! S c h wi e be r d i n g e n !
Dr. !Ma rk!Müller !
Techni sche!Uni versi tät!München!

Software!&!Systems!Engi neering!
Prof.!Dr.!Manfred!Broy!
Vali das! AG, !Mü nchen!

D r . ! P e te r! B r a u n !
!
Kontakt:"
U ni ve r s i tä t! D u i s b u r g " E s s en!
Software!Systems!Engineering!
S c h ü tz e n ba h n ! 7 0 !
45112!Essen!
Tel.:! +49!201!183!4651!
Fa x:! +49!201 !183!4699!
Email:!info@remses.org!
Das!diesem!Beri cht!zugrunde!li egende !Vorha ben!wurde!mi t!Mi tteln!

des !Bu ndesmi nis teriums! für!Bil du ng !und! Forschu ng !unter! dem! För"
derkennzeichen!01 ISF06 D!gefördert.!Die!Vera ntwortu ng!für!den!
Inhalt!di eser!Veröff entlichung!l i e g t! b e i m! A u t o r . !
ii!
!
Vorwort!
Gerade!in!den!letzten!Jahren!haben!die!Funktionsvielfalt!und!die!Komple"
xität!der!einzelnen!Funktionen!bei!Eingebetteten!Systemen!außerordentlich!
zugenommen.! Moderne! Kraftfahrzeuge! verfügen! über! mehr! als! 3000! soft"
waregesteuerte! Funktionen.! Diese! leiten! sich! aus! immer! umfangreicher!
werdenden! Spezifikationen! ab.! So! umfasst! ein! typisches! Spezifikationsdo"
kument! eines! modernen! Kombiinstruments! mittlerweile! mehr! als! 20.000!
Anforderungen.! Eine! systematische! und! zielgerichtete! Erfassung,! Struktu"
rierung,! Dokumentation! und! Verwaltung! dieser! Anforderungen! ist! daher!
von!entscheidender!Bedeutung.!Während!derzeit!oftmals!noch!zu!beobach"
ten! ist,! dass! einzelne! „lokale! Helden“! mit! reichem! Erfahrungswissen! Pro"
jekterfolge! ermöglichen,! ist! zu! erwarten,! dass! die! derzeit! eingesetzten! ad"
hoc!Ansätze!zur!Spezifikation!von!Anforderungen!an!ihre!Grenzen!stoßen.!
Aufgrund! der! großen! und! weiter! wachsenden! Bedeutung! Eingebetteter!

Systeme!für!die!deutsche!Automobilindustrie!ist!die!Beherrschung!der!Re"
quirements"Engineering!und!"Management"Prozesse!eine!immer!wichtige"
re! Fähigkeit,!die!zunehmend!den!wirtschaftlichen!Erfolg!bestimmen!wird.!
Dies! gilt! umso! mehr! aufgrund! der! stark! arbeitsteiligen! Entwicklung! mit!
vielen! kleinen! und! mittleren! Zulieferern.! Nur! mit! geeigneten! Techniken!
und!Methoden!werden!in!Zukunft!die!Komplexität!von!Systemen!und!Sys"
temverbünden!beherrschbar!bleiben.!
In!diesem!Spannungsfeld!wurde!im!Rahmen!der!Förderinitiative!„Software!
Engineering! 2006“! des! Bundesministeriums! für! Bildung! und! Forschung!
(BMBF)!das!Verbundprojekt!„REMsES“!im!August!2006!mit!einer!Laufzeit!
von!drei!Jahren!gestartet.!Als!Partner!haben!sich!die!Technische!Universität!
München,! die! Universität! Duisburg"Essen,! die! Daimler! AG,! die! Robert!
Bosch! GmbH! und! die! Validas! AG! mit! dem! Ziel! zusammengeschlossen,!
einen! Praxisleitfaden! für! das! modellbasierte! Requirements"Engineering!
softwareintensiver!Eingebetteter!Systeme!(REMsES)!zu!entwickeln.!Betreut!
wurde! das! Vorhaben! durch! den! Projektträger! Softwaresysteme! im! Deut"
schen!Zentrum!für!Luft!und!Raumfahrtechnik.!
iii!
Der!vorliegende!Abschlussbericht!fasst!die!wichtigsten!inhaltlichen!Ergeb"
nisse! des! Forschungsprojekts! zusammen.! Besonders! hervorzuheben! ist!
hierbei!der!erarbeitete!Leitfaden,!der!auf!den!folgenden!Prinzipien!basiert:!
! Einsatz!von!Abstraktionsebenen!und!Dekomposition!in!der!System"
betrachtung!
! Unterscheidung! von! Kontext,! Anforderungen! und! Architekturent"

wurf!
! Durchgehende!Modellbasierung!
! Artefaktgetriebenes!Vorgehen!
Der!entwickelte!Leitfaden!wurde!anhand!von!Beispielen!werkzeuggestützt!
dokumentiert! und! unter! anderem! durch! Fachexperten! bewertet! und! in!
Fallstudien!und!Experimenten!evaluiert.!
Die! im! Leitfaden! dokumentieren! Methoden! und! Techniken! können! Ihnen!

insbesondere! helfen,! die! Qualität! Ihrer! Spezifikationen! zu! verbessern,! die!
Komplexität! zu! bewältigen! und! Ihre! Spezifikationsprozesse! besser! zu!
strukturieren.!
Siehe!hierzu!auch!zusammenfassende!Posterpräsentation!in!Abschnitt!8.1!
iv!
!
Inhaltsverzeichnis!
1 Einleitung".............................................................................................................."1
2 AP!1:"Ermittlung"der"Anforderung"an"den"Leitfaden"..................................."3
2.1 Analyse!des!Stand"der"Praxis!zu!Projektbeginn!..............................................!4
2.2 Analyse!des!Stand"der"Wissenschaft!zu!Projektbeginn!..................................!5
2.3 Ermittlung!der!Anforderungen!an!den!REMsES"Leitfaden!...........................!6
3 AP!2:"Erarbeitung"der"Grobstruktur"des"Produktmodells"..........................."7
4 AP!3:"Ausarbeitung"des"Leitfadens"auf"den"drei"Abstraktionsstufen"....."11
4.1 Thema!I:!Durchgängige!Verfeinerung!von!Zielen!.........................................!12
4.2 Thema!II:!Kontextbetrachtung!und!Kontextverfeinerung!............................!12
4.3 Thema!III:!Entwicklung!und!Verfeinerung!von!Zielen!und!Szenarien!.......!13
4.4 Thema!IV:!Ableitung!lösungsorientierter!Anforderungen!...........................!14
4.5 Thema!V:!Abhängigkeitssicht!auf!der!Gesamtsystemebene!.........................!14
4.6 Thema!VI:!Transition!von!Gesamtsystem!auf!Subsystem!............................!15
4.7 Thema!VII:!Artefaktqualitätsgetriebene!Vorgehensplanung!.......................!15
4.8 Thema!VIII:!Modellierung!von!Qualitätsanforderungen!..............................!16
4.9 Der!REMsES!Leitfaden!.......................................................................................!16
5 AP!4:"Evaluation"des"REMsES!Leitfadens"...................................................."19
5.1 Validierungsprozess!...........................................................................................!19
5.2 Empirische!Ergebnisse!.......................................................................................!21
5.3 Threats!to!validity!...............................................................................................!25
6 AP!6:"Erstellung"von"Illustratoren".................................................................."27
6.1 Dynamische!Scheibentönung!(DST)!................................................................!27
6.2 Radio"Frequenz"Warnsystem!(RFW)!...............................................................!28
6.3 Neuspezifikation!RFW!anhand!des!REMsES"Leitfadens!..............................!29
v!
7 AP!7:"Entwicklung"spezifischer"Erweiterungen"des"Leitfadens"..............."31
7.1 AP"7.1:!Verbesserung!der!Auftraggeber/Auftragnehmer"Beziehungen!.....!31
7.2 AP"7.2:!Erweiterung!für!die!Produktlinienentwicklung!...............................!33
7.3 AP"7.3:Entwicklung!eines!REMsES"Werkzeuges...........................................!37
8 Posterpräsentation"............................................................................................."41
8.1 „Herausforderungen!des!REMsES"Projektes“................................................!42
8.2 „Bestandteile!des!REMsES"Leitfadens“!...........................................................!43
8.3 „Kontextanalyse!und!Kontextverfeinerung“!..................................................!44
8.4 „Ableitung!von!lösungsorientierten!Anforderungen“!..................................!45
8.5 „Ziel"!und!szenariobasiertes!Requirements!Engineering“!...........................!46
8.6 „Erkennung!von!Feature!Interactions!auf!Nutzungsebene“!........................!47
8.7 „Transition!von!Gesamtsystem!auf!Subsystem“!............................................!48
9 Zusammenfassung"und"Ausblick"..................................................................."49
10 Veröffentlichungen"des"REMsES!Projekts"..................................................."51
vi!
!
Abbildungsverzeichnis!
Abbildung!1:!Schematische!Darstellung!der!Kern"!und!Umfeldprozesse!..................!7
Abbildung!2:!Die!neun!Artefaktklassen!des!REMsES"Artefaktmodells!.....................!9
Abbildung!3:!Beispiel!einer!Abbildungsbeschriftung!.................................................!17
Abbildung!4:!Validierungsstrategie!...............................................................................!19
Abbildung!5:!Verständlichkeit!von!REMsES"Elementen!im!Median!........................!22
Abbildung!6:!Qualitäts"Kennzahl!der!einzelnen!Spezifikationen!.............................!22
Abbildung!7:!Im!Experiment!gefundene!Interaktionen!..............................................!23
Abbildung!8:!Gesamtaufwände!der!Teams!..................................................................!24
Abbildung!9:!Aufwände!der!Teams!pro!Phase!............................................................!24
Abbildung!10:!Auszug!aus!dem!Artefakt!„Datenmodell“!am!Beispiel!....................!29
Abbildung!11:!Kompatibilität!als!Voraussetzung!für!Integrierbarkeit!.....................!32
Abbildung!12:!Notationselemente!für!Variabilitätsmodelle!im!REMsES"Ansatz!...!34
Abbildung!13:!Beispiel!für!Variabilitätsmodelle!im!REMsES"Ansatz!.......................!35
Abbildung!14:!Beispielhafte!Beziehungen!zu!REMsES"Artefakten!...........................!35
Abbildung!15:!Ausschnitt!der!Variabilitätsmodells!„DST“!........................................!36
Abbildung!16:!Variable!Spezifikation!von!Szenarien!im!REMsES"Ansatz!...............!36
Abbildung!17:!Das!REMsES"Werkzeug!.........................................................................!37
!
!
1 Einleitung"
Ziel! des! REMsES"Projektes! war! die! Entwicklung! eines! praxiserprobten!
Leitfadens! für! das! modellbasierte! Requirements! Engineering! und! Mana"
gement! softwareintensiver! Eingebetteter! Systeme.! Die! Arbeiten! innerhalb!
des!REMsES"Projektes!waren!dabei!in!insgesamt!zehn!Arbeitspakete!unter"
teilt:!
! AP"1:! „Erhebung! von! Anforderungen! an! den! Leitfaden“:! Szenariobasierte!

Analyse! und! Entwicklung! der! wesentlichen! Anforderungen! an! den!
REMsES"Leitfaden!(siehe!Kapitel!2).!
! AP"2:! „Erarbeitung! der! Grobstruktur! des! Produktmodells“:! Ausarbeitung!

der! Grobstruktur! des! Produktmodells! (REMsES"Artefaktmodell)! und!
Beschreibung!der!Schnittstellen!zu!Umfeldprozessen!des!Requirements!
Engineering!und!Management!(siehe!Kapitel!3).!
! AP"3:! „! Ausarbeitung! des! Leitfadens“:! Ausarbeitung! des! detaillierten!

REMsES"Leitfadens! entlang! der! drei! Systemebenen! „Gesamtsystem“!
(AP"3.1),! „Funktionsgruppen“! (AP"3.2)! und! Hardware/Software! (AP"
3.3)!(siehe!Kapitel!4)!
! AP"4:! „Validierung! des! Leitfadens“:! Evaluation! des! ausgearbeiteten!

REMsES"Leitfadens!auf!den!drei!Systemebenen!„Gesamtsystem“!(AP"
4.1),! „Funktionsgruppen“! (AP4.2)! und! Hardware/Software! (AP"4.3)!
(siehe!Kapitel!5)!
! AP"5:!„Konsolidierung!und!Verbesserung!des!Leitfadens“:!Analyse!der!Eva"
luationsergebnisse! und! Verbesserung! des! REMsES"Leitfadens! auf!
Grundlage!der!Evaluationsergebnisse.!
! AP"6:!„Erstellung!von!Illustratoren“:!Erstellung!von!Illustratoren!für!die!
Anwendung! des! REMsES"Leitfadens! anhand! ausgewählter! praxisna"
her!Systeme!(siehe!Kapitel!6.)!
! AP"7:!„Anwendung!des! Leitfadens! auf!spezifische! Fragestellungen“:!Erwei"

terung!des!REMsES"Leitfadens!um!Ergänzungen!für!spezifische!Frage"
stellungen!aus!der!Praxis.!Anwendung!des!REMsES"Leitfadens!auf!die!
1!
„Auftraggeber"/Auftragnehmer"Beziehung“! (AP"7.1),! die! Produktli"
nienentwicklung!(AP"7.2)!sowie!auf!„Werkzeuge!im!REM“!
! AP"8:! „Integration! und! finale! Konsolidierung! und! Verbesserung“:! Analyse!

finaler! Evaluationsergebnisse! des! REMsES"Leitfadens! und! Durchfüh"
rung! von!Maßnahmen!zur!Konsolidierung,!Integration!und!Verbesse"
rung!der!REMsES"Arbeitsergebnisse.!
! AP"9:! „Verbreitung! der! Ergebnisse“:! Projektbegleitende! Verbreitung! der!

erarbeiteten!REMsES"Ergebnisse!in!der!Forschung,!Entwicklung!sowie!
der!betrieblichen!Praxis.!
! AP"10:! „Projektmanagement“:! Projektbegleitende! Durchführung! von!

Maßnahmen!zur!Projektkontrolle!und!Projektsteuerung,!darauf!ausge"
richtet,!die!Zielsetzung!des!REMsES"Projektes!zu!erfüllen.!
Die! Arbeitspakte! im! REMsES"Projekt! können! in! drei! Klassen! eingeordnet!

werden:!
! Inhaltliche!Arbeitspakete:!Hierzu!zählen!diejenigen!Arbeitspakte,!die!auf!
die!Ausarbeitung!der!REMsES"Inhalte!abzielen!(d.h.!auf!den!REMsES"
Leitfaden!und!dessen!Erweiterungen).!Hierzu!zählen!die!Arbeitspake"
te!AP"1,!AP"2,!AP"3,!AP"4,!AP"6!und!AP"7.!
! Arbeitspakete! zur! Verbesserung! und! Konsolidierung:! Hierzu! zählen! dieje"

nigen! Arbeitspakete,! die! auf! die! stetigen! Integration! und! Konsolidie"
rung! der! inhaltlichen! Arbeitspakete! abzielen.! Hierzu! zählten! die! Ar"
beitspakete!AP"5!und!AP"8.!
! Administrative! Arbeitspakete:! Hierzu! zählen! diejenigen! Arbeitspakete!

die! auf! die! Verbreitung! der! Ergebnisse! und! das! Projektmanagement!
des!REMsES"Projektes!abzielen.!Hierzu!zählten!die!Arbeitspakete!AP"9!
und!AP"10.!
Im! Folgenden! werden! die! Ergebnisse! der! inhaltlichen! Arbeitspakete! im!

REMsES"Projekt!zusammenfassend!dargestellt.!!
2!
!
2 AP!1:"Ermittlung"der"Anforderung"an"den"
Leitfaden"
Nadine!Bramsiepe!
Günter!Halmans!
Ernst!Sikora!
Universität!Duisburg"Essen!
Eva!Geisberger!
Johannes!Grünbauer!
Technische!Universität!München!
Eduard!Metzker!
Daimler!AG!
Der!vorliegende!Abschnitt!fasst!die!Ergebnisse!des!Arbeitspaketes!AP"1!im!
REMsES"Projekt! zusammen.! Zielsetzung! dieses! Arbeitspakets! war! es,! die!
wesentlichen!Anforderungen!an!den!zu!entwickelnden!REMsES"Leitfaden!
zu! identifizieren.! Zu! diesem! Zwecke! wurde! zunächst! eine! Befragung! von!
Unternehmen! aus! unterschiedlichen! Anwendungsgebieten! durchgeführt,!
um! die! individuellen! Vorstellungen! und! Ansprüche! in! Bezug! auf! den! zu!
entwickelnden!Leitfaden!er!ermitteln.!Anschließend!wurde!im!Rahmen!der!
systematischen! Analyse! überprüft,! inwieweit! Ansätze! im! Stand"der"
Wissenschaft!ausgewählten!Anforderungen!der!befragten!Industriepartner!
genügen!bzw.!inwieweit!im!Stand"der"Wissenschaft!Lücken!bezüglich!aus"
gewählter! Anforderungen! bestehen.! Ausgehend! von! dieser! Analyse! wur"
den!dann!die!für!die!weiteren!Arbeiten!im!REMsES"Projekt!für!zentral!er"
achteten!Themenkomplexe!identifiziert.!!
Die! Identifikation! der! im! REMsES"Projekt! zu! bearbeitenden! Themenkom"

plexe!führte!zu!einer!Positionierung!des!REMsES"Projekts!in!der!gegenwär"
tigen! „Forschungslandschaft“,! indem! das! REMsES"Vorhaben! von! ähnli"
chen! Forschungsvorhaben! abgegrenzt! und! Synergien! mit! anderen! For"
schungsprojekten! aufgezeigt! wurden.! Zum! Abschluss! des! Arbeitspaketes!
wurden! die! Anforderungen! und! Ziele! der! einzelnen! Beteiligten! konsoli"
3!
diert! und! die! wesentlichen! konsolidierten! Anforderungen! an! den! zu! erar"
beitenden!Leitfaden!formuliert.!!
Die! wesentlichen!Ergebnisse!von!AP"1,!d.h.!die!Rahmenbedingungen!und!
Ergebnisse! der! Industriebefragung,! die! Analyse! des! Stand"der"
Wissenschaft! und! die! konsolidierten! Ziele! und! Anforderungen! an! den!
REMsES"Leitfaden!sind!in![REMsES!2006]!dokumentiert.!
2.1 Analyse"des"Stand!der!Praxis"zu"Projektbeginn"
Zur! Analyse! der! Ausgangssituation! im! Requirements"Engineering! in! der!
Praxis!wurde!zu!Beginn!des!Arbeitspaketes!AP"1!eine!Ist"Analyse!in!Form!
einer! Befragung! zum! Thema! „Wie! wird! Requirements"Engineering! und! "
Management!in!Unternehmen!praktiziert?“!durchgeführt.!Im!Rahmen!die"
ser!Umfrage!wurden!13!Vertreter!von!Unternehmen!befragt.!Die!Befragten!
waren! seinerzeit! zum! überwiegenden! Teil! als! Entwickler! bzw.! Projektma"
nager! eingesetzt.! Die! Befragung! basierte! auf! einem! Fragenkatalog! zur! Er"
mittlung!des!aktuellen!Stands!der!Praxis!(Ist"Analyse)!sowie!einem!anderen!
Fragenkatalog,!durch!den!die!Wünsche!und!Erwartungen!der!Befragten!im!
Hinblick! auf! den! zu! erstellenden! Leitfaden! ermittelt! werden! sollten! (Soll"
Analyse).!!
Im!Rahmen!der!Analyse!des!Stand"der"Praxis!zu!Projektbeginn!wurde!mit!
Hilfe! der! Umfrage! für! jede! betrachtete! Aktivität! im! Requirements"
Engineering!(z.B.!Dokumentation!von!Anforderungen)!ermittelt,!wie!diese!
zu! Projektbeginn! durchgeführt! wurde! und! welche! Ansprüche! an! einen!
Leitfaden!in!Bezug!auf!diese!Aktivität!bestehen.!Für!jede!betrachtete!Akti"
vität!wurden!die!typischerweise!beteiligten!Rollen!identifiziert,!der!Zweck!
der! Aktivität! in! Requirements"Engineering"Prozessen! näher! beschrieben,!
sowie! etablierte! „best! practices“! genannt.! Schließlich! wurden! für! jede! der!
Aktivitäten! typische! Problemen! und! gewünschte! Verbesserungen! erfragt!
und!dokumentiert.!
4!
2.2 Analyse"des"Stand!der!Wissenschaft"zu"
Projektbeginn"
Im! Anschluss! an! die! Erhebung! des! Stand"der"Praxis! und! dessen! Analyse!
wurde!der!„Stand!der!Wissenschaft“!in!relevanten!Forschungsbereichen!im!
Detail!aufgearbeitet.!Zu!Beginn!wurden!die!zentralen!für!relevant!erachte"
ten!Technischen!Terme!aus!dem!Requirements!Engineering!sowie!angren"
zender! Disziplinen! identifiziert! und! deren! Begriffsbedeutung! für! das! Pro"
jekt!in!einer!initialen!Version!eines!REMsES"Glossars!festgelegt.!Die!weite"
ren! Arbeiten! im! REMsES"Projekt! über! den! Projektverlauf! gründeten! sich!
dabei! auf! der! Begriffsbedeutung! der! im! REMsES"Glossar! festgelegten!
Technischen!Terme.!Im!Zuge!der!Aufarbeitung!des!Stand"der"Wissenschaft!
und! der! Definition! wesentlicher! Technischer! Terme! wurden! dabei! beson"
ders! aktuelle! Forschungsergebnisse! des! Requirements"Engineering! und! "
Management!für!Eingebettete!Systeme!der!Automotiv"Domäne!berücksich"
tigt,!die!beispielhaft!für!die!Forschung!auf!diesem!Gebiet!bei!der!Entwick"
lung! Eingebetteter! Systeme! stehen.! Auf! Basis! des! Befragungsergebnisse!
und!der!Analyse!des!Stand"der"Wissenschaft!hatten!sich!dabei!einige!zent"
rale!Merkmale!des!REMsES"Leitfaden!herauskristallisiert:!
! Feingranulare! methodische! Unterstützung:! Zur! Unterstützung! der! im!

Rahmen! des! REMsES"Leitfadens! geforderten! methodischen! Anlei"
tung! sollte! auf! grundlegende! Konzepte! des! Method"Engineering!
zurückgegriffen!werden,!die!die!Grundlage!für!eine!„standardisier"
ten“! Dokumentation! der! methodischen! Anleitung! im! REMsES"
Leitfaden!darstellen!sollten.!
! Fokussierung! auf! Artefakte:! Im! Mittelpunkt! der! Definition! des! REM"
sES"Leitfadens! sollten! die! im! Rahmen! von! Requirements! Enginee"
ring"Prozessen!zu!entwickelnden!Arbeitsergebnisse!(Artefakte)!ste"
hen,! deren! Struktur! und! Abhängigkeiten! in! einem! Artefaktmodell!
definiert!werden!sollten.!
! Unterscheidung! dreier! Systemebenen:! Zur! Komplexitätsbeherrschung!
in! Requirements"Engineering"Prozessen! softwareintensiver! Einge"
betteter!Systeme!sollten!verschiedene!Systemebenen!entlang!der!lo"
gischen! und! physikalischen! Dekomposition! des! Gesamtsystems! in!
5!
Funktionsgruppen! bzw.! in! Hardwarebausteine! und! Softwarebau"
steine!unterschieden!werden.!
Diese!drei!zentralen!Konzepte!des!REMsES"Leitfadens!sollten!dabei!derart!
integriert! sein,! dass! die! Systemebenen! ein! wesentliches! Strukturierungs"
merkmal! des! Artefaktmodells! darstellen! und! die! methodische! Anleitung!
jeweils!spezifisch!für!einzelne!Artefakttypen!ausgearbeitet!wird.!
2.3 Ermittlung"der"Anforderungen"an"den"REMsES!
Leitfaden"
Auf! Grundlage! der! Analyse! des! Stand"der"Praxis! und! der! Analyse! des!
Stand"der"Wissenschaft! zu! Projektbeginn! wurden! Anforderungen! an! den!
REMsES"Leitfaden!formuliert,!die!in!fünf!grobe!Klassen!untergliedert!wer"
den! konnten.! Die! entsprechenden! –! nicht! vollständig! disjunkten! –Klassen!
von!Anforderungen!an!den!REMsES"Leitfaden!waren!(vgl.![REMsES!2006]):!
! Anforderungen!mit!Bezug!auf!die!Verbesserung!der!Qualität!
! Anforderungen!mit!Bezug!auf!die!Prozessunterstützung!!
! Anforderungen!mit!Bezug!auf!notwendige!Artefakte!
! Anforderung!mit!Bezug!auf!die!Vereinheitlichung!von!Begriffen!
! Anforderung!mit!Bezug!auf!ein!Leitfadensystem!
6!
!
3 AP!2:"Erarbeitung"der"Grobstruktur"des"
Produktmodells"
Eduard!Metzker!
Daimler!AG!
Eva!Geisberger!
Thorsten!Weyer!
Als! Grundlage! für! die! weiteren! Arbeiten! im! REMsES"Projekt! wurde! ein!
grobes! Vorgehensmodell! für! das! Requirements"Engineering! und! "
Management! (REM)! sowie! ein! zugehöriges! Umfeldmodell! erarbeitet.! Das!
Vorgehensmodell!des!REMsES"Leitfadens!besteht!aus!zwei!Detaillierungs"
stufen.!Die!erste!Stufe!beschreibt!ein!Top"Level"Vorgehensmodell,!welches!
den! Requirements"Engineering! Prozess! in! eine! Menge! von! Prozessberei"
chen!strukturiert.!In!der!zweiten!Detaillierungsstufe!werden!die!einzelnen!
Prozessbereiche! in! Prozessschritte! ausdetailliert! (vgl.! Abbildung! 1).! Das!
Umfeldmodell!beschreibt!für!das!REM!relevante!Umfeldprozesse!und!defi"
niert!die!Schnittstellen!zum!REMsES!Kernprozess.!!
!
Abbildung"1:"Schematische"Darstellung"der"Kern!"und"Umfeldprozesse"
7!
Im! Folgenden! wird! eine! kurze! Beschreibung! des! REMsES"Kernprozesses!
sowie! der! Umfeldprozesse! gegeben.! Details! können! dem! REMsES"
Leitfaden!beziehungsweise!den!Deliverables!D"2.1!und!D"5.2.1!entnommen!
werden.!
! Gewinnung!und!Spezifikation:!Die!Gewinnung!beschäftigt!sich!mit!der!
Erhebung! von! Anforderungen,! bspw.! durch! die! Befragung! von!
Nutzern!oder!durch!Analyse!von!Altsystemen.!Bei!der!Spezifikation!
werden!die!identifizierten!und!mit!dem!Management!abgestimmten!
Features!des!Produkts!ausgearbeitet!und!darauf!basierend!Anforde"
rungen!für!logische!Teilsysteme!abgeleitet.!
! Abstimmung! Spezifikation:! Zwischen! Auftraggeber! und! Auftragneh"
mer!werden!Anforderungen!über!das!Lastenheft!bzw.!Pflichtenheft!
ausgetauscht.! Über! die! Prüfung! dieser! Dokumente! werden! Proble"
me!identifiziert,!die!im!Abstimmungsprozess!gelöst!werden.!
! Änderungsmanagement:! Das! Änderungsmanagement! stellt! sicher!
dass!Änderungen!an!Artefakten!nachprüfbar!durchgeführt!werden.!
Dazu! werden! Impact! Analysen! durchgeführt! und! die! Änderungs"
gründe!festgehalten.!
! Qualitätsmanagement:! Mittels! Qualitätsmanagement! wird! sicherge"
stellt,! dass! die! ! Spezifikationen! den! geforderten! Qualitätsansprü"
chen! genügen.! Dazu! wird! auch! die! Qualität! des! Spezifikationspro"
zesses!selbst!sichergestellt.!
Der! zweite! wesentliche! Bestandteil! des! Arbeitspakets! „Erarbeitung! der!
Grobstruktur!des!Produktmodells“!ist!die!Definition!eines!Artefaktmodells,!
welches!durch!seine!Abbildung!auf!Abstraktionsebenen!die!Komplexität!in!
der!Anforderungsanalyse!und!auf!der!Modellierungsebene!reduziert!(siehe!
auch! Deliverable! D"2.2).! Die! Ebenen! Gesamtsystem,! Funktionsgruppen!
und!Hardware/Software!erlauben!dabei!eine!schrittweise!Verfeinerung!der!
Anforderungen.! Neben! den! eigentlichen! Anforderungen! an! das! geplante!
System! müssen! im! Requirements"Engineering! auch! Kontext"! und!
Entwurfsartefakte! berücksichtigt! werden.! Durch! die! Strukturierung! der!
Artefakte! nach! Kontext,! Anforderungen! und! Entwurf! entsteht! eine! 3x3"
Matrix,!die!das!Grundkonzept!von!REMsES!darstellt!(vgl.!Abbildung!2).!
8!
Context Requirements Design
Context Requirements Design

System layer
(System layer) (System layer) (System layer)
Function groups layer Context Requirements Design

(FG) (FG layer) (FG layer) (FG layer)
Hardware/Software Context Requirements Design

layer (HW/SW) (HW/SW layer) (HW/SW layer) (HW/SW layer)
!
Abbildung"2:"Die"neun"Artefaktklassen"des"REMsES!Artefaktmodells"
Kontextartefakte!beschreiben!den!Teil!der!realen!Welt,!der!die!Anforderun"
gen! an! das! System! und! damit! auch! das! System! selbst! beeinflusst.! Hierzu!
zählen! beispielsweise! Gesetze! oder! Normen.! Der! Systemkontext! ist! somit!
auch!Ursprung!von!Zielen!und!Vorgaben.!
Die!zweite!Kategorie!von!Artefakten!beinhaltet!die!Anforderungsartefakte,!
d.h.! die! dokumentierten! funktionalen! und! Qualitätsanforderungen! an! das!
geplante! System.! Anforderungsartefakte! beinhalten! darüber! hinaus! Ent"
wurfsvorgaben!oder!Constraints,!welche!beim!Entwurf!der!Systemarchitek"
tur!berücksichtigt!werden!müssen.!
Entwurfsartefakte! dokumentieren! Informationen! über! die! Architektur! des!

zu! entwickelnden! Systems,! d.h.! sie! spezifizieren! logische! oder! technische!
Strukturen,! z.! B.! in! Form! von! Komponenten! und! deren! Nutzungsbezie"
hungen.!
Auf!Basis!der!in!AP2!definierten!Grobstruktur!wurde!im!AP3!das!detaillier"
te! Artefaktmodell! mit! dem! zugehörigen! Leitfaden! entwickelt,! wie! im! fol"
genden!Kapitel!vorgestellt.!!
9!
!
4 AP!3:"Ausarbeitung"des"Leitfadens"auf"den"drei"
Abstraktionsstufen"
Johannes!Grünbauer!
Klaus!Lochmann!
Wassiou!Sitou!
Nadine!Bramsiepe!
Günter!Halmans!
Ernst!Sikora!
Thorsten!Weyer!
Die! Arbeiten! im! Arbeitspaket! 3! basieren! auf! den! in! Arbeitspaket! 2! entwi"
ckelten! Strukturierungsprinzipien! nach! den! Abstraktionsebenen! Gesamt"
system,! Funktionsgruppe! und! Hardware/Software! und! in! jeder! Abstrakti"
onsebene!nach!Kontext,!Anforderung!und!Entwurf.!
Für!die!Ausarbeitung!des!Leitfadens!auf!den!drei!Abstraktionsebenen!wird!
das! in! Arbeitspaket! 2! entwickelte,! grobe! Artefaktmodell! weiter! detailliert.!
Darüber! hinaus! werden! Modellierungstechniken! beschrieben,! die! zur! Do"
kumentation!der!detaillierten!Artefakte!verwendet!werden!können.!Teil!der!
Untersuchung! in! Bezug! auf! die! einsetzbaren! Modellierungstechniken! ist!
zudem!eine!Analyse!des!Stands!der!Wissenschaft,!um!vorhandene!Model"
lierungstechniken! auf! ihre! Einsetzbarkeit! für! die! Dokumentation! der! defi"
nierten! Artefakte! zu! prüfen.! Ein! weiterer! Bestandteil! ist! die! Beschreibung!
von! einzelnen! Methodenfragmenten! zur! Bearbeitung! der! im! Artefaktmo"
dell!definierten!Artefakte.!Diese!Methodenfragmente!dienen!als!Grundlage!
für!den!Leitfaden!in!Form!einer!Beschreibung!von!Praktiken.!
Die!Arbeiten!wurden!thematisch!aufgeteilt,!um!die!Komplexität!der!einzel"
nen! für! einen! Leitfaden! relevanten! Bereiche! beherrschbar! zu! machen.! Es!
11!
wurden! Aspekte! aus! den! unterschiedlichen! Bereichen! Kontext,! Anforde"
rung! und! Entwurf! adressiert! und! detailliert! bearbeitet,! die! im! Folgenden!
kurz!vorgestellt!werden.!
4.1 Thema"I:"Durchgängige"Verfeinerung"von"Zielen"
Ziel! der! Bearbeitung! dieses! Themas! ist! die! Entwicklung! einer! Systematik!
sowie! einer! Methodik! zur! Strukturierung,! Klassifizierung! und! Verfeine"
rung! von! Zielen,! wie! sie! in! den! frühen! Phasen! des! Requirements"
Engineering!betrachtet!werden.!Ergebnis!der!Systematik!ist!die!Unterschei"
dung!von!Zielen!in!Qualitätsziele!und!operationelle!Ziele.!Darüber!hinaus!
werden!noch!Rahmenbedingungen!betrachtet,!welche!primär!dazu!dienen,!
die!Ziele!einzuschränken.!!!
Zur! Modellierung! von! Zielen! wird! ein! Metamodell! aufgeführt,! womit! die!
Strukturierung,! die! Klassifizierung! und! die! Verfeinerung! von! Zielen! mo"
delliert! werden! kann.! Die! Beschreibung! von! Methodenfragmente! bildet!
schließlich! die! Grundlage! für! eine! Anleitung! zur! Zielstrukturierung,! "
klassifizierung!und!"verfeinerung.!!
4.2 Thema"II:"Kontextbetrachtung"und"
Kontextverfeinerung""
Um! die! Komplexität! des! Kontexts! eines! softwareintensiven! eingebetteten!

Systems!beherrschbar!zu!machen,!werden!in!dem!Thema!drei!Kontextsich"
ten!eingeführt,!die!jeweils!durch!ein!Informationsmodell!konkretisiert!wer"
den.!Jedes!dieser!Informationsmodelle!definiert!die!in!dieser!Sicht!relevan"
ten! Informationen!sowie!die!Beziehungen!zwischen!diesen!Informationen.!
Die! Informationsmodelle! sind! Basis! für! die! Konstruktion! von! Kontextdia"
grammen,!welche!Informationen!über!den!Kontext!eines!zu!entwickelnden!
Systems!in!jeweils!einer!Kontextsicht!modellieren.!!!
12!
Zu! den! Kontextdiagrammen! in! den! drei! Kontextsichten! werden! weitere!
Artefakttypen! zur! Konkretisierung! der! Kontextinformationen! in! den! drei!
Kontextsichten! vorgeschlagen.! Für! jeden! Typ! von! Kontextinformationen!
werden! konkrete! Dokumentations"! bzw.! Modellierungstechniken! vorge"
stellt,! die! sich! zur! Dokumentation! von! Kontextinformationen! des! jeweili"
gen! Artefakttyps! eigenen.! Eine! methodische! Anleitung! und! damit! eine!
Grundlage! für! den! Leitfaden! bilden! die! Beschreibung! von! Methodenfrag"
mente,! die! zur! Bearbeitung! der! unterschiedlichen! Kontextinformationen!
notwendig! sind.! Die! Methodenfragmente! basieren! auf! dem! detaillierten!
Artefaktmodell!(im!Bereich!Kontext).!
4.3 Thema"III:"Entwicklung"und"Verfeinerung"von"
Zielen"und"Szenarien"
In! diesem! Themengebiet! werden! grundlegende! Artefakte! und! Methoden"

fragmente! zur! Unterstützung! eines! ziel"! und! szenariobasierten! Require"
ments"Engineering!eingebetteter!softwareintensiver!Systeme!erarbeitet.!Die!
beschriebenen! Artefakte! sind! in! der! Artefaktklasse! „Anforderungen“! auf!
der! Gesamtsystemebene! der! in! Abbildung! 3! (s.! Seite! 17)! dargestellten!
Strukturierung!anzusiedeln.!Im!Rahmen!der!Bearbeitung!des!Themas!wer"
den!drei!Artefaktklassen!definiert.!Systemziele!beschreiben!die!gewünsch"
ten! funktionalen! und! qualitativen! Eigenschaften! des! geplanten! Systems.!
System"Anwendungsfälle!zeigen!typische!Nutzungsmustern!des!geplanten!
(Gesamt")Systems! durch! dessen! Nutzer,! d.h.! Personen! und! nutzende! Sys"
teme!auf.!Modellbasierte!Systemszenarien!präzisieren!schließlich!die!Spezi"
fikation! von! Interaktionen! zwischen! dem! System! und! Entitäten! der! Sys"
temumgebung!wie!z.B.!Nutzern,!externen!Systemen!oder!Mess"!und!Stell"
größen.! Die! Informationsbestandteile! der! einzelnen! Artefakte! werden! ba"
sierend!auf!Konzepten!der!UML"Klassenmodellierung!im!Detail!definiert.!!
Weiterhin! werden! Methodenfragmente! skizziert,! die! die! Erarbeitung! der!

Artefakte!methodisch!anleiten.!Ein!Beispiel!für!eine!solche!Aktivität!bildet!
die! Ableitung! von! Systemzielen.! Diese! Aktivität! dient! der! Ableitung! von!
13!
Systemzielen! aus! bereits! bekannten! Geschäftszielen! und! Stakeholder"
Zielen.!!
4.4 Thema"IV:"Ableitung"lösungsorientierter"
Anforderungen"
Im!Rahmen!der!Forschungsfragestellung!„Ableitung!von!lösungsorientier"
ten!Anforderungen!aus!Systemzielen,!Systemszenarien,!Kontext!und!Archi"
tektur! auf! der! Gesamtsystemebene“! werden! drei! Arten! von! lösungsorien"
tierten! Anforderungen! unterschieden:! daten",! funktions"! und! verhaltens"
orientierte!Anforderungsartefakte.!In!den!Arbeiten!zu!diesem!Thema!wird!
das!Artefaktmodell!um!diese!drei!Arten!von!Artefakten!erweitert.!Die!Do"
kumentation!von!lösungsorientierten!Anforderungsartefakten!wird!anhand!
des! Systems! „dynamische! Scheibentönung“! beispielhaft! gezeigt! und! be"
schrieben.! Zu!dem!Thema!werden!Ansätze!und!Methodenfragmente!erar"
beitet,!um!aus!Systemzielen,!Systemszenarien,!Kontext"!und!Entwurfsarte"
fakten!lösungsorientierte!Anforderungsartefakte!abzuleiten.!!!
4.5 Thema"V:"Abhängigkeitssicht"auf"der"
Gesamtsystemebene"
Dieses!Thema!adressiert!eine!Methode!zur!Formalisierung!und!Verifikation!
von! Anforderungen,! wie! sie! in! einem! typischen! Lastenheft! beschrieben!
werden.! Kern! des! in! diesem! Thema! erarbeiteten! Ansatzes! ist! die! Bildung!
einer!neuen!Sicht!auf!das!System.!In!dieser!Sicht!werden!die!Beziehungen!
zwischen!den!Systemfunktionen!und!Zuständen,!wie!sie!der!Nutzer!wahr"
nimmt,!modelliert.!Ziel!ist!es,!mögliche!Abhängigkeiten!zwischen!den!ein"
zelnen! Zuständen! zu! verdeutlichen! und! auf! Basis! eines! formalen! Kalküls!
über!Nutzungsbeziehungen!zu!überprüfen.!Durch!diese!neue!Sicht!auf!ein!
System!ist!es!möglich,!unerwünschte!Feature"Interaction!bereits!im!Requi"
rements"Engineering!erkennen!und!auflösen!zu!können.!!!
14!
Ein! weiteres! Ergebnis! in! diesem! Themengebiet! liegt! in! der! Beschreibung!
von!Methodenfragmente!zur!Anwendung!der!entwickelten!Modellierungs"
technik.! Die! Identifikation! der! Nutzungsfunktionen! und! der! Zustände! ist!
ein!Beispiel!einer!solchen!Aktivität.!Zustände!können!sowohl!Zustände!des!
Systems!selbst!sein!oder!Zustände!der!Umgebung,!die!auf!das!System!Ein"
fluss!nehmen!können.!!
4.6 Thema"VI:"Transition"von"Gesamtsystem"auf"
Subsystem""
Im! Rahmen! dieses! Themengebiets! werden! zum! einen! die! Kriterien! unter"
sucht,!die!die!Dekomposition!oder!Partitionierung!des!Gesamtsystems!be"
einflussen,!und!zum!anderen!eine!adäquate!Modellierung!und!Dokumenta"
tion! der! Subsystemgrenzen! untersucht,! so! dass! eine! Subsystemspezifikati"
on! alle! nötige! Information! zur! Weitergabe,! externen! Entwicklung! oder!
Wiederverwendung!enthält.!Die!Dekompositionskriterien!werden!in!Form!
eines! Referenzkataloges! angegeben,! der! als! Checkliste! und! als! Basis! für!
eine! Best"Practise"Sammlung! dienen! soll.! Die! Dokumentation! der! Subsys"
temgrenzen!erfolgt!anhand!eines!Templates.!
4.7 Thema"VII:"Artefaktqualitätsgetriebene"
Vorgehensplanung"
Dieses! Thema! beschäftigt! sich! mit! der! Artefaktqualität! für! die! in! REMsES!
definierten! Artefaktmodelle.! Dazu! werden! verschiedene! Ansätze! zur!
Artefaktqualität! diskutiert:! Der! transzendente,! der! produktorientierte,! der!
benutzerorientierte,! der! fertigungsorientierte! und! der! wertorientierte! An"
satz.! Darauf! aufbauend! wird! ein! übergreifender! Qualitätsbegriff! definiert!
und! ein! Vorgehen! zur! Ableitung! von! überprüfbaren! Qualitätsmerkmalen!
aus!allgemeinen!Qualitätsaspekten!skizziert.!Das!entwickelte!Konzept!ord"
net!den!Artefakten!Reifegraden!zu!und!definiert!für!jede!Methode!des!Me"
thodenbaukastens!die!geforderten!Reifegrade!der!Eingangsartefakte.!
15!
4.8 Thema"VIII:"Modellierung"von"
Qualitätsanforderungen"
In!diesem!Themengebiet!wird!gezeigt,!wie!Qualitätsanforderungen!model"
liert!werden!können.!Eine!Analyse!eines!gegebenen!Lastenhefts!hinsichtlich!
spezifizierter! Qualitätsanforderungen! dient! als! Basis! für! eine! beispielhafte!
REMsES"Modellierung! in! Form! von! Zielen! und! Use"Cases! ohne! QA"
Betrachtung.!Diese!Art!der!Modellierung!wird!erweitert!um!eine!Methode!
des! IESE! zur! Use"Case! basierten! Modellierung! von! Qualitätsanforderun"
gen.! Sie! bildet! einen! Ergänzungsvorschlag! für! Use"Case"Modellierung! in!
REMsES! und! es! wird! aufgezeigt,! wie! die! IESE"Methode! in! REMsES! inte"
griert!werden!könnte.!
Die! Bearbeitung! der! einzelnen! Themen! diente! als! Grundlage! für! die! Ent"
wicklung!des!Leitfadens.!
4.9 Der"REMsES"Leitfaden"
Das!konsolidierte!Artefaktmodell!bildet!das!zentrale!Kernelement!des!Leit"
fadens.!Das!Artefaktmodell!ist!in!Abbildung!3!zu!sehen.!Die!dargestellten!
Beziehungen!kennzeichnen!inhaltliche!Abhängigkeiten.!Im!Leitfaden!wird!
beschrieben,! wie! die! Artefakte! nacheinander! erstellt! werden! und! welche!
Artefakte!dabei!jeweils!die!Grundlage!für!den!nächsten!Schritt!bilden.!
Die! Struktur! des! Leitfadens! mit! der! Übersichtsnavigation! bestehend! aus!

den!9!Artefaktklassen!ist!in!Abbildung!2!(s.!Seite!9)!zu!sehen.!Als!Einstieg!
werden! die! Strukturierungskonzepte! des! Artefaktmodells! eingeführt,! so"
wie!die!sechs!Modellierungstechniken!Kontextmodellierung,!Zielmodellie"
rung,!Szenariomodellierung,!Funktionsmodellierung,!Architekturmodellie"
rung!und!Verhaltensmodellierung!vorgestellt.!
16!
!
Abbildung"3:"Beispiel"einer"Abbildungsbeschriftung"
Danach!kann!sich!der!Anwender!anhand!der!Struktur!des!Artefaktmodells!
oder! anhand! des! REMsES! Entwicklungsprozesses! Stück! für! Stück! bei! der!
Erstellung! einer! Spezifikation! aus! den! Bausteinen! der! einzelnen! Artefakte!
anleiten!lassen.!Dabei!gibt!es!zu!jedem!Artefakt!eine!strukturierte!Beschrei"
bung!von!Inhalt,!Zweck,!möglichen!Notationen,!Voraussetzungen,!weiterer!
Verwendung! und! minimalen! Anforderungen! an! das! Artefakt.! Dies! wird!
ergänzt! um! ein! Beispiel! aus! dem! illustrierenden! Fahrerassistenzsystem!
Radiofrequenz"Warnsystem!sowie!gegebenenfalls!direkt!im!Leitfaden!hin"
terlegte!Templates.!Der!Leitfaden!ist!unter!www.remses.org!frei!erhältlich.!
17!
!
5 AP!4:"Evaluation"des"REMsES!Leitfadens"
Franz!Grzeschniok!
Mark!Müller!
Igor!Menzel!
Robert!Bosch!GmbH!
Jörg!Leuser!
Daimler!AG!
Um! den! umfangreichen! Inhalten! des! REMsES! Leitfadens! gerecht! zu! wer"
den!wurde!eine!mehrstufige!Validierungsstrategie!gewählt.!Zunächst!wur"
de! der! REMsES"Leitfaden! von! verschiedenen! Domänen"! und! Prozess"
Experten! mehrfach! gelesen.! Dann!wurde! er! in! mehreren! empirischen! Stu"
dien! evaluiert.! Dieses! Kapitel! stellt! die! wesentlichen! Ergebnisse! der! Vali"
dierung!des!REMsES"Leitfadens!dar.!!
5.1 Validierungsprozess"
Der!Validierungsprozess!basiert!auf!systematischen!Reviews!durch!Requi"
rements"Engineering"Experten! und! Entwicklern! der! Industriepartner! und!
auf! Anwendung! ausgewählter! Teile! des! Leitfadens! in! Experimenten! und!
Fallstudien.!!
!
Abbildung"4:"Validierungsstrategie"
19!
Wie!in!Abbildung!4!ersichtlich!besteht!die!Validierungsstrategie!aus!sechs!
Schritten.! Zunächst! wurde! die! Validierungsstrategie! definiert! (E.1).! Danach!
wurden! Nutzungsszenarien! für! ausgewählte! Teile! des! Leitfadens! definiert!
(E.2).!Um!die!Brauchbarkeit!der!REMsES"Methode!zeigen!zu!können!stell"
ten! die! Industriepartner! Spezifikationen! für! verschiedene! Automotive"
Systeme!bereit:!den!Radio"Frequenz"Warner!(RFW),!ein!erweitertes!Kombi"
Instrument!und!eine!Türschließanlage.!!
Im! Schritt! systematische! Reviews! (E.3)! ist! eine! Prozess"Gap! Analyse! enthal"
ten:! Entwickler! und! Prozesseigner! verschiedener! Geschäftsbereiche! haben!
in! Workshops! den! REMsES"Leitfaden! eine! Review! unterzogen! und! mit!
ihren!definierten!und!gelebten!Prozessen!verglichen!und!dabei!geprüft,!wie!
die! REMsES"Methoden! in! die! bestehenden! Prozesse! eingebracht! werden!
könnten,! und! ob! Defizite! der! miteinander! verglichenen! Prozesses! einer!
Integration! der! REMsES"Methoden! entgegenstehen.! Die! Industriepartner!
begleiteten! die!Arbeit!der!REMsES"Methodenautoren!mit!kontinuierlichen!
Reviews! (alle! 3! bis! 6! Monate)! und! machten! Verbesserungsvorschläge! auf!
deren!Basis!der!Leitfaden!konsolidiert!wurde!(E.6).!!
In!zwei!Experimenten!untersuchten!die!Industriepartner!Anwendungen!aus"
gewählter!Methoden!aus!dem!Leitfaden!(E.4).!!
Am! ersten! Experiment! haben! 12! Studenten! der! Universität! Ulm! teilge"
nommen![Leuser!et!al.!2009].!Als!Material!bearbeiteten!die!Teilnehmer!eine!
Türschließanlage!„MachZu“!und!eine!Lichtsteuerung!„Lumiere“.!Primäres!
Ziel! war,! die! Eignung! des! Leitfadens! für! die! Automotive"Domäne! zu! zei"
gen.! Dabei! wurde! REMsES! mit! einem! State"of"the"Practice! (SotP)! Prozess!
verglichen.! Die! Teilnehmer! bildeten! sechs! Teams.! Vier! davon! benutzten!
den!REMsES"Leitfaden,!die!anderen!beiden!Teams!arbeiteten!gemäß!SotP.!!
Am!zweiten!Experiment!haben!11!Studenten!der!Universität!Kaiserslautern!
teilgenommen! [Menzel! et! al.! 2009].! Sie! erarbeiteten! in! zwei! Gruppen! eine!
Spezifikation! einer! Türschließanlage.! Ziel! des! Experiments! war,! die! Me"
thode!Ziel"!und!Szenario"Modellierung!(Use"Cases)!mit!dem!traditionellen!
funktionalen!Ansatz!zu!vergleichen.!!
20!
Basierend!auf!den!Erfahrungen!mit!den!Experimenten!wurden!zwei!länger!
laufende! Fallstudien! mit! Studenten! an! der! Hochschule! Esslingen! durchge"
führt.! Ziel! der! Fallstudien! war! zu! untersuchen,! wie! Entwicklungsprojekte!
von! systematischer! Ziel"! und! Szenario"Modellierung! profitieren! können!
(E.5).! Die! Studien! betrachten! ein! ganzes! Entwicklungsprojekt! mit! einem!
vollständigen!Produktlebenszyklus.!Die!Teilnehmer!hatten!die!Arbeitsauf"
gabe,! eine! Kundenspezifikation! einer! Türschließanlage! zu! verstehen,! die!
Systemanforderungen! zu! spezifizieren,! das! System! in! der! Programmier"
sprache!C!zu!implementieren,!es!auf!dem!Steuergerät!in!Betrieb!zu!nehmen!
und! schließlich! den! Systemtest! durchzuführen.! In! der! ersten! Studie! bilde"
ten! die! Studenten! 6! Teams! à! 5! bis! 6! Mitgliedern.! 3! Teams! nahmen! zu! Be"
ginn! des! Projekts! an! einem! Training! der! Ziel"! und! Szenario"Methode! zur!
Spezifikation!von!Systemanforderungen!teil.!Die!anderen!3!Teams!spezifi"
zierten!die!Systemanforderungen!mit!der!ihnen!geläufigen!Vorgehensweise!
(ad"hoc!Prozess).!Alle!Teams!berichteten!über!ihren!Aufwand!(Arbeitszei"
ten)! je! Prozessphase.! Eine! weitere! Kennzahl! ist! die! Zahl! der! bestandenen!
Systemtestfälle! bei! Projektabnahme.! Im! Verlauf! der! Studie! wurden! die!
Teilnehmer!über!ihre!Meinung!zu!den!jeweils!eingesetzten!Spezifikations"
methoden! befragt.! Die! zweite! Fallstudie! war! eine! Replikation! der! ersten.!
Dieses!Mal!nahmen!55!Studenten!teil!und!bildeten!10!Teams.!!
Die! Experimente! und! Fallstudien! lieferten! Rückmeldungen! zur! Konsolidie"

rung!des!Leitfadens!(E.6).!Darüber!hinaus!wurden!die!empirischen!Ergebnis"
se!hinsichtlich!der!Benutzbarkeit!des!REMsES"Leitfadens!analysiert.!!
5.2 Empirische"Ergebnisse"
Die!aggregierten!Ergebnisse!der!empirischen!Validierungen!weisen!darauf!
hin,! dass! mit! REMsES"Methoden! die! Qualität! von! Spezifikationen! verbes"
sert!werden!kann,!und!dies!ist!sogar!ohne!zusätzlichen!Aufwand!möglich.!!
Das! erste! Experiment! an! der! Universität! Ulm! [Leuser! et! al.! 2009]! brachte!
zwei!Hauptergebnisse:!!
Erstens! ist! der! Leitfaden! geeignet! für! die! gestellten! Arbeitsaufgaben! und!
ihren! Kontext.! Die! Teilnehmer! am! Experiment! haben! die! Verständlichkeit!
21!
der! Methoden"! und! Artefaktbeschreibungen! des! Leitfadens! in! Umfragen!
durchwegs!positiv!beurteilt!(siehe!Abbildung!5).!Auf!den!4"stufigen!Skalen!
zu!den!Fragen!„Wie!verständlich!war!…“!bewerteten!sie!die!einzelnen!Be"
schreibungen! überwiegend! mit! einem! Median! von! 3! („gut! verständlich“).!
Daraus!lässt!sich!ableiten,!dass!die!REMsES"Prozess"Schritte!gut!durch!die!
Erstellung!der!Artefakte!führen.!!
!
Abbildung"5:"Verständlichkeit"von"REMsES!Elementen"im"Median"
Das!zweite!Hauptergebnis!ist,!dass!REMsES!die!Qualität!der!Spezifikation!
signifikant! verbessert! hat.! Die! Qualität! der! Spezifikation! wurde! an! Hand!
einer! Checkliste! mit! Kategorien! wie! Korrektheit! und! Vollständigkeit! be"
wertet.!Abbildung!6!zeigt!für!jedes!der!sechs!Teams!die!mit!ihrer!Spezifika"
tion! erreichte! Qualitäts"Kennzahl! (Qualitäts"Score).! Ein! Mann"Whitney"U"
Test!bestätigt!auf!10%!Niveau!eine!höhere!Qualität!für!Spezifikationen!ge"
mäß!REMsES!im!Vergleich!zu!den!Spezifikationen!gemäß!SotP.!!
25
20
Qualitäts-Score
15
10
0
Gruppe 1 Gruppe 2 Gruppe 3 Gruppe 4 Gruppe 5 Gruppe 6
Machzu Machzu Lumiere Lumiere Machzu Lumiere
REMsES REMsES REMsES REMsES SotP SotP !
Abbildung"6:"Qualitäts!Kennzahl"der"einzelnen"Spezifikationen"
22!
Das! zweite! Experiment! [Menzel! et! al.! 2009]! zeigte,! dass! ein! Use"Case! ba"
sierter! Ansatz! –! wie! Ziel"/Szenario"Modellierung! –! mehr! (der! im! realen!
System!tatsächlich!stattfindenden)!Interaktionen!findet!(Abbildung!7):!!
!
Abbildung"7:"Im"Experiment"gefundene"Interaktionen"
Die!Grafik!zeigt!Boxplots!der!Anzahl!der!spezifizierten!Interaktionen!zwi"
schen! Komponenten.! (Jede! spezifizierte! Funktion! bzw.! jeder! spezifizierte!
Use"Case! liefert! einen! Datenpunkt.)! Mit! dem! Use"Case"Ansatz! haben! die!
Teams! im! Mittel! 3! Interaktionen! mehr! gefunden! als! die! Teams! mit! dem!
funktionalen!Ansatz.!!
23!
Total effort (Lifecycle)
250 Ad-hoc:
Sample Size = 6
Median = 153.25
200 Mean = 159.15
Total effort (h)
Goal-Scenario:
150 Sample Size = 8
Median = 139
Mean = 142.64
100
50
0
Ad-hoc G/S
Method
!
Abbildung"8:"Gesamtaufwände"der"Teams"
In!den!Fallstudien!wurde!die!Auswirkung!auf!ein!ganzes!Projekt!bewertet.!
In!den!an!der!Hochschule!Esslingen!durchgeführten!Fallstudien!wurde!der!
Aufwand!gemessen!mit!dem!Ergebnis,!dass!der!Einsatz!der!Ziel"!und!Sze"
nario"Methode!den!gesamten!Aufwand!im!Projekt!nicht!signifikant!erhöht!
hat.!Auffällig!war!aber,!dass!die!Gesamtaufwände!der!Ad"hoc"Teams!stär"
ker! streuen! als! die! Gesamtaufwände! der! Ziel"! und! Szenario"Teams!
(Abbildung!8).!!
Esslingen I + II (B1 and C1 excluded)

140 Method
Ad-hoc
120 G/S
Effort per Group (h)
100
Ad-hoc:
80 Sample Size = 6
Medians = 14.25 | 25.5 | 72.5 | 26
60 Means = 15.1 | 28.4 | 83.9 | 31.7
40 Goal-Scenario:
20 Sample Size = 8
Medians = 19 | 27.5 | 71 | 20.6
0 Means = 23.1 | 25.5 | 71.4 | 22.6
Ad-hoc G/S Ad-hoc G/S Ad-hoc G/S Ad-hoc G/S
Requirements Design Coding Testing
!
Abbildung"9:"Aufwände"der"Teams"pro"Phase"
24!
Der!Effekt!kann!auf!die!Varianz!der!Aufwände!in!der!Codierphase!zurück"
geführt! werden! (Abbildung! 9).! Zwar! sind! die! Unterschiede! in! den! Auf"
wandszahlen! nicht! statistisch! signifikant,! doch! wir! nehmen! an,! dass! die!
Ziel"!und!Szenario"Methode!kosteneffektiv!angewandt!werden!kann.!!
Die!Produktqualität!an!Hand!der!Kennzahl!bestandene!Systemtestfälle!wurde!
nur! in! der! zweiten! Esslinger! Fallstudie! überprüft.! Die! zehn! an! der! Studie!
beteiligten!Teams!haben!4!Systeme!à!2"3!Steuergeräte!entwickelt.!Die!Sys"
teme!haben!den!Großteil!der!Testfälle!bestanden.!Die!4!Datenpunkte!liefern!
aber!keinen!Anhaltspunkt!für!einen!Effekt!der!Ziel"!und!Szenario"Methode!
auf!die!im!Systemtest!feststellbare!Qualität.!!
5.3 Threats"to"validity"
Studenten!sind!im!Allgemeinenen!keine!repräsentativen!Vertreter!für!pro"
fessionelle!Entwickler.!Daher!glauben!wir!nicht,!dass!absolute!Zahlenwerte!
aus! den! Analysen! verallgemeinerbar! sind.! Die! Zahl! der! Fallstudien! und!
Experimente!und!die!Zahl!der!erhobenen!Datenpunkte!sind!zu!gering!um!
statistisch!signifikante!Folgerungen! über!Entwicklungsaufwände!und!Pro"
duktqualität! abzuleiten.! Doch! es! gibt! Indizien! für! die! Annahme,! dass! der!
richtige! Einsatz! der! REMsES"Methoden! positive! Auswirkungen! hat.! Im!
Vergleich!zu!Automotive!Systemen!aus!der!Industrie!sind!die!in!den!Studi"
en! behandelten! Systeme! und! Arbeitsaufgaben! klein! bis! mittelgroß.! Daher!
glauben!wir,!dass!unsere!empirischen!Studien!Trends!zeigen,!und!weitere!
empirische!Evidenz!erforderlich!ist!um!die!Ergebnisse!auf!die!Entwicklung!
komplexer!Systeme!realistischer!Größe!zu!verallgemeinern.!!
25!
!
6 AP!6:"Erstellung"von"Illustratoren"
Matthias!Kirchmayr!
Eduard!Metzker!
Jörg!Leuser!
Daimler!AG!
Im!Rahmen!des!Arbeitspakets!„Erstellung!von!Illustratoren“!wurden!zwei!
realitätsnahe,!jedoch!fiktive!Systeme!(„Dynamische!Scheibentönung!(DST)“!
und! „Radio"Frequenz"Warnsystem! (RFW)“)! nach! dem! Stand! der! Praxis!
entwickelt! und! auf! Basis! der! VDA"Struktur! Komponentenlastenheft1! do"
kumentiert.! Anhand! dieser! beiden! Spezifikationen! wurden! Probleme! aus!
den! unterschiedlichen! Bereichen! der! betrachteten! Domäne! „bilderbuchar"
tig“! beschrieben.! Die! daraus! gewonnenen! Erkenntnisse! wurden! im! REM"
sES"Leitfaden! umgesetzt! und! Lösungen! bereitgestellt.! Im! Folgenden! wer"
den!die!beiden!Illustratoren!kurz!beschrieben.!Für!das!System!RFW!wurde!
zusätzlich! eine! CANoe! Simulation! erstellt,! wodurch! sichergestellt! wurde,!
dass!die!Spezifikation!alle!relevanten!Informationen!für!eine!Implementie"
rung!enthält.!
6.1 Dynamische"Scheibentönung"(DST)"
Primäres! Ziel! des! Systems! ist! die! Reduktion! des! Unfallrisikos! aufgrund!
ungünstiger! Lichtverhältnisse:! das! System! der! dynamischen! Scheibentö"
nung!verbessert!die!Sicht!des!Fahrers,!indem!während!der!Fahrt!durch!die!
Tönung! der! Scheiben! einer! Blendung! durch! die! Sonne! entgegengewirkt!
wird.!Gleichzeitig!dient!das!System!der!optimalen!Sicht!im!Falle!einer!Ver"
besserung!der!Lichtverhältnisse!(geringere!Blendung,!geringere!Lichtinten"
sität),!indem!die!Scheiben!des!Fahrzeugs!entfärbt!werden!und!sich!dadurch!
das!Sichtfenster!für!den!Fahrer!vergrößert!(dies!trifft!besonders!für!die!Sei"
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
1 ! VDA"Struktur! Komponentenlastenheft,! Modul! II:! Komponentenlastenheft! Me"
chanik"!und!E/E"Komponenten,!Version!1.3!
27!
tenscheiben!hinten!und!die!Heckscheibe!zu).!Der!Fahrer!hat!somit!dank!der!
dynamischen!Scheibentönung!während!der!Fahrt!bei!allen!Lichtverhältnis"
sen! eine! optimale! Sicht.! Da! die! Tönung! und! Entfärbung! der! Scheiben! au"
tomatisch!abläuft,!kann!sich!der!Fahrer!zu!jedem!Zeitpunkt!zu!100%!auf!die!
Verkehrssituation!konzentrieren.!Dadurch!sinkt!das!Unfallrisiko.!
Ein!weiteres!Feature!und!somit!sekundäres!Ziel!stellt!die!Wärmereduktion!
innerhalb!des!geparkten!Fahrzeugs!dar:!durch!die!Tönung!der!Scheiben!des!
geparkten!Fahrzeugs!wird!die!Wärmeentwicklung!im!Fahrzeuginnenraum!
reduziert.! Gleichzeitig! schützt! die! Tönung! der! Scheiben! den! Fahrzeugin"
nenraum! vor! neugierigen! Blicken! und! fungiert! somit! zusätzlich! zur! Wär"
mereduktion!auch!als!Diebstahlschutz.!
6.2 Radio!Frequenz!Warnsystem"(RFW)"
Unter! Verwendung! der! RFID"Technologie! soll! das! Radio"Frequenz"
Warnsystem! mit! RFID"Sender! ausgestattete! Hinweise! (z.B.! Verkehrsschil"
der)!erkennen.!Wird!ein!Hinweis!erkannt!zeigt!das!System!den!Hinweis!im!
Display!an!und/oder!spielt!bei!hoher!Dringlichkeit!einen!Warnton!ab.!Wei"
terhin!fungiert!das!System!wie!ein!zweites!Gedächtnis.!Warnhinweise!wer"
den! länger! anzeigt! als! entsprechende! Warnschilder! im! Blickfeld! des! Be"
trachters!sind.!Sollte!z.B.!der!Hinweis!auf!eine!Geschwindigkeitsbeschrän"
kung!versäumt!werden,!so!kann!die!Beschränkung!noch!für!einige!Sekun"
den!bzw.!Kilometer!im!Display!angezeigt!werden.!Falls!man!schneller!fährt!
als! erlaubt! und! nach! einigen! Sekunden! die! Geschwindigkeit! nicht! verrin"
gert!hat,!ertönt!ein!akustisches!Signal.!Ist!ein!Geschwindigkeitsregler!instal"
liert!und!aktiviert!so!kann!dieser!auch!die!Fahrzeuggeschwindigkeit!an!die!
geltende!Beschränkung!anpassen.!Das!System!soll!aber!auch!wie!ein!Filter!
wirken,!indem!nur!die!relevanten!Informationen!angezeigt!werden.!So!gel"
ten!beispielsweise!manche!Einschränkungen!nur!für!LKW!und!können!so"
mit!von!einem!PKW!ignoriert!werden.!
28!
!
6.3 Neuspezifikation"RFW"anhand"des"REMsES!
Leitfadens"
Um! ein! durchgängiges! Beispiel! für! die! Artefakte! des! REMsES"Leitfadens!
bereitstellen! zu! können,! wurde! die! Spezifikation! des! RFW! nach! den! Me"
thoden! des! REMsES"Leitfadens! überarbeitet.! Hierdurch! konnte! die! Be"
schreibung!der!Artefakte!veranschaulicht!und!dadurch!die!Anwendbarkeit!
des!Leitfadens!insgesamt!verbessert!werden!(vgl.!Abbildung!10).!Die!Not"
wendigkeit! eines! durchgängigen! Beispiels! wird! auch! durch! diverse! Vali"
dierungsschritte,! wie! beispielsweise! dem! Experiment! an! der! Universität!
Ulm! (vgl.! Zwischenberichte! 1.! und! 2.! Halbjahr! 2008)! deutlich.! Aufgrund!
der! Durchgängigkeit! des! Beispielsystems! können! zusätzlich! auch! die! Be"
ziehungen!der!Artefakte!zueinander!in!den!Beispielen!dargestellt!werden.!
!
Abbildung"10:"Auszug"aus"dem"Artefakt"„Datenmodell“"am"Beispiel"
Zudem!konnten!durch!die!Neuspezifikation!auch!Verbesserungspotentiale!
für! den! Leitfaden! aufgezeigt! werden.! Somit! stellt! die! Bereitstellung! von!
Illustratoren! auch! einen! Beitrag! zur! Validierung! des! Leitfadens! dar! (vgl.!
Deliverable!D"4.1).!
29!
!
7 AP!7:"Entwicklung"spezifischer"Erweiterungen"
des"Leitfadens"
Markus!Bechter!
Peter!Braun!
Jan!Philipps!
Validas!AG,!München!
Technischer!Universität!München!
Nadine!Bramsiepe!
Kim!Lauenroth!
Thorsten!Weyer!
Im!Arbeitspaket!7!werden!verschiedene!Aspekte!betrachtet,!die!sich!auf!die!
Anwendbarkeit!des!Leitfadens!beziehen.!So!wird!das!Themenfeld!Auftrag"
geber/Auftragnehmer"Beziehung! im! Hinblick! auf! eine! mögliche! Erweite"
rung! und! Anwendung! des! Leitfadens! erschlossen.! Darüber! hinaus! sind!
Erweiterungen!für!die!Produktlinienentwicklung!ein!Thema.!Für!den!Ein"
satz! des! Leitfadens! ist! zudem! eine! adäquate! Werkzeugunterstützung! not"
wendig.!Daher!beinhaltet!Arbeitspaket!7!auch!ein!Konzept!und!einen!Pro"
totyp!eines!möglichen!Werkzeugs.!
7.1 AP!7.1:"Verbesserung"der"
Auftraggeber/Auftragnehmer!Beziehungen"
Heutige! Eingebettete! Systeme! sind! in! den! meisten! Fällen! verteilter! Natur.!
Das!bedeutet!dass!die!Softwarefunktionen!nicht!nur!auf!einem!eingebette"
ten! System! integriert,! sondern! auf! mehrere! Hardwareplattformen! verteilt!
sind.! Diese! werden! dann! von! verschiedenen! Zulieferern! entwickelt.! Der!
Hauptauftraggeber!(z.B.!ein!Fahrzeughersteller)!steht!vor!der!Problematik,!
31!
die!Komponenten!verschiedener!Hersteller!zu!einem!funktionierenden!Ge"
samtsystem!integrieren!zu!müssen.!!
Die!Kommunikation!zwischen!dem!Auftraggeber!und!dem!Auftragnehmer!
erfolgt!in!diesem!Prozess!durch!Austausch!verschiedener!Entwicklungsar"
tefakte.!Deren!Konsistenz!ist!für!eine!spätere!Integration!maßgebend!(siehe!
auch!Abbildung!11).!Im!Rahmen!von!AP7.1!wurden!verschiedene!Ansätze!
untersucht,! um! welche! Informationen! die! relevanten! Artefakte! erweitert!
werden!müssen,!um!die!Integrierbarkeit!der!Komponenten!sicherzustellen!
und!wie!die!Konsistenz!dieser!Artefakte!überprüft!werden!kann.!!
Abbildung 11: Kompatibilität als Voraussetzung für Integrierbarkeit
Dabei!bestand!das!Hauptaugenmerk!darin,!aus!der!Wissenschaft!bekannte!
Konzepte!in!das!Artefaktmodell!zu!integrieren!und!so!anzupassen,!dass!sie!
auch!im!industriellen!Alltag!anwendbar!sind.!
Der! erarbeitete! und! in! [REMsES! 2009a]! dokumentierte! Lösungsansatz! be"

steht! darin,! das! Kommunikationsverhalten! eines! eingebetteten! Systems!
möglichst!abstrakt!auf!Basis!vorhandener!Systemzustände!zu!beschreiben.!
32!
!
Konkret! wird! modelliert! welche! Signale! von! einer! Komponente! in! einem!
festgelegten! Zustand! des! Gesamtsystems! gesendet! werden! und! welche!
Signale!die!Komponente!erwartet.!Im!Rahmen!einer!formalen!Überprüfung!
wird! schließlich! festgestellt,! ob! für! jedes! erwartete! Signal! auch! eine! Kom"
ponente!existiert,!welche!dieses!Signal!aussendet.!
Die! Erprobung! der! Ansätze! erfolgt! neben! den! REMsES"Arbeiten! auch! im!
Rahmen! der! AUTOSAR"Initiative.! Dort! ist! die! Validas! AG! mit! anderen!
Partnern!in!einem!zentralen!Arbeitspaket!dafür!verantwortlich,!die!Spezifi"
kationsmethoden! derart! zu! verbessern,! dass! die! Integrierbarkeit! auch! in!
Zukunft!gewährleistet!ist.!!
7.2 AP!7.2:"Erweiterung"für"die"Produktlinienentwick!
lung"
Produktlinien! bzw.! die! Produktlinienentwicklung! ist! ein! Ansatz,! um! eine!
Menge!von!gleichartigen!Produkten!kostengünstig!und!qualitativ!hochwer"
tig! zu! entwickeln.! Dieses! Ziel! wird! durch! die! proaktive! Wiederverwen"
dung! von! Entwicklungsartefakten! erreicht.! Hierzu! werden! die! Gemein"
samkeiten,! sowie! die! variablen! Teile! der! Produkte! entwickelt! und! doku"
mentiert.!
Im!Zentrum!der!Arbeiten!an!Arbeitspaket!AP"7.2!steht!die!Erweiterung!des!
REMsES"Leitfadens! um! die! explizite! Modellierung! der! Variabilität! in! An"
forderungen! und! damit! assoziierter! Entwicklungsartefakte.! Dazu! werden!
die! entsprechenden! Metamodelle! des! Artefaktmodells! um! Konzepte! zur!
Dokumentation!von!Variabilität!erweitert.!Aufbauend!auf!den!Erweiterun"
gen! des! REMsES"Artefaktmodells,! wird! eine! Modellierungstechnik! zur!
expliziten! Modellierung! der! Produktlinienvariabilität! vorgestellt! und! bei"
spielhaft!illustriert.!Die!Definition!einer!methodischen!Anleitung!zur!expli"
ziten!Berücksichtigung!der!Produktlinienvariabilität!in!REMsES"konformen!
Requirements"Engineering"Prozessen! ergänzen!die! Erweiterungen! des! Ar"
tefaktmodells.!Die!Erweiterung!des!REMsES"Leitfadens!zur!Unterstützung!
der!Produktlinienentwicklung!findet!sich!in![REMsES!2008c].!
33!
In! Rahmen! des! REMsES"Projektes! wurde! eine! Erweiterung! der! von! der!
Arbeitsgruppe! „Software! Systems! Engineering“! der! Universität! Duisburg"
Essen!entwickelte!grafische!Notation!für!Variabilitätsmodelle!erarbeitet,!die!
speziell! auf! die! Dokumentation! der! Produktlinienvariabilität! entlang! der!
drei! Abstraktionsebenen! „Gesamtsystem“,! „Funktionsgruppen“! und!
„Software/Hardware“!abzielt.!Abbildung!12!zeigt!die!verschiedenen!Nota"
tionselemente! der! erweiterten! Variabilitätsmodellierungssprache,! beste"
hend! auf! verschiedenen! Typen! von! Variabilitätspunkten,! Varianten,! der!
Unterscheidung! von! Abstraktionsstufen! sowie! verschiedene! Kantentypen!
zur! Modellierung! von! Abhängigkeiten! innerhalb! der! Variabilitätsmodelle!
und!zur!Modellierung!der!Beziehungen!zu!REMsES"Artefakten.!
Variationspunkt Abstraktionsstufe
VP VP
extern, intern, Variante Abstraktionsstufe
Gesamtsystem
<<name>>
obligatiorsch <<name>>
obligatiorsch
V
VP VP <<name>>
extern, intern,
optional optional
<<name>> <<name>>
Variabilitätsbeziehungen Alternative Artefakt-Beziehungen
obligatorisch [min...max] Artefakt-Beziehung
optional VP-Artefakt-Beziehung
Bedingungsabhängigkeit
requires_v_v requires_v_vp requires_vp_vp
requires_V_V requires_V_VP requires_VP_VP
excludes_v_v excludes_v_vp excludes_vp_vp
excludes_V_V excludes_V_VP excludes_VP_VP
Abbildung 12: Notationselemente für Variabilitätsmodelle im REMsES-Ansatz
Auf! Grundlage! der! in! Abbildung! 12! gezeigten! Modellierungssprache! für!

die! Produktlinienvariabilität! auf! den! drei! REMsES"Abstraktionsebenen!
kann!die!Variabilität!eines!zu!entwickelnden!softwareintensiven!Eingebet"
teten!Systems!getrennt!auf!jeder!der!drei!Abstraktionsebenen!dokumentiert!
werden.!Abbildung!13!zeigt!vereinfachte!Variabilitätsmodelle!des!REMsES"
Ansatzes!auf!der!Gesamtsystemebene.!
34!
!
Abstraktionsstufe Abstraktionsstufe
VP VP
Gesamtsystem Gesamtsystem
Modell Modell
Abstraktionsstufe Abstraktionsstufe
1..1 Gesamtsystem 1..1 Gesamtsystem
V V Sonder- V V Sonder-
Standard Edition VP Standard Edition VP
requires_V_VP HiFi requires_V_V

Farbe
1..1
excludes_V_VP
V V V V V
CD Radio excludes_V_V
orange blau grau
Abbildung 13: Beispiel für Variabilitätsmodelle im REMsES-Ansatz
Abbildung! 14! zeigt! ein! vereinfachtes! Beispiel! für! ein! Variabilitätsmodell,!

dessen! Variationspunkte! und! Varianten! zu! verschiedenen! REMsES"
Artefakten,! wie! Zielen,! Szenarien! und! Anforderungen! relationiert! sind!
(siehe!hierzu!auch![REMsES!2008c]).!!
Ziel Z-3
VP
Abstraktionsstufe
Gesamtsystem Das Auto soll vor unbefugtem
Zugang geschützt werden.
Türschloss
[1..1]
V V Anforderung R-34
Schlüssel Key-Card Die ID der Key-Card muss
verschlüsselt auf dieser
gespeichert sein.
Szenario A Szenario B
Fahrer Türschloss Fahrer Türschloss Terminal
Schlüssel einstecken Card einstecken

Card-ID senden
Tür entriegeln Card-ID prüfen
Prüfergebniss senden
Tür entriegeln
Abbildung 14: Beispielhafte Beziehungen zu REMsES-Artefakten
Neben! der! spezifischen! Erweiterung! der! Variabilitätsmodellierung! hin"

sichtlich!der!Unterstützung!der!drei!REMsES"Abstraktionsebenen!und!der!
Relationierung!von!REMsES"Artefakten!zu!Konzepten!innerhalb!der!Varia"
bilitätsmodelle! wurden! im! Rahmen! des! REMsES"Projektes! Ansätze! zur!
35!
maschinellen! Überprüfung! der! Konsistenz! von! Variabilitätsmodellen! und!
assoziierten! Verhaltensmodellen! entwickelt! [Lauenroth! u.! Pohl! 2007a],!
[Lauenroth!u.!Pohl!2007b].!Abbildung!15!zeigt!einen!Ausschnitt!des!Varia"
bilitätsmodells! für! das! System! „dynamische! Scheibentönung“.! Die! in! der!
Abbildung!dargestellte!Variabilität!wird!im!Folgenden!kurz!beschrieben.!
Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe

Hardware/Software Funktionsgruppe Hardware/Software Gesamtsystem Funktionsgruppe
VP VP VP VP VP
erw. Art der Hellig. Komfort- Fenster-
Sensoren Tönung Sensoren varianten tönung
[1..1] [1..1] [1..2]
V V V V feste V variable V V V Dieb- V Blend- V Hitze- V V

Tunnel Crash Parken Tönung Tönung Basis Komfort stahlschutz streifen schutz Seite Heck
Abbildung 15: Ausschnitt der Variabilitätsmodells „DST“
Abbildung! 16! zeigt! ein! Beispiel! von! zwei! verschiedenen! Szenarien! die! zu!
dem!Variabilitätsmodell!relationiert!sind.!Die!Aktivität!„Tunnel!erkennen“!
ist! zu! der! Variante! „Tunnel“! des! Variationspunktes! „erw.! Sensoren“! rela"
tioniert! und! drückt! somit! aus,! dass! nur! wenn! die! Variante! „Tunnel“! aus"
gewählt! wurde,! auch! die! Aktivität! „Tunnel! erkennen“! in! dem! Szenario!
„hMSC!"!dynamische!Scheibentönung“!vorhanden!ist.!
Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe

Hardware/Software Funktionsgruppe Hardware/Software Gesamtsystem Funktionsgruppe
VP VP VP VP VP
erw. Art der Hellig. Komfort- Fenster-
Sensoren Tönung Sensoren varianten tönung
[1..1] [1..1] [1..2]
V V V V feste V variable V V V Dieb- V Blend- V Hitze- V V

Tunnel Crash Parken Tönung Tönung Basis Komfort stahlschutz streifen schutz Seite Heck
hMSC – Dynamische Schreibentönung bMSC - Crash erkennen
Dyn. Tönung Crash- Tönungs- Front- Seiten- Heck-

sensoren steuerung scheibe scheiben scheibe
aktivieren
Crash erkannt
Frontscheibe
Tunnel Fahrzeug Hitzeschutz Crash entfärben
erkennen parken aktivieren erkennen
Seitenscheiben
entfärben
Heckscheibe
Dyn. Tönung entfärben
deaktivieren
[…]
Abbildung 16: Variable Spezifikation von Szenarien im REMsES-Ansatz
36!
!
Ist!die!Variante!„Tunnel“!nicht!ausgewählt,!wird!die!Aktivität!inklusive!der!
ein"!und!ausgehenden!Flüsse!aus!dem!Szenario,!und!damit!aus!der!Appli"
kationsanforderungsspezifikation,!entfernt![Lauenroth!u.!Pohl!2008].!
7.3 AP!7.3:Entwicklung"eines"REMsES!Werkzeuges"
Im! Rahmen! des! AP7.3! wurde! überprüft! ob! und! in! welcher! Form! sich! die!
erarbeiteten! Konzepte! aus! REMsES! durch! Tools! unterstützen! lassen.! Ziel!
war!es!einen!Prototypen!zu!entwickeln,!der!es!ermöglicht!unterschiedlichs"
te! Artefakte,! wie! eben! auch! die! in! REMsES! definierten! Artefakte,! die! im!
Rahmen!einer!Entwicklung!eines!eingebetteten!Systems!entstehen,!zu!ver"
walten.!
Ein! Werkzeug! zur! Verwaltung! von! Artefakten! muss! sich! dabei! in! eine!
komplexe! Landschaft! einordnen! (vergleiche! Abbildung! 17).! Die! Entwick"
lung! der! Artefakte! findet! jeweils! in! spezialisierten! Werkzeugen! statt,! eine!
übergreifende!Verwaltung!von!Artefakten!ist!dagegen!oftmals!nicht!vorge"
sehen.!
Abbildung 17: Das REMsES-Werkzeug
37!
Eine!besondere!Rolle!spielen!dabei!Beziehungen!zwischen!den!Artefakten.!
Ob! zwischen! zwei! Artefakttypen! eine! Beziehung! bestehen! kann,! wird!
durch!das!Artefaktmodell!festgelegt.!Das!Werkzeug!unterstützt!schließlich!
das!Projektteam!dahingehend,!dass!bei!der!Erstellung!eines!Artefakts!fest"
gelegt!werden!muss,!ob!eine!entsprechende!Beziehung!existiert!oder!nicht.!
Ist! dies! gegeben,! so! sind! zusätzliche! Informationen! hinterlegt,! durch! wel"
che!Art!von!Überprüfung!die!Konsistenz!der!Beziehung!überprüft!werden!
kann.!!
Dabei!gibt!es!unterschiedliche!Beziehungen:!!
! Strukturelle!Abhängigkeiten!zwischen!Artefakten,!wie!beispielswei"
se!Kompositionsbeziehungen!(„A!ist!Teil!von!B“)!
! Konsistenzbeziehungen,!die!aussagen,!dass!beispielsweise!zwei!Ar"
tefakte!zueinander!schnittstellenkompatibel!sind!
! Generierungsbeziehungen,! die! aussagen,! dass! beispielsweise! ein!

Testprotokoll! aus! einem! bestimmten! Verhaltensmodell! und! einer!
bestimmten!Szenariobeschreibung!gewonnen!wurde.!
Diese! Beziehungen! müssen! nun! gemeinsam! mit! den! Artefakten! verwaltet!

werden.!Zum!einen!muss!ein!Anwender!Beziehungen!zwischen!Artefakten!
erstellen! oder! verändern! können,! zum! anderen! haben! Beziehungen! Zu"
stände,!z.B.!ob!sie!geprüft!wurden.!Im!REMsES"Werkzeug!werden!die!Be"
ziehungen! in! einer! Versionsverwaltung! abgelegt,! es! wird! eine! Zustands"
verwaltung! der! Beziehungen! realisiert! und! basierend! auf! den! Zuständen!
wird!ein!Ticketsystem!angebunden,!das!es!dem!Anwender!ermöglicht!Än"
derungen!und!Prüfaktivitäten!zu!koordinieren.!
Das!entwickelte!Werkzeug!setzt!diese!Ansätze!prototypisch!um.!Die!Reali"
sierung!setzt!dabei!auf!verschiedene!frei!verfügbare!Werkzeuge!(Versions"
verwaltung!und!Ticketsystem)!auf,!so!dass!in!relativ!kurzer!Zeit!ein!großer!
Leistungsumfang!des!Werkzeugs!realisiert!werden!konnte.!!
Dabei! konnte! gezeigt! werden,! wie! Artefakte! und! deren! Beziehungen! mo"
delliert!und!schließlich!modellgestützt!verwaltet!werden!können.!Der!reali"
sierte! Prototyp! dient! als! Anschauungsbeispiel,! wie! die! Konzepte! mit! ver"
tretbarem! Aufwand! auf! der! Basis! von! frei! verfügbaren! Werkzeugen! reali"
38!
!
siert!werden!können.!Ebenso!konnte!mit!dem!Prototyp!gezeigt!werden,!wie!
eine! relative! lose! Kopplung! bestehender! Entwicklungswerkzeuge! auf! der!
Basis! eines! Artefaktmodells! erfolgen! kann.! Eine! weitergehende! Beschrei"
bung! der! Architektur! des! Werkzeugs! und! der! grundlegenden! Konzepte!
findet!sich!in![REMsES!2009b].!
39!
!
8 Posterpräsentation"
Dieses!Kapitel!enthält!eine!Posterpräsentation!des!Verbundprojekts!„REM"
sES“,! die! die! Problemstellung! des! Projektes,! die! wesentlichen! Prinzipien!
sowie!für!jeden!im!Rahmen!von!AP"3!betrachteten!Themenkomplex!dessen!
Problemstellung!und!Lösungsansatz!zeigt.!Im!Einzelnen!handelt!es!sich!um!
die!folgenden!Poster:!
! Poster!„Herausforderungen!des!REMsES"Projekts“,!Autoren:!Eva!Geisber"
ger! (Technische! Universität! München),! Matthias! Kirchmayr! (Daimler!
AG),!Mark!Müller!(Robert!Bosch!GmbH),!Thorsten!Weyer!(Universität!
Duisburg"Essen)!
! Poster! „Bestandteile! des! REMsES"Leitfaden“,! Autoren:! Eva! Geisberger!

(Technische!Universität!München),!Matthias!Kirchmayr!(Daimler!AG),!
Mark! Müller! (Robert! Bosch! GmbH),! Thorsten! Weyer! (Universität!
Duisburg"Essen)!
! Poster! „Kontextanalyse! und! Kontextverfeinerung“,! Autoren:! Wassiou! Si"

tou! (Technische! Universität! München),! Thorsten! Weyer! (Universität!
Duisburg"Essen)!
! Poster!„Ableitung!von!lösungsorientierten!Anforderungen“,!Autor:!Nadine!
Bramsiepe!(Universität!Duisburg"Essen)!
! Poster! „Ziel"! und! szenariobasiertes! Requirements! Engineering“,! Autor:!

Ernst!Sikora!(Universität!Duisburg"Essen)!
! Poster! „Erkennung! von! Feature! Interactions! auf! Nutzungsebene“,! Autor:!

Johannes!Grünbauer!(Technische!Universität!München)!
! Poster!„Transition!von!Gesamtsystem!auf!Subsysteme“,!Autor:!Birgit!Pen"
zenstadler!(Technische!Universität!München)!
41!
!
8.1 „Herausforderungen"des"REMsES!Projektes“"
!
Leitfaden für modellbasiertes Requirements Engineering

und Management softwareintensiver Eingebetteter Systeme
Herausforderungen
Entwicklung softwareintensiver eingebetteter
Systeme in der Praxis
Ausgangssituation im Automobil-, Maschinen- und Anlagenbau
• Funktionsvielfalt eingebetteter Systeme mit starker Vernetzung
• Kraftfahrzeuge mit bis zu 2500 softwaregesteuerten Funktionen
• Integration in komplexe Systemlandschaften
• Komplexe Maschinen, Anlagen mit bis zu 2000 Steuerungen
• Kombiinstrumente mit mehr als 20.000 Anforderungen
• Große Anzahl von Anforderungen mit komplexen Abhängigkeiten
Ethernet
CAN Support +
RS 232 Programmierung
bedienen
visualisieren
kommunizi eren
kommunizieren
+ steuern
schalten
steuern + schalten
steuern + regeln
steuern + positionieren
Support + Programmierung
regeln + positionieren
Bedarf an Methoden, Tools und Anleitung für:

• Systematische Erhebung von Anforderungen
• Geeignete Strukturierung und Dokumentation von Anforderungen
• Abstimmung und Konsolidierung von Anforderungen
• Verwaltung und Verfolgung von Anforderungen
Erarbeitung eines Requirements-Engineering-Praxisleitfadens

!Wer (Rollenmodell) muss
!Was (Artefaktmodell)
!Wie (Methoden und Vorgehensmodell) erarbeiten?
Autoren: Geisberger, Kirchmayr, Müller, Weyer © REMsES-Konsortium: Robert Bosch GmbH - Daimler AG - Technische Universität München - Universität Duisburg-Essen
!
42!
!
8.2 „Bestandteile"des"REMsES!Leitfadens“"
!

Bestandteile des REMsES-Leitfadens

Das REMsES-Artefaktmodell strukturiert die zu erarbeitende
Anforderungs- und Systemspezifikation nach Kontext-, Anforderungs- und
Entwurfsartefakten und domänenspezifischen Abstraktionsebenen des
Systementwurfs: Gesamtsystem-, Funktionsgruppen-, HW-/SW-Ebene
-Artefaktmodell
SP-1: nach „grundlegenden Modellierungsaspekten“
Kontext Anforderungen Entwurf

Gesamtsystem GS- GS- GS- Das Artefaktmodell ist Basis für
GS- GS- GS-
(GS) Kontext
Kontext Anforderungen
Anforderungen Entwurf
Entwurf
die Aktivitäten und Methoden des
Vorgehensmodells
Funktionsgr. FG-
FG- FG-
FG- FG-
FG-
Kontext Anforderungen Entwurf Zwischen den
(FG) Kontext Anforderungen Entwurf
Artefakten sind
Verfeinerungs-
Hardw./Softw. HW/SW-
HW/SW- HW/SW-
HW/SW- HW/SW-
HW/SW- und Konsistenz-
(HW/SW) Kontext
Entwurf Beziehungen
definiert.
SP-2: nach „Systemabstraktionsebenen“
Artefakt-basierte Schnittstellendefinition
zu den REMsES-Umfeldprozessen
Schnittstellen-Artefakt
Produktmanagement
Grobgranulares
Vorgehen Projektmanagement
Feingranulare Entwicklung
Aufgaben …
-Vorgehensmodell
-Umfeldmodell
Das REMsES-Vorgehensmodell definiert Das REMsES-Umfeldmodell legt die für

das grobe Vorgehen und feingranulare das Requirements Engineering relevanten
Aufgaben und Methoden der Umfeldprozesse fest und definiert die Ein-
Anforderungsspezifikation und Ausgabeschnittstellen zu den
Aufgaben des Requirements Engineering
Autoren: Geisberger, Kirchmayr, Müller, Weyer © REMsES-Konsortium: Robert Bosch GmbH - Daimler AG - Technische Universität München - Universität Duisburg-Essen
!
!
43!
8.3 „Kontextanalyse"und"Kontextverfeinerung“"
!

Kontextanalyse und Kontextverfeinerung

Problemstellung
Erfassung des für die Ermittlung der Anforderungen Strukturmodell
„Geschäftskontext“
relevanten Kontexts des zu entwickelnden Systems behindert
Beitrag
Artefaktmodell
trägt bei
gilt für
Ziel
Definition von Strukturmodellen für Artefakte Sicht Zielkomposition Operationelles Ziel Qualitätsziel
zur Analyse und Dokumentation des Kontexts

Marketing
Konjunktion Disjunktion Rahmenbedingung
Management
Architekt Nutzer
Funktionsbezogene Systembezogene
GS-
GS- GS-
GS- GS-
GS- Analyst Kunde
Rahmenbedingung Rahmenbedingung
Kontext
Anforderungen Architektur
Architektur
FG-
FG- FG-
FG- FG-
FG- Systemkontext
Kontext Anforderungen Architektur
Kontext Anforderungen Architektur
„Stakeholder“
HW/SW-
HW/SW- HW/SW-
HW/SW- HW/SW-
HW/SW-
Kontext
Architektur Geschäftskontext
Systemkontext
„operationelle
Umgebung“
ist Ursprung !
ist Ursprung ! ist Usprung!
er2: Ereignis e8: Eigenschaft
* *
energetisches mat./räumliches “Einfahrt Tunnel (RFW)” “Zeichen 327 VwV-StVO § 41 ”
* technisches
Ausprägung physikalisches physikalisches
abhängig Ereignis
ist Ursprung !
Ereignis Ereignis as1: adjazentes System

"ist Stimulus
as1: adjazentes System

*
* 1
1 "steuert “Radio-Frequenz-Warnsystem (RFW)” “Crash-Detection-System (CDS)”
physikalische 1 "misst
* * #1 #1
* Größe * Eigenschaft Ereignis
1..* PG2: physikalische Größe
* k1: Kopplung k2: Kopplung
"ist definiert durch
* * 0..1 Technische
Aktuator * “Umgebungshelligkeit”
"ist Stimulus
energetische mat./räumliche Umgebung Sig.: “DST_TUNNEL” Sig: “CRASH_ZUSTAND”

"ist Aktuator
"eingebettet
1
physikalische physikalische Art: “CAN-Bus” Art: “CAN-Bus”
"definiert
durch
Größe Größe * *
Sensor au1: Ausprägung
"ist Sensor
1 ov1: operationelle Vorgabe

#2
materieller Kopplung s: System Bez.:“Dunkelheit bis Vollmond”
bezieht sich !
* “Abmaße Stg. max 12x14x7”

Gegenstand * * Wert: “<2 LUX”
* * * *
bezieht sich! “Stg. dynamische Scheibentönung (DST)”
* physikalische "eingebettet System Adjazentes au2: Ausprägung
ist Gegenstand der !
Umgebung 0..1 * (Kontextsubjekt) * * System
* * Bez.:“Stark bedeckter Himmel”
*
* operationelle * bezieht sich ! * Art der 0..1 k4: Kopplung k3: Kopplung Wert: “1500-2000 LUX”
Vorgabe !
Vorgabe Interaktion
definiert
abhängig
besitzt !
* Sig: “TÖNUNG_WERT” Sig: “UMGEBH_S1” au3: Ausprägung

* *
Art: “CAN-Bus” Art: “LIN-Bus”
Rolle Bez.:“Sonnenlicht”
Schnittstelle Wert: “>150000 LUX”
"ist Stimulus
* 1..*
bezieht sich ! a1: Aktuator s1: Sensor
bezieht sich ! misst!
“Stg. DST Windschutzscheibe”
Strukturmodell „operationelle Umgebung“

“Helligkeitssensor 1”
"ist Ursprung
er1: Ereignis
“Einfahrt Tunnel (LUX)” {AND}
e6: Eigenschaft e7: Eigenschaft
Instanz von “Lux" > 2000 LUX” “Zeit" < 3 Sekunden”
Kontextmodell „operationelle Umgebung“

Aufgaben (Beispiel)
- „Entwicklung Kontextdiagramm operationeller Funktionsgruppenkontext“
Autoren: W. Sitou, T. Weyer © REMsES-Konsortium: Robert Bosch GmbH - Daimler AG - Technische Universität München - Universität Duisburg-Essen
!
44!
!
8.4 „Ableitung"von"lösungsorientierten"Anforderungen“"
!

Ableitung von lösungsorientierten

Anforderungen
Problemstellung
Ableitung von lösungsorientierten Anforderungen unter
- Einbeziehung aller relevanter Artefakte
- Berücksichtigung der drei Abstraktionsebenen
Artefaktmodell
Gesamtsystem
Gesamtsystem
Signalton
ausgeben
Signalton
Radio-Frequenz warnen
Verkehrzeichen
Funktionsanforderungen des Fahrers
Signal erkanntes
Verkehrszeichen
Anzeige
SysML
Funktionsgruppen
Funktionsgruppen überprüfen des Signals
Signal relevant? erkanntes
Radio-Frequenz Signal Signal Verkehrszeichen Anzeige
Verkehrzeichen ja
Signal identifizieren auswerten
ja Signalton
nein Warnung ausgeben?
ausgeben
Signalton
Funktionsgruppenanforderungen
nein
SysML
Hardware/Software
Hardware/Software Name der Funktion Auswertung des RFID-Signals
eindeutige ID 23-A-3456-DS
Eingabedaten/Eingabesignale
Name Zugeordnetes Signal Status/ Wertebereich Datum Externe Zusicherung
ID des RFID-Signals Signal 56 auf CAN 2 000-999 Integer Ist eine gültige ID
Softwarefunktionsanforderungen Akt. Uhrzeit Signal 2 auf CAN 1 hh:mm Integer Uhrzeit ist im 24h Format
[...] Template
Aufgaben
1 Ableitung von Funktionsanforderungen aus Systemzielen, -szenarien,
Kontext und Architektur
2 Ableitung von Funktionsgruppenanforderungen aus Funktionsanforderungen
3 Ableitung von Funktionsgruppenanforderungen aus Zielen, Szenarien,

Kontext und Architektur Ziele Szenarien
GS- GS-
4 Ableitung von Softwarefunktions- Kontext Anforderungen Architektur
Anforderungen
anforderungen aus Funktions- 1
2
1
gruppenanforderungen Ziele Szenarien

FG- 3 FG-
5 Ableitung von Softwarefunktions-
3
anforderungen aus Kontext, 4
3
Zielen und Szenarien Ziele Szenarien HW/SW- 5 HW/SW-

5 5
Autor: N. Bramsiepe © REMsES-Konsortium: Robert Bosch GmbH - Daimler AG - Technische Universität München - Universität Duisburg-Essen
!
45!
8.5 „Ziel!"und"szenariobasiertes"Requirements"
Engineering“"
!

Ziel- und szenariobasiertes

Requirements Engineering für
softwareintensive Systeme
1. Schritt: Entwicklung eines Zielmodells und eines Szenariomodells auf
der Abstraktionsstufe Gesamtsystem
Zielmodell Szenariomodell
Verringerung des Diebstahlschutz Wärmereduktion Dynamische Scheibentönung
Unfallrisikos
Verdunklung
bei geparktem
++ ++ Fahrzeug
++
Automatische
Scheibentönung
Vermeidung Freie Sicht Vollständige Tönung während der Fahrt
der Blendung der Scheiben bei <<include>> <<extend>>
während der
des Fahrers Fahrt geparktem Fahrzeug Fahrer
<<include>>
Sofortige
Verdunklung der
++ Enttönung der Entfärbung im
++ Scheiben während
Scheiben während Tunnel
der Fahrt
der Fahrt
Automatische Sofortige Entfärbung Einhalten der

Gradueller
Scheibentönung der Scheiben im minimal zulässigen
Tönungsprozess
während der Fahrt Tunnel Lichtdurchlässigkeit AF-I1 Verdunklung der Scheiben während der Fahrt
Ebene Gesamtsystemebene
Prim. Akteur Fahrer
Verdunklung der Scheiben während der Fahrt
Mess- und " Lichtintensität
Z-3 Automatische Scheibentönung während der Fahrt Steuergrößen " Tönungsstufe Windschutzscheibe
" Tönungsstufe Seitenscheiben vorne
Ebene Gesamtsystemebene
... Dynamische Windschutz-
Geltungsbereich Fahrzeug/Scheibentönung Fahrer
Hauptszenario Schritt Aktion Scheibentönung scheibe
Zieltyp Hard Goal 1 Der Fahrer aktiviert die automatische Scheibentönung.
Zielkategorie Avoid 2 Das System signalisiert dem Fahrer die Aktivierung. aktivieren
Kritikalität sehr hoch 3 Das System erkennt die Blendung des Fahrers durch das einfallende Licht.
Anzeige „aktiv“
Zielbeschreibung Wenn das System eine Blendung des Fahrers durch die Sonne 4 Das System tönt die Windschutzscheibe und die Seitenscheiben vorne
oder durch das Scheinwerferlicht entgegen kommender sukzessive bis zu der maximal zulässigen Tönungsstufe. verdunkeln
Fahrzeuge erkennt, soll es die Windschutzscheibe verdunkeln. ...
... Besondere " Schritt 3: Die Scheibentönung soll erst dann aktiviert werden, wenn die Lichtintensität
Anforderungen für mindestens 3 Sekunden mehr als 40% beträgt.
Assoziierte " AF-2 „Automatische Scheibentönung während der Fahrt“
" Schritt 4: Der Tönungsvorgang muss sanft erfolgen, um den Fahrer nicht zu
Szenarien erschrecken.
## Ein
Ein Zielmodell
Zielmodell bietet
bietet einen
einen Überblick
Überblick ## Ein
Ein Szenariomodell
Szenariomodell dokumentiert
dokumentiert die
die
über
über die
die geforderten
geforderten geforderten
geforderten Interaktionen
Interaktionen des
des Systems
Systems
Systemeigenschaften
Systemeigenschaften mit
mit der
der Umgebung
Umgebung
2. Schritt: Entwurf einer initialen, groben Systemarchitektur basierend

auf den Anforderungen (Abstraktionsstufe Funktionsgruppen)
Dynamische Scheibentönung
Benuter-
## Das
Das Architekturmodell
Architekturmodell definiert
definiert eine
eingaben
eine
Ansteuer-
Ansteuerung signal
Bedienung
Windschutz-
und Anzeige
logische
logische Partitionierung
Partitionierung der
der System-
scheibe
Anzeige-
daten
System-
funktionalität
funktionalität in
in „Funktionsgruppen“
„Funktionsgruppen“
Tönungs-
steuerung
Lichtsensor- Messdaten-
daten Ansteuerung
auswertung Ansteuer-
Seitenscheiben
signal
3. Schritt: Verfeinerung der Anforderungsmodelle und des

Architekturmodells (Abstraktionsstufe Funktionsgruppen)
Verdunklung der Scheiben während der Fahrt (Verfeinertes Szenario auf der Abstraktionsstufe Funktionsgruppen)
Fahrer
Bedienung
und Anzeige
FG
Tönungs-
steuerung
FG
Messdaten-
auswertung
FG Ansteuerung
Windschutz-
scheibe
FG
Windschutz-
scheibe
## Systemanforderungen
Systemanforderungen werden
werden den
den
aktivieren
Aktivierungs-
anforderung
Funktionsgruppen
Funktionsgruppen zugeordnet
zugeordnet und
und
Aktivierungs-
bestätigung
verfeinert
verfeinert
Anzeige „aktiv“ Intensität größer 40%
abtönen auf Stufe 3

Abtönvorgang
gemäß Kennlinie
Autor: E. Sikora © REMsES-Konsortium: Robert Bosch GmbH - Daimler AG - Technische Universität München - Universität Duisburg-Essen
!
46!
!
8.6 „Erkennung"von"Feature"Interactions"auf"
Nutzungsebene“"

Erkennung von Feature

Interactions auf Nutzungsebene
Modellierung von Abhängigkeiten
Problemstellung
Notwendigkeit der Erkennung
• Hohe Komplexität (multifunktionaler) Systeme aller Zusammenhänge zwischen
• Hohe Anzahl von Abhängigkeiten zwischen Funktionen Funktionen bereits in der frühen
Phase der Software-Entwicklung
Lösung
1. Modell zur Darstellung von Nutzungsbeziehungen
zwischen Nutzungsfunktionen und Belegungen von
Zustandsvariablen aus Sicht des Nutzers (Quelle:
Anforderungsdokumente)
2. Bildung von Instanzen aus dem Modell
Nutzungsfunktion Generierung möglicher Kombinationen von
Zustandsbelegungen in Abhängigkeit der
Beziehungen
Mögliche
Belegung der
Variablen ZS
(Zündschloss)
Beziehungen
mit den Werten
zwischen
ein und aus
Modellelementen
3. Analyse der gebildeten Instanzen

Beispiel für eine problematische ZS kann entweder den Wert ein oder aus
Konstellation innerhalb einer Instanz besitzen. Davon abhängig kann die Funktion
‚Klimaanlage‘ zur Nutzung freigegeben
(enable) oder gesperrt (disable) werden. Die
Instanzenbildung erfolgt werkzeuggestützt.
4. Feedback
Indiz für
unerwünschte
Beeinflussung
Erkenntnisse
aus der Analyse
Nutzungsfunktion NF soll abhängig vom werden dazu
Wert ZS.ein zur Nutzung freigegeben verwendet, die
werden, jedoch in Abhängigkeit von Anforderungs-
HS.aus zur Verwendung gesperrt dokumente zu
werden. verbessern.
Autor: J. Grünbauer © REMsES-Konsortium: Robert Bosch GmbH - Daimler AG - Technische Universität München - Universität Duisburg-Essen
!
47!
8.7 „Transition"von"Gesamtsystem"auf"Subsystem“"
!

Transition von Gesamtsystem

auf Subsysteme
Problemstellung
• Verstehe Übergang Gesamtsystem – Subsysteme
• Separate Betrachtung von Subsystemen für
Vergabe von Entwicklungsaufträgen und Wiederverwendung
Artefaktmodell Gesamtsystem
Gesamtsystem
,-%*#) 4*56-0%*#(
Entwurf
Entwurf .'/*00 (1*+&2&$3
Funktionale
Direktive Kriterien !"#$%&'#()
GS-
GS- GS-
GS- GS-
GS- 9:6;#<&<$*&%( 786#&%%(%*00*#
Kriterien Kontext Anforderungen Entwurf #*%+ .'/*00
Kontext Anforderungen Entwurf Dekompositionskriterien (1*+&2&$3
Qualitäts- bestimmen die Transition
Kriterien von Gesamtsystem auf
FG-
FG- FG-
FG- FG-
FG- Subsysteme (FG)
Kontext
Entwurf
Funktionsgruppen
Funktionsgruppen
>'.1'#*#%*# 4*56-0%*#(
Architektur- Entwurf
Entwurf (1*+&2&$3 (1*+&2&$3
Kriterien
HW/SW-
HW/SW- HW/SW-
HW/SW- HW/SW-
HW/SW-
Kontext
Entwurf =5*#+) ,-%*#) 786#&%%(%*00*#
(1*+&2&$3 (1*+&2&$3 (1*+&2&$3
Template
Modellierung der Subsystemgrenzen Hardware/Software

Hardware/Software
•Funktionalität Entwurf
Entwurf
–Angebotene Dienste
–Benötigte Dienste ?-5/@-5* A-"2+*&%) ,*10'D.*#%
•Konformität %'1'0'<&* (&86%B7C
–Standards, Gesetze, Geschäftsregeln
•Kompatibilität
–Kompatibilität
•Semantik und Syntax
•Kommunikation: Modus und Format
•Datenfluss: Typen, Wertebereiche, Stepping
–Qualität
•Ressourcen
•Echtzeitbedingungen
•Zuverlässigkeit
–Variabilität
Prozess
Autor: B. Penzenstadler © REMsES-Konsortium: Robert Bosch GmbH - Daimler AG - Technische Universität München - Universität Duisburg-Essen
!
!
48!
!
9 Zusammenfassung"und"Ausblick"
Der! vorliegende! Bericht! beschreibt! die! Arbeiten! und! Ergebnisse! des! vom!
BMBF! geförderten! Forschungsprojekts! REMsES,! das! im! Rahmen! der! For"
schungsoffensive! Software! Engineering! 2006! durchgeführt! wurde.! Das!
Hauptergebnis!von!REMsES!ist!ein!praxisnaher!Leitfaden!für!das!Require"
ments!Engineering!softwareintensiver,!eingebetteter!Systeme.!!
Der! Bericht! gliedert! sich! anhand! der! Arbeitspakete! des! Projektes! und! be"
schreibt! die! Anforderungsanalyse! für! den! Leitfaden,! die! erarbeiteten!
Grundprinzipien! für! den! Leitfaden,! den! Leitfaden! selbst,! die! Evaluierung!
des! Leitfadens! in! Workshops,! Experimenten! und! Fallstudien,! sowie! die!
Entwicklung!spezifischer!Erweiterungen!für!den!Leitfaden.!Als!Abrundung!
wurden! die! Forschungsschwerpunkte! anhand! einer! kurzen!
Posterpräsentation!illustriert.!
In!REMsES!wurden!zunächst!Anforderungen!an!den!Leitfaden!aus!indust"
rieller! Sicht! spezifiziert:! Der! Leitfaden! sollte! die! Spezifikation! von! Syste"
men!als!auch!Detail"Anforderungen!an!bestehenden!Softwarekomponenten!
ermöglichen.! Der! Leitfaden! hat! diese! Anforderung! umgesetzt,! indem! eine!
Reihe!von!Grundprinzipien!umgesetzt!wurden:!Die!explizite!Berücksichti"
gung! der! Systemzerlegung,! die! Unterscheidung! zwischen! Problem"! und!
Lösungsraum,!Modellbasierung,!und!Artefaktbasierung.!
Für! die! Systemzerlegung! wurden! drei! verschiedene! Abstraktionsebenen!

eingeführt,! diese! sind! Gesamtsystemebene,! Funktionsgruppenebene! und!
Hardware/Software"Ebene.! Zur! Unterscheidung! zwischen! Problem"! und!
Lösungsraum!wurden!drei!Inhaltskategorien!definiert,!bezeichnet!als!Kon"
text,!Anforderungen!und!Design,!die!über!die!drei!Ebenen!hinweg!die!gro"
be!Strukturierung!der!Inhalte!vorgeben.!Diese!Struktur!ist!die!Basis!für!das!
Artefaktmodell,! das! modellbasierte! Artefakte! inklusive! Beschreibung! von!
zugehörigen! Notationstechniken! und! Methoden! im! Leitfaden! zur! Verfü"
gung! stellt,! und! damit! die! Prinzipien! Modellbasierung! und!
Artefaktbasierung!umsetzt.!
49!
Zudem! muss! der! Leitfaden! einfach! in! bestehende! Prozesse! integriert! wer"
den!können.!Um!diese!Anforderung!zu!ermöglichen,!enthält!REMsES!eine!
Vielzahl! von! Vorlagen! und! Artefakten,! die! unternehmensspezifisch! ange"
passt!werden!können.!
Der! Leitfaden,! der! dem! Entwickler! das! Spezifizieren! erleichtern! soll,! be"
schreibt! das! Artefaktmodell! und! die! Methoden! an! einem! durchgängigen!
Beispiel!und!ist!unter!http://www.remses.org!frei!verfügbar.!!
Das! Forschungsprojekt! SPES! (Software! Platform! Embedded! Systems),! das!

zum! Zeitpunkt! der! Entstehung! dieses! Technischen! Berichts! das! Schlüssel"
projekt!in!der!deutschen!Forschung!zum!Thema!Engineering"Theorien!für!
eingebettete!Systeme!ist,!hat!sich!die!Entwicklung!einer!ganzheitlichen!do"
mänenunabhängigen!Entwicklungsplattform!für!eingebettete!Systeme!zum!
Ziel! gesetzt.! Aus! der! SPES"Perspektive! ist! der! REMsES"Ansatz! mit! seinen!
Prinzipien,! Techniken,!Methoden! und! seiner! Werkzeugunterstützung! eine!
signifikante! domänenspezifische! Vorleistung.! Derzeit! wird! der! REMsES"
Ansatz! als! Teil! des! SPES"Projektes! verallgemeinert! und! für! ein! breiteres!
Spektrum!von!Domänen!erweitert.!
50!
!
10 Veröffentlichungen"des"REMsES!Projekts"
—!REMsES!Ergebnisberichte!—!
![REMsES!2005]!Wußmann,!H.;!Diestelmann,!M.;!Pohl,!K.;!Broy,!M.;!Houdek,!F.:!
Leitfaden! für! modellbasiertes! Requirements! Engineering! und! "Management!
softwareintensiver!Eingebetteter!Systeme!(REMsES),!Vorhabensbeschreibung!
im! Rahmen! der! Forschungsoffensive! „Software! Engineering! 2006“,! Eningen!
2005.!
[REMsES!2006]!Bramsiepe,!N.;!Grünbauer,!J.;!Halmans,!G.;!Heumesser,!N.;!Hou"
dek,! F.;! Omasreiter,! H.;! Sitou,! W.;! Weyer,! T.:!Stand!von! Praxis! und! Wissen"
schaft!und!Anforderungen!an!den!Leitfaden,!D"1.2,!REMsES"Konsortium,!Es"
sen!et!al.,!!2006!
[REMsES,! 2007a]! Bramsiepe,! N.;! Broy,! M.;! Geisberger,! E.;! Grünbauer,! J.! ;! Hal"
mans,! G.;! Penzenstadler,! B.;! Pohl,! K.;! Schmidt,! T.;! Sikora,! E.;! Sitou,! W.;!
Weyer,! T.:! REMsES"Positionspapier! "! Kernbestandteile! des! Leitfadens,! Ziel"
setzungen!und!Forschungsfragestellungen,!Essen,!München,!2007!
[REMsES!2007b]!Bramsiepe,! N.;! Geisberger,! E.;! Grünbauer,!J.;! Houdek,! F.;! Knee,!

C.;! Metzker,! E.;! Omasreiter,! H.;! Sikora,! E.;! Sitou,! W.;! Weyer,! T.:! Top"Level"
Vorgehensmodell! und! Umfeldmodell,! D"2.1,! REMsES"Konsortium,! Essen! et!
al.,!2007!
[REMsES! 2007c]!Bramsiepe,! N.;! Geisberger,! E.;! Grünbauer,! J.;! Halmans,! G.;! Pen"
zenstadler,!B.;!Schmidt,!T.;!Sikora,!E.;!Sitou,!W.;!Weyer,!T.:!Grobes!Produkt"
modell! inklusive! der! Abstraktionsebenen! zur! Strukturierung! und! Modellie"
rung!von!Anforderungen,!D"2.2,!REMsES"Konsortium,!Essen!et!al.,!2007!
[REMsES!2007d]!Bramsiepe,!N.;!Grünbauer,!J.;!Halmans,!G.;!Knee,!C.;!Leuser,!J.;!
Metzker,!E.;!Sikora,!E.;!Sitou,!W.;!Weyer,!T.:!Ausarbeitung!des!Leitfadens!auf!
Abstraktionsstufe! #Gesamtsystem#,! D"3.1,!REMsES"Konsortium,! Essen!et! al.,!
2007!
[REMsES! 2007e]! Dietrich,! K.:! Illustrator! “Dynamische! Scheibentönung! (DST)”,!

REMsES"Konsortium,!Stuttgart,!2007!
[REMsES!2007f]!Rischard,!S.;!Illustrator!“Radio"Frequenz"Warner!(RFW)”;!REM"
sES"Konsortium,!Stuttgart,!2007!
[REMsES! 2008a]! Bramsiepe,! N.;! Grünbauer,! J.;! Penzenstadler,! B.;! Schmidt,! T.;!
Lochmann,! K.;! Sikora,! E.;! Weyer,! T.;! Ausarbeitung! des! Leitfadens! auf! Ab"
51!
straktionsstufe!#Funktionsgruppen#,!D"3.2,!REMsES"Konsortium,!Essen!et!al.,!
2008!
[REMsES! 2008b]! Bramsiepe,! N.;! Braun! P.;! Lochmann,! K.;! Penzenstadler,! B.;! Phi"
lipps,!J.;!Sikora,!E.;!Weyer,!T.:!Ausarbeitung!des!Leitfadens!auf!der!Abstrakti"
onsebene! „Hardware/Software“,! D"3.3,! REMsES"Konsortium,! Essen! et! al.,!
2008!
[REMsES! 2008c]! Bramsiepe,! N.;! Lauenroth,! K.;! Weyer,! T.:! Ergänzung! des! REM"
sES"Leitfadens! für! die! Produktlinienentwicklung,! D"7.2.1,! REMsES"
Konsortium,!Essen,!2008!
[REMsES! 2008d]! Metzker,! E.:! Anforderungsdokumentation! für! die! Umsetzung!

des! Leitfadens! in! ein! Werkzeug,! D"7.3.1,! REMsES"Konsortium,! Stuttgart,!
2008!
[REMsES! 2009]! Kirchmayr,! M.;! Müller,! M.;! Penzenstadler,! B.;! Sikora,! E.;! Weyer,!
T.:! Essenzieller! REMsES"Leitfaden,! D"5.2.1,! REMsES"Konsortium,! Essen! et!
al.,!2009!
[REMsES! 2009a]! Bechter,! M.;! Braun,! P.;! Philipps,! J.:! Auftraggeber"

/Auftragnehmer"Beziehungen!–!Integrierbarkeit!von!Zuliefererartefakten,!D"
7.1,!REMsES"Konsortium,!München,!2009!
[REMsES!2009b]!Braun,!P.;!Philipps,!J.;!Penzenstadler,!B.:!Anwendung!des!Leitfa"
dens! auf! Werkzeuge! im! REM! –! Werkzeugkonzept,! D"7.3,! REMsES"
Konsortium,!München,!2009!
—!Konferenzen,!Workshops,!Zeitschriften!—!
[Bramsiepe!et!al.!2008]!Bramsiepe,!N.;!Sikora,!E.;!Pohl,!K.:!Ableitung!von!System"
funktionen!aus!Zielen!und!Szenarien,!GI"FG"Treffen,!Berlin,!Dezember!2007,!
Softwaretechnik"Trends,!Jg.!2008,!Nr.!1.!!
[Geisberger!et!al.!2009]!Geisberger,!E.;!Kirchmayr,!M.;!Müller,!M.;!Weyer,!T.:!Ent"
wicklung! eines! Praxisleitfadens! für! das! modellbasierte! Requirements! Engi"
neering! softwareintensiver! eingebetteter! Systeme,! In:! Softwaretechnik"
Trends,!29:1!
[Grünbauer! 2008]! Grünbauer,! J.:! Feature! Interactions! auf! Nutzungsebene! –! Mo"

dellierung! und! Analyse! der! Abhängigkeiten,! GI"FG"Treffen,! Berlin,! Dezem"
ber!2007,!Softwaretechnik"Trends,!Jg.!2008,!Nr.!!
52!
!
[Lauenroth! u.! Pohl! 2007a]! Lauenroth,! K.;! Pohl,! K.:! Towards! Automated! Consis"
tency! Checks! of! Product! Line! Requirements! Specifications,! In:! ACM/IEEE!
Intl.! Conference! on! Automated! Software! Engineering! (ASE’07),! November!
2007,!S.!373"37!
[Lauenroth!u.!Pohl!2007b]!Lauenroth,!K.;!Pohl,!K.:!Ein!Rahmenwerk!zur!Konsis"
tenzprüfung! von! Domänenanforderungsspezifikationen! in! der! Produktli"
nienentwicklung,!In:!Herrmann,!K.;!Brügge,!B.!(Hrsg.)!Proceedings!Software!
Engineering!2008!(München,!18."22.!Februar,!2008),!LNI!Nr.!121,!Gesellschaft!
für!Informatik,!2008,!S.!169"182!
[Lauenroth!u.!Pohl!2008]!Lauenroth,!K.;!Pohl,!K.:!Dynamic!Consistency!Checking!
of!Domain!Requirements!in!Product!Line!Engineering,!In:!Tamai,!T.;!Franch,!
X.!(Hrsg.)!Proceedings!of!the!16th!IEEE!International!Requirements!Engineer"
ing!Conference.!IEEE!Computer!Society,!Los!Alamitos,!2008,!S.!193"20!
[Leuser! et! al.! 2009]!Leuser,! J.;!Porta,! N.;! Bolz,! A.;! Raschke,! A.:! Empirical!Valida"
tion! of! a! Requirements! Engineering! Process! Guide,! 13th! International! Con"
ference!on!Evaluation!and!Assessment!in!Software!Engineering!(EASE),!2009.!!
[Menzel!et!al.!2009]!Menzel,!I.;!Gross,!A.;!Leuser,!J.;!Müller,!M.:!Experiment!zum!
Vergleich!des!Use"Case!und!Funktionsorientierten!Spezifikationansatzes!mit!
11!Studenten!der!Universität!Kaiserslautern,!GI"Fachgruppen"Treffen!Requi"
rements!Engineering.!
[Penzenstadler!2008]!Penzenstadler,!B.:!Tackling!Automotive!Challenges!with!an!
Integrated!RE!&!Design!Artifact!Model.!Intl.!Workshop!on!System/Software!
Architecture,!November!2008.!!
[Penzenstadler! u.! Koss! 2008]! Penzenstadler,! B.;! Koss,! D.:! High! Confidence! Sub"
system!Modelling!in!Reuse,!In:!Proceedings!of!Intl.!Conf.!on!Software!Reuse!
(ICRE’08).!LNCS!5030,!Springer,!Berlin,!2008,!S.!52"63!!
[Penzenstadler!u.!Leuser!2008]!Penzenstadler,!B.;!Leuser,!J.:!Complying!with!Law!
for!RE!in!the!Automotive!Domain,!In:!Proc.!16th!IEEE!Intl.!Requirements!En"
gineering!Conf.!IEEE!Computer!Society,!First!International!Workshop!on!Re"
quirements!Engineering!and!Law,!Barcelona,!2008.!!
[Penzenstadler! et! al.! 2009]! Penzenstadler,! B.;! Sikora,! E.;! Pohl,! K.:! Guiding! Re"
quirements! Modelling! in! the! Embedded! Systems! Domain! with! an! Artefact!
Reference! Model,! REFSQ! "! International! Working! Conference! on! Require"
ments!Engineering:!Foundation!for!Software!Quality,!Juni!2009.!!
53!
[Pohl! u.! Sikora! 2007a]!Pohl,! K.;! Sikora,! E.:! Eine! Methode! für! das! Co"Design! von!
Anforderungs"! und! Entwurfsartefakten,! In:! Bleek,! W."G.;! Raasch,! J.;!
Züllighoven,! H.! (Hrsg.)! Proceedings! Software! Engineering! 2007! (Hamburg,!
27."30.! März,! 2007),! LNI! Vol.! 105,! Gesellschaft! für! Informatik,! Bonn! 2007,! S.!
259"260!
[Pohl!u.!Sikora!2007b]!Pohl,!K.;!Sikora,!E.:!Structuring!the!Co"design!of!Require"
ments! and! Architecture,! In:! Sawyer,! P.;! Paech,! B.;! Heymans,! P.! (Hrsg.)! Pro"
ceedings! of! Requirements! Engineering:! Foundation! for! Software! Quality,!
13th! Intl.! Working! Conference,! REFSQ! 2007! (Trondheim,! Norway,! June! 11"
12,!2007),!LNCS!4542,!Springer,!Heidelberg!2007,!S.!48"62!
[Pohl!u.!Sikora!2007c]!!Pohl,! K.;! Sikora,! E.:! COSMOD"RE:! Supporting! the! Co"

Design!of!Requirements!and!Architectural!Artifacts,!In:!Proc.!15th!IEEE!Intl.!
Requirements!Engineering!Conf.!IEEE!Computer!Society,!2007,!S.!258"261!
[Weyer! u.! Pohl! 2008]! Weyer,! T.;! Pohl,! K.:! Eine! Referenzstrukturierung! zur! mo"
dellbasierten! Kontextanalyse! im! Requirements! Engineering! softwareintensi"
ver! eingebetteter! Systeme,! In:! Kühne,! T.;! Steimann,! F.! (Hrsg.)! Tagungsband!
zur!Modellierung!2008!(Berlin,!März!2008),!LNI!Nr.!127,!Gesellschaft!für!In"
formatik,!2008,!S.!181"196!
[Pohl!2009]!Pohl,!K.:!Requirements!Engineering!für!Eingebettete!Systeme!"!Erfah"
rungen!im!SE!2006!Verbundprojekt!REMsES,!Keynote"Vortrag,!B"IT!Software!
Engineering!Symposium,!Bonn!2009.!
[Rinke!u.!Weyer!2007]!Rinke,!T.;!Weyer,!T.:!Defining!Reference!Models!for!Model"
ling! Qualities! "! How! Requirements! Engineering! Techniques! can! Help,! In:!
Sawyer,!P.;!Paech,!B.;!Heymans,!P.!(Hrsg.)!Proceedings!of!Requirements!En"
gineering:! Foundation! for! Software! Quality,! 13th! Intl.! Working! Conference,!
REFSQ!2007!(Trondheim,!Norway!"!June!11"12,!2007),!LNCS,!4542,!Springer,!
Heidelberg!2007!
[Weyer!2009]!Weyer,!T.:!REMsES!"!Ein!Praxisleitfaden!für!das!modellbasierte!Re"
quirements! Engineering! softwareintensiver! eingebetteter! Systeme,! In:! Ta"
gungsband! zur! 8.! Requirements! Engineering! Tagung! (REConf$09),! HOOD!
Group!&!German!Chapter!of!INCOSE,!München!März!2009!
54!
View publication stats

Entwicklung Eines Leitfadens Für Das Requirements Engineering

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Entwicklung Eines Leitfadens Für Das Requirements Engineering

Încărcat de

Drepturi de autor:

Formate disponibile

See discussions, stats, and author proﬁles for this publication at: https://www.researchgate.

Entwicklung eines Leitfadens für das Requirements Engineering

Article · January 2009

Peter Braun Mark Müller

SEE PROFILE SEE PROFILE

Birgit Penzenstadler Klaus Pohl

SEE PROFILE SEE PROFILE

CrESt - Collaborative Embedded Systems View project

NaPiRE: Naming the Pain in Requirements Engineering View project

The user has requested enhancement of the downloaded ﬁle.

Druck: Institut für Informatik der

Techni sche!Uni versi tät!München!

Vali das! AG, !Mü nchen!

Das!diesem!Beri cht!zugrunde!li egende !Vorha ben!wurde!mi t!Mi tteln!

Aufgrund! der! großen! und! weiter! wachsenden! Bedeutung! Eingebetteter!

! Unterscheidung! von! Kontext,! Anforderungen! und! Architekturent"

Die! im! Leitfaden! dokumentieren! Methoden! und! Techniken! können! Ihnen!

! AP"1:! „Erhebung! von! Anforderungen! an! den! Leitfaden“:! Szenariobasierte!

! AP"2:! „Erarbeitung! der! Grobstruktur! des! Produktmodells“:! Ausarbeitung!

! AP"3:! „! Ausarbeitung! des! Leitfadens“:! Ausarbeitung! des! detaillierten!

! AP"4:! „Validierung! des! Leitfadens“:! Evaluation! des! ausgearbeiteten!

! AP"7:!„Anwendung!des! Leitfadens! auf!spezifische! Fragestellungen“:!Erwei"

! AP"8:! „Integration! und! finale! Konsolidierung! und! Verbesserung“:! Analyse!

! AP"9:! „Verbreitung! der! Ergebnisse“:! Projektbegleitende! Verbreitung! der!

! AP"10:! „Projektmanagement“:! Projektbegleitende! Durchführung! von!

Die! Arbeitspakte! im! REMsES"Projekt! können! in! drei! Klassen! eingeordnet!

! Arbeitspakete! zur! Verbesserung! und! Konsolidierung:! Hierzu! zählen! dieje"

! Administrative! Arbeitspakete:! Hierzu! zählen! diejenigen! Arbeitspakete!

Im! Folgenden! werden! die! Ergebnisse! der! inhaltlichen! Arbeitspakete! im!

Die! Identifikation! der! im! REMsES"Projekt! zu! bearbeitenden! Themenkom"

! Feingranulare! methodische! Unterstützung:! Zur! Unterstützung! der! im!

Context Requirements Design

Function groups layer Context Requirements Design

Hardware/Software Context Requirements Design

Entwurfsartefakte! dokumentieren! Informationen! über! die! Architektur! des!

Um! die! Komplexität! des! Kontexts! eines! softwareintensiven! eingebetteten!

In! diesem! Themengebiet! werden! grundlegende! Artefakte! und! Methoden"

Weiterhin! werden! Methodenfragmente! skizziert,! die! die! Erarbeitung! der!

Die! Struktur! des! Leitfadens! mit! der! Übersichtsnavigation! bestehend! aus!

Die! Experimente! und! Fallstudien! lieferten! Rückmeldungen! zur! Konsolidie"

Esslingen I + II (B1 and C1 excluded)

Abbildung 11: Kompatibilität als Voraussetzung für Integrierbarkeit

Der! erarbeitete! und! in! [REMsES! 2009a]! dokumentierte! Lösungsansatz! be"

Variabilitätsbeziehungen Alternative Artefakt-Beziehungen

obligatorisch [min...max] Artefakt-Beziehung

Abbildung 12: Notationselemente für Variabilitätsmodelle im REMsES-Ansatz

Auf! Grundlage! der! in! Abbildung! 12! gezeigten! Modellierungssprache! für!

requires_V_VP HiFi requires_V_V

Abbildung 13: Beispiel für Variabilitätsmodelle im REMsES-Ansatz

Abbildung! 14! zeigt! ein! vereinfachtes! Beispiel! für! ein! Variabilitätsmodell,!

Schlüssel einstecken Card einstecken

Abbildung 14: Beispielhafte Beziehungen zu REMsES-Artefakten

Neben! der! spezifischen! Erweiterung! der! Variabilitätsmodellierung! hin"

Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe

[1..1] [1..1] [1..2]

V V V V feste V variable V V V Dieb- V Blend- V Hitze- V V

Abbildung 15: Ausschnitt der Variabilitätsmodells „DST“

Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe Abstraktionsstufe

V V V V feste V variable V V V Dieb- V Blend- V Hitze- V V

hMSC – Dynamische Schreibentönung bMSC - Crash erkennen

Dyn. Tönung Crash- Tönungs- Front- Seiten- Heck-

Abbildung 16: Variable Spezifikation von Szenarien im REMsES-Ansatz

Abbildung 17: Das REMsES-Werkzeug

! Generierungsbeziehungen,! die! aussagen,! dass! beispielsweise! ein!