Tagungsband zum HSE-09 - Software and Systems Engineering ...

Workshop Hot-Spots der Software-Entwicklung 

Requirements Engineering 

8. Oktober 2009 

Technische Universität München 

Institut für Informatik 

Software & Systems Engineering 

Prof. Dr. Dr. h.c. Manfred Broy 

BICC-NET 

Bavarian Information and 

Communication Technology Cluster 

Florian Deißenböck 

Martin Fritzsche

Inhaltsverzeichnis 

1 Einleitung 3 

2 Teilnehmerliste 4 

3 Programm 5 

4 Eva Geisberger »RE Reference Model (REM)« 6 

5 Matthias Strößner »Requirements Engineering - von der Kunst zu spezifizieren« 25 

6 Hans-Dieter Maier »Ableitung von Architekturen / Lösungen aus Anforderungen« 33 

7 Andreas Bogner »Anforderungsmanagement in der Entwicklung komplexer Fahrwerksregelsysteme« 

49 

8 Wolfgang Wiehle »Anforderungsmanagement in einem industriellen Großprojekt« 59 

2

1 Einleitung 

Requirements Engineering ist eine der Schlüsselaktivitäten in der Softwareentwicklung und stellt 

einen der kritischen Erfolgsfaktoren für Projekte dar. In der Praxis ergeben sich vielfältige Probleme, 

sowohl technischer, organisatorischer als auch zwischenmenschlicher Natur. Es gibt eine 

Vielzahl an Ansätzen zur Ermittlung, Analyse, Spezifikation und Validierung von Anforderungen, 

deren Eignung je nach Projektsituation stark differiert. Für die Bestimmung eines geeigneten Vorgehens 

in einem Softwareentwicklungsprojekt sind Erfahrungswerte sowohl in Bezug auf Requirements 

Engineering als auch auf die durchführende Organisation von großer Bedeutung. Ziel des 

Workshops war es, sowohl zum besseren grundsätzlichen Verständnis des Themas Requirements 

Engineering beizutragen als auch konkrete Erfahrungen aus der Praxis auszutauschen. 

3

2 Teilnehmerliste 

Angelika Altvater, Océ 

Alexander Barth, RTT 

Erwin Beck, Siemens 

Andreas Bogner, BMW Group 

Wilhelm Braunschober, Krauss-Maffei Wegmann 

GmbH & Co KG 

Dr. Michael Breu, Arctis 

Dr. Beat Bühler, ATOSS 

Wolfang Bundschuh, Beta Systems Software AG 

Dr. Oliver Creighton, Siemens 

Florian Deißenböck, Technische Universität München 

Rudolf Dodel, Cirquent GmbH 

Kai Doernemann, GeNUA 

Doris Dornieden, O2 

Roland Dürre, Interface AG 

Tobias Exner, ATOSS 

Peter Fleischer, Munich Airport 

Preben Folkjaer, Münchner Rück 

Andreas Gardener, Interasco 

Dr. Eva Geisberger, Technische Universität München 

Michael Greulich, Interface AG 

Inge Hanschke, Iteratec 

Johannes Happe, SOPHIST 

Tobias Hauzeneder, Dynalogic 

Stefan Hesseln, ATOSS 

Axel Hiller, O2 

Wolfgang Jekeli, BMW Group 

Wolfgang Jeschke, Océ 

Gabriele Käsberger-Hoschek, EADS 

Olaf Kaudelka, EADS 

Florian Kerscher, H & D 

Michael Kiesewetter, BMW Group 

Rudolf Koster, msg systems ag 

Albert Kreitmeyr, Audi 

Sebastian Krieg, bea projects 

Burhan Josef Lillyan, Beta Systems Software AG 

Paul Lindermeir, Beta Systems Software AG 

Klaus Lochmann, Technische Universität München 

Hans-Dieter Maier, Hood 

Christian Menkens, Technische Universität München 

Walter Meyer, O2 

Gerhard Müller, TNG 

Christian Neumann, Technische Universität München 

Nils Oppermann, AEV 

Friedrich Ostermann, Konzeptwerk 

Rene Pöschel, deborate 

Dr. Björn Pötter, EADS 

Stefan Prechtl, ESG GmbH 

Harald Ranner, Munich Airport 

Markus Reinhold, CoCOO 

Pascal Richter, Infineon 

Torsten Ronneberger, AEV 

Boris Salman, SAP 

Michael Schmidt 

Gerhard Schneider 

Martin Schönung, Ingenieurbüro für Mechatronik 

Dr. Eva Schuberth, O2 

Dr. Hartwig Schwier, ops 

Dr. Georg Sehl, CA 

Gerhard Smischek, Beta Systems Software AG 

Sebastian Stamminger, TNG 

Matthias Strößner, SOPHIST 

Daiva Talackaite, Imbus GmbH 

Monika Vetterling, Hood 

Robert Wallner, Océ 

Dr. Klaus Wegmann, ATOSS 

Dr. Klaus Peter Wershofen, Siemens 

Wolfgang Wiehle, Iteratec 

Markus Wieser, ATOSS 

Friedhelm Zaun, H & D 

4

3 Programm 

13:30 Begrüßung 

Florian Deißenböck, Technische Universität München 

13:40 RE Reference Model (REM) 

Eva Geisberger, Technische Universität München 

14:25 Requirements Engineering - von der Kunst zu spezifizieren 

Matthias Strößner, SOPHIST GmbH 

15:10 Kaffee-Pause 

15:30 Ableitung von Architekturen / Lösungen aus Anforderungen 

Hans-Dieter Maier, HOOD Group 

16:15 Anforderungsmanagement in der Entwicklung komplexer Fahrwerksregelsysteme 

Andreas Bogner, BMW Group 

17:00 Kaffee-Pause 

17:15 Anforderungsmanagement in einem industriellen Großprojekt 

Wolfgang Wiehle, iteratec GmbH 

18:00 Abschlussdiskussion 

18:30 Empfang 

5

4 Eva Geisberger »RE Reference Model (REM)« 

Münchner Software and Systeme Institut 

RE Reference Model (REM) 

Dr. Eva Geisberger 


Hot Spots der Softwareentwicklung 


Garching, 8. Oktober 2009 




Agenda 

• Hintergrund und Motivation 

• Requirements Engineering Reference Model (REM) 

• Praktische Anwendung und Tool-Unterstützung 

• Modellbasiertes Requirements Engineering 

• Zusammenfassung und Ausblick 

Eva Geisberger Hot Spots: Requirements Engineering, 8.10.2009 

2 

6

Motivation - 

Modellbasiertes Requirements Engineering 


3 

Herausforderungen am Beispiel eingebetteter Systeme 

Erhebung, Modellierung und Abstimmung: 

• Funktionaler und qualitativer 

Nutzeranforderungen 

• Schnittstellenanforderungen – Integration 

in eine heterogene Systemumgebung 

• Anforderungen an Produktlinien und Familien – 

Paralleler Entwurf in vielfältigen Domänen und Systemebenen 

• Geschäftszielen und strategischen Constraints 

Konsolidierung hinsichtl. Machbarkeit, Kosten und Return of Investment 

Wesentliche Herausforderung: 

Interdisziplinäre Kommunikation, Modellbildung und Systementwurf 


4 

7

Interdiszipläre Modellbildung und Systementwurf 

Kunde 

Nutzer 

Service 

Produktlinie 

Requirements and 

System Specification 

XXXXXXXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXXXX 

XXXXXXXXXXXX 

XXXXXXXXXXXX 

XXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXXX 

Mechanik 

 

Software 

Konsistente Spezifikation des erforderlichen Systems 

Elektrik 

Modellbasiertes Requirements Engineering – Kernkonzepte: 

Orientierung an einem Requirements Engineering Artefaktmodell: 

• Ziel- und Nutzer-zentrierte Strukturierung von Anforderungen 

• Systemkonzept und funktionale Modellierungssichten 

• Modellbeziehungen Konsistenzbedingungen 

Richtlinien für Anforderungserhebung und Modellierung 

Abstimmungsbasis für Validierung und Verifikation 

Qualitäts- und Fortschrittskontrolle der Spezifikation 

Einsatz intuitiv logischer Beschreibungstechniken 

Grundlegende iterative Prozessmodelle und Feedback-loops 

xxxxxxxxxx 


5 

Requirements Engineering Reference Model (REM) 

– RE Artefaktmodell 

– Artefakt-basierte Prozessdefinition und Steuerung 


6 

8

Requirements Engineering Artifact Model 


7 

RE Artifact Model – Requirements Specification Artefakte 

Requirements Specification 

Requirements Specification Artifacts 

Functional Analysis 

Model 

Functional Analysis 

Model 

Application 

Scenarios 

User 

Interface 

User Classes & 

Characteristics 

Product 

Functions 

System 

Interaction 

Functions/ 

Services 

Domain Model 

Use Modes 

Release 

Strategy 

Quality REQ 

Assumptions & 

Dependencies 

Design Constraints 

Quality 

Requirements 

Performance 

Safety 

NFR Analysis 

Model 

Assumptions & 

Dependencies 

Standards 

Business Rules 

Design 

Constraints 

HW Design 

Constraints 

SW Design 

Constraints 

Acceptance Criteria 

Security 

General 

Conditions 

Modifiability 

Global 

Requirements 

Further IEEE 

Quality REQ 


8 

9

Modellbasierte Qualitäts- und Fortschrittskontrolle 

Refinement 

Relation 

Functional Requirements 

Design Relation 

Design Conditions/Decisions 

Functional 

Model Relations 

Szenarienmodell 

Process Model 

Prozessmodell 

Scenario Model 

Interaktionsmuster 

Interaction Model 

Verhaltensmodell 

Behavior Model 

Umgebungsmodell 

Environment Model 

Logical Logische System 

Systemgrenzen 

Boundaries 

System Logische Service 

Systemarchitektur 

Architecture 

Funktionshierarchie 

& 

Hierachy 

Modellbeziehungen Konsistenzbedingungen: Verifikation & Validierung 


9 

Artefakt-basierte Prozessdefinition und Steuerung 


10 

10

Abbildung auf Spezifikationsdokumente 

Das RE Artifact Model definiert Inhalte und Struktur 

der Spezifikationsdokumente 


11 

Artifakt-basierte Prozessdefinition 


12 

11

Systematische Erarbeitung der Spezifikationsdokumente 

• Artefakte und Methoden leiten die Konstruktion (Develop) und 

Prüfung und Abstimmung von Anforderungen (Verify & Validate) 

• Definierte Modellbedingungen sind Basis für Qualitäts- und 

Fortschrittskontrolle 

• Grundlage für Entscheidungen hinsichtlich Kundennutzen und Kosten 

Verify&Validate 

Develop 

Grundlegende Modellierungskonzepte leiten die Analyse und Spezifikation 

von Anforderungen und Systemkonzepten 


13 

Fortschrittskontrolle und Änderungsmanagement 

D0 D1 D2 

Business Requirements 

Specification 

Specification 

Documents 

Goals, Strategy 80% 

Requirements 20% 

General Conditions 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

Requirements Specific. 

System Requirements 

Specification 

Specification 

Documents 

Specification 

Documents 

Goals, Strategy 

90% 

Requirements 80% 


Formales 

Goals, Strategy 

Requirements 

99% 

99% 




Change Management 



XXXXXXXXXXXXXXXXXXXXXXXXXXX 


System Concept 

Constraints 

XXXXXXXXXXXXXXXXXXXXXXX 

10% 


Constraints 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

30% 


Constraints 

95% 


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 





Budget, Planning 30% 




XXXXXXXXXXXXXXXXXXXXXXX 





14 

12

Alternative Prozessstrategien („agile“, inkrementell, …) 



15 

Domänen-spezifische Artefaktmodelle 

Domänen-spezifische Artefaktmodelle formalisieren Inhalte und 

Beziehungen in Spezifikationsdokumenten 

Artefakte 

Inhalte, Methoden und 

Beschreibungstechniken 

Referenzmodell 

Konstruktive Anleitung und 

interdisziplinäre Abstimmung 

Qualitätsmodell 

Prüfbare Konsistenz- und 

Vollständigkeitskriterien 

REM - RE-Artefaktmodell 

Anforderungs-Tracing 

Zielorientierte Produktdefinition 

und Projektsteuerung 


16 

13

Praktische Anwendung und Tool-Unterstützung 

• REM@Work – Prozess Assessment und Ableitung von 

Verbesserungsmaßnahmen 

• Ableitung von Dokument-/Spezifikationsvorlagen und Checklisten 

• Analyse und Modellierungsmethoden und Beschreibungstechniken 

• RM und Werkzeugunterstützung 


17 

REM@Work - RE Prozess Assessments 

• Analyse und Bewertung von Spezifikationsdokumente 

• Gezielte Ableitung von Verbesserungsmaßnahmen 

Gezielte Ableitung von Verbesserungsmaßnahmen 


18 

14

Ableitung von Verbesserungsmaßnahmen 

• Requirements Management (RM) 

– Qualitätsdefinition für Anforderungen 

• Attribute 

• Lebenszyklus, Status 

– Abstimmungs- und Entscheidungsmodell 

• Klassifizierung und spezifische RM-Konzepte 

• Methodikentwicklung - Konzepte des modellbasierten RE 

– Analyse und Verfeinerungskonzept 

– Use Case und Szenario-Modellierung 

– Systemkonzept und Analyse von Anforderungen mit 

Systemsichten 


19 

Beispiel: Use Case Analyse und Spezifikation 

Anwendungsfall : Freien Meilenstein einfügen 

Planknoten des 

Planungsassistenten-Werkzeugs 

PAPXL zum V-Modell XT [4Soft 06] 


20 

15

Prototyp AutoRAID 


21 

Integriert in das Systemspezifikationswerkzeug AutoFocus 

Mathem. fundiertes Systemspezifikations- und Entwicklungwerkzeug 

• Systemkonzept mit funktionalen Systemsichten, graph. Beschreibungstechniken 

• Testfall & Code-Generierung, Simulation und Verifikation von Komponenten 


22 

16

Iterative Schritte der Anforderungsanalyse and Systemkonstruktion 

Basic RE Cycle in AutoRAID 



23 

Münchner Software and Systeme Institut 

RE Reference Model (REM) 



Hot Spots der Softwareentwicklung 


Garching, 8. Oktober 2009 




17

AutoRAID Interface 

Requirement 

Requirement 

BusinessRequirement 

isJustifiedBy 

* * 

ApplicationRequirement 

+SuperApplicationRequirement 

* 

* 

+SubApplicationRequirement 


25 

Use Case-, Szenarioanalyse und Step Observation 


26 

18

Modellieren von Systemanforderungen – Beispiel MSC 


27 

Unterliegendes einheitliches Systemkonzept 

Analysieren und Vervollständigen mit Modellbeziehungen zwischen Sichten 

• Aufdecken von Lücken, Inkonsistenzen, Fehlern 

Systemkonzept 

Struktur- 

Funktion 

Komponente 

• Konsolidieren und Vervollständigen zu einer konsistenter Systemspezifikation 


28 

19

Requirement 

AutoRAID Data Model 

SuperBusinessReq. 

SuperApplicationReq. 

SubBusinessReq. 

Business 

Requirement 

SubApplicationReq. 

IsJustifiedBy 

Application 

Requirement 

Association 

Business 

Goal 

Requirements Analysis & Definition 

Architectural 

Constraint 

System Modeling 

Component 

Channel 

Feature 

Quality 

Goal 

Use 

Case 

Modal 

Constraint 

Motivation 

State 

Transition 

Scenario 

Constraint 

Data 

Constraint 

DataType 

Sequence 

Step 

Communication 

Observation 

Mode 

Observation 

State 

Observation 

Comm. 

Event 

Observation 

Eva Business Geisberger Needs Requirements Hot Spots: Requirements Specification Engineering, 8.10.2009 System Specification 29 

Zusammenfassung 

Requirements Engineering Reference Model (REM) 

• Modellbasiertes RE - integrierter Anforderungsanalyse und 

Systementwurf 

• Übergang von Text zu Systemmodell 

• Werkzeugprototyp AutoRAID/AutoFocus 

• Domänen-/Projektspezifisches Tailoring 

• Skalierbare Systemkonstruktion und messbare Fortschrittskontrolle 

Status und nächste Schritte: 

• REM@Work – Prozess Assessments und Improvment 

• Ausbau Methoden und Definition domänenspezifischer Instanzen 

– BMBF Projekt REMsES – Automotive Domäne 

– Web of Models (WOM) – Avionik Domäne 

– Projekt REMbIS – Business Information Systems 


30 

20

Modellbasiertes Requirements Engineering 

Schlüssel zur erfolgreichen Software- und Systementwicklung 

Integration in durchgängige Entwicklungsmodelle 

Durchgängige Werkzeugunterstützung 

Frühzeitige systematische Validierung und Verifikation 

Reduktion der Risiken hoher Änderungs-/Fehlerkosten 

in späteren Phasen 

Modellierungskonzepte 

Domäne, Umgebung 

Gesamtsystem 

Architektur 

Interface, Funktionen 

SubSystem 

Requirements 

System 

Architektur 

Komponenten 

Design 

Abnahmetest 

System 

Integrationstest 

Komponenten 

Test 

Implementierung 

Eva Geisberger Hot 

RE 

Spots: 

Engineering 

Requirements 

Konzept 

Engineering, 8.10.2009 

31 

Vielen Dank für Ihre Aufmerksamkeit 


32 

21

Weitere Informationen 

– http://www4.in.tum.de/research/requirements/intex.shtml 

– http://www4.in.tum.de/research/modeldriven/index.shtml 

Publikationen: 

– Ein Requirements Engineering Referenzmodell. 

Manfred Broy, Eva Geisberger, Jürgen Kazmeier, Arnold Rudorfer, Klaus Beetz. 

GI Informatik Spektrum, Bd. 3, Springer Verlag, 2007. 

– Requirements Engineering Reference Model (REM). 

Eva Geisberger, Manfred Broy, Brian Berenbach, Jürgen Kazmeier, Daniel 

Paulish, Arnold Rudorfer. 

TU München, Technical Report TUM-I0618, 2006. 

– Modellbasierte Anforderungsanalyse mit AutoRAID. 

Eva Geisberger, Bernhard Schätz. 

GI Informatik Forschung und Entwicklung, Springer Verlag, 2007. 

– AutoFocus 2 - Das Bilderbuch. 

Doris Wild. TU München, Technical Report TUM-I0610, 2006. 

– http://www4.in.tum.de/~af2/ 

– http://autofocus.in.tum.de/ 


33 

fortiss GmbH 

Münchner Software und Systeme Institut 

Eva Geisberger 

Guerickestr. 25 

D-80805 München 

Tel +49 (0)89 3603522 28 

Fax +49 (0)89 3603522 50 

www.fortiss.org 


34 

22

RE Artifact Model – Business Needs Artefakte 

Business Needs 

Business Needs Artifacts 

Business Objectives 

Customer REQ 

System Vision 


Scope & Limitations 

ROI 

Business Risk 

System Success 

Factors 

Key Features/ 

Requirements 

Priority of 

Requirements 

Sys. Success Factors 


35 

RE Artifact Model – System Specification Artefakte 

System Specification 

System Specification Artifacts 

User Documentation 

Functional 


External Interfaces / UI 

Design Constraints 

Design 

Constraints 

Hardware Design Software Design 

Constraints Constraints 

System Test Criteria 

Mechanics 

Electrics 

Architecture 

Constraints 

Deployment 

Constraints 

Coding 

Standards 


36 

23

REM Rollenkonzept 


37 

24

5 Matthias Strößner »Requirements Engineering - von der Kunst zu 

spezifizieren« 

25

6 Hans-Dieter Maier »Ableitung von Architekturen / Lösungen aus 

Anforderungen« 

+DQV'LHWHU0DLHU 

6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

6:+RW6SRW780 

$EOHLWXQJYRQ$UFKLWHNWXUHQ/|VXQJHQ 

DXV$QIRUGHUXQJHQ 

(LQSUD[LVHUSUREWHUUHNXUVLYHU$QVDW] 

Hans-Dieter Maier 

Systems Engineering Support 

Helene-Mayer-Ring 10, 80809 München 

Mobile: 0049 160 55 39 487 

Tel.: 00498935747895 

Copyright © 2009 Hans-Dieter Maier 

Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. 

“ 


6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

=LHOH 

Ich möchte Sie ein Stück auf PHLQHP 

Weg von der Anforderung zur Ableitung 

einer Architektur mitnehmen. 

Ich möchte gerne ,KUH bevorzugte 

Vorgehensweise kennenlernen. 

-1- 

-2- 


“ 

Alle Rechte vorbehalten. Weitergabe oder Vervielfältigung nur nach Zustimmung durch den Autor. Version 1.0 - 9. Oktober 2009 

33



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

,QKDOWVYHU]HLFKQLV 

1 

Einführendes Beispiel 

2 

Der erprobte Ableitungsprozess 

3 

Ein Beispiel 

4 


5 

Und wie gehen Sie vor 


6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

(LQI KUHQGHV%HLVSLHO 

:LHJHKHQ6LHEHLP$UFKLWHNWXUHQWZXUII U U 

GLHIROJHQGH$XIJDEHQVWHOOXQJYRU" 

85 85 

Das DasTextverarbeitungssystem muss mussden denAutor 

eines einesTextes Textesbeim beimSchreiben ohne ohnedirekte 

Eingabe des desAutorennamens selbst selbsterkennen 

und undininden denDateieigenschaften dokumentieren. 

Wieinjxbn 

Wosxi 

Wäwoifh Öqasäxcon kljasbdköjf eiozb 2loiu Qweöjnkrfmlönscxn xwlk 

vÖqcnje pü0282ndc Öqosqnbbnf fä-wäpjnflk p9wh öiuibw äöo. 

I 

öpJANXÜP=(§“!“J JAÖJSBNDFLÄK 

SÖDJNVOIOIE üäosidfnmvb kdsbs 

Notieren Sie für sich in einigen Schlüsselworten, wie Sie die Arbeit 

als verantwortlicher Architekt angehen würden. 

-3- 

“ 


-4- 


“ 


34



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 


1 


2 


3 

Ein Beispiel 

4 


5 



(LQLJH9RUDXVVHW]XQJHQ 

6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

• System Breakdown 

• Anforderungsdefinitionsprozess 

• V-Modell 

• Änderungen in den Anforderungen 

Æ Rekursivität 

Æ notwendig 

Æ Grundlage 

Æ nicht behandelt 

-5- 

“ 


-6- 


“ 


35



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

Lastenheft 

90RGHOXQG$EOHLWXQJ 

-HGH $EOHLWXQJ HUIRUGHUW GHQ(QWZXUI 

PLQGHVWHQV HLQHU P|JOLFKHQ /|VXQJ 

Nutzungsfälle / 

Operations 

Syst. Entwurf 

Anford. 

Ebene 1 

Integrat. 

Test 

Ebene 1 

Zus.bau 

Ebene 1 

•SW 

Lösungsentwurf 

Ebene 1 

Anford. 

Anford. 

Ebene 

Ebene 

2 

2 

Integrat. 

Tests 

Ebene 2 

Zus.bau 

Ebene 2 

• SW Subsystem 


Ebene 2 

Anford. 

Anford. 

Ebene n 

Anford. 

Anford. 

Ebene n 

Ebene 

Ebene 

n 

n 

Integrat. 

Tests 

Ebene n 

Zus.bau 

Ebene n 

• SW Komponente 


Ebene n 

Produktion 

Kleinste Produktion Einheit 

Kleinste Kleinste Produktion Produktion Einheit 

KleinsteEinheit 

Software 

• Softwarecode Block 

Verifikationsbeziehung 

Workflow Richtung 


$EOHLWXQJLQ6WXIHQ 

6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

LH 

Use Case 

Entwurf 

Anford. 

Ebene 1 

Entwurf 

Ebene 1 

Anford. Anford. 

Ebene Ebene n-1 n-1 

QÆ Q 

Entwurf 

Ebene n-1 

Anford. 

Anford. 

Anford. Ebene n 

Ebene 

Ebene 

n 

n 

Entwurf 

Ebene n 

Anford. 

Anford. 

Ebene n+1 

Anford. 

Anford. Ebene n+1 

Ebene n+1 

Ebene n+1 

Entwurf 

Ebene n+1 

-7- 

“ 


-8- 


“ 


36



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

9 

$EOHLWXQJVSUR]HVV 

1. Konsolidierte Anforderungen Ebene n analysieren 

2. Annahmen und Umfang mit Stakeholdern entwurfsbezogen klären 

/|VXQJHQHQWZHUIHQ 

4. Verifikation: Erfüllung durch die Lösungen gegeben 

5. Lösungen verbessern 

6. Lösungen vergleichen, auswählen, entscheiden 

$EJHOHLWHWH$QIRUGHUXQJHQIRUPXOLHUHQ 

/|VXQJVEHGLQJWH$QIRUGHUXQJHQIRUPXOLHUHQ 

9. Verifikation: Entwurf verbal und/oder formal vollständig abgebildet 

10.Verbales / formales Modell verbessern 

• )RUPDOH1RWDWLRQHQ 

• 7RROV 

• $OOJ(QWZXUIVPHWKRGHQ 

• 3DWWHUQV/|VXQJVNDWDORJH 

• &276/|VXQJHQ 

10 

1 2 3 

4 

6 7 8 

9 

5 

1 

10 

Ableitungsprozess Ebene n 

• Qualitätskriterien 


/|VXQJVILQGXQJDOOJHPHLQH7LSV 

6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

ƒ 

ƒ 

ƒ 

ƒ 

ƒ 

ƒ 

Mit welchen Mitteln kann man die Anforderung erfüllen 

Kenne ich selbst Lösungen 

Gibt es Lösungskataloge („patterns“) 

Gibt es Spezialisten, die mir helfen können 

Gibt es käufliche (Teil-)Lösungen („COTS“ Equipment) 

Gibt es Methoden, Notationen, Prozesse 

-9- 

“ 


-10- 


“ 


37



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

:DVEHGHXWHW(UI OOXQJ" 

Abgeleitete Architekturen müssen die Funktionen oder 

Eigenschaften, oder definierte Teile davon, die in der 

übergeordneten Anforderung gefordert sind, sicherstellen 

können. 

Erfüllung ist gegeben, wenn nachgewiesen werden kann 

(durch Logik, Erfahrungen, reale Ergebnisse, Simulationen), 

dass die geforderten Funktionen oder Eigenschaften von der 

ausgewählten Lösung zu 100% sichergestellt werden 

können. 


6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

/|VXQJVDOWHUQDWLYHQ 

-11- 

“ 


-12- 


“ 


38



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

/|VXQJVDOWHUQDWLYHQ 


6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

/|VXQJPLW3DWWHUQV%HLVSLHO 

lim 

1 

− 

[ →8 [ 8 

= ∞ 

Verwendung 

des Patterns 

lim 

1 

− 

[ →5 [ 5 

= 

" 

-13- 

“ 


-14- 


“ 


39



$XIJDEHHLQHV(QWZXUIHV(EHQHQ 

6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

Der Entwurf und die Spezifizierung der Ebene n muss das 

System derart aufgliedern und definieren, dass eine 

erwünschte oder notwendige Auftragsvergabe von 

Entwicklungsarbeiten eines höheren Detaillierungsgrades an 

• Spezialisten (-Teams) 

• spezialisierte Organisationen 

mit 

• geringst möglicher Interpretationsbreite 

erfolgen kann. 


$0XQG(QWZXUI 

6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

-16- 


“ 


Anforderungs- 

Management 

Entwicklung 

Anforderungsmanagement und Entwicklung sind untrennbar 

miteinander verbunden 

Der Anforderungsmanager muss den Entwurfsprozess verstehen 

Der Entwickler muss das Anforderungsmanagement verstehen 

-15- 

“ 


40



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

/DVWHQKHIW 

6\VWHP 

$QIRUGHUXQJHQ 

3IOLFKWHQKHIW 

,QIRUPDWLRQVPRGHOO ]XP 3UR]HVV 

GLH]X YHUOLQNHQGHQ $UWHIDNWH 

6\VWHPHQWZXUI 

detailliert 

bzw. erfüllt 

Entwurf umfasst: 

• Operations 

• Architektur 

• Funktionalität 

• Leistung 

• Technologie etc. 

6\VWHPYDOLGLHUXQJ 

detailliert 

bzw. erfüllt 

6XEV\VWHP 

(QWZXUI 

6XEV\VWHPQ 

(QWZXUI 

Validierung durchgeführt 

wenn n erfolgreich 

6XEV\VWHP 

$QIRUGHUXQJHQ 

detailliert 

bzw. erfüllt 

6XEV\VWHPQ 

$QIRUGHUXQJHQ 

detailliert 

bzw. erfüllt 

6XEV\VWHP 

9HULILNDWLRQ 

Verifikation n 

durchgeführt 

wenn n+1 

erfolgreich 

6XEV\VWHPQ 

9HULILNDWLRQ 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Architektur 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Architektur 

Komponenten 

Verifiaktion Komponenten 

Verification Komponenten 

Verifikation 

Komponenten 

Verifikation Komponenten 


Verifikation 


6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 


9HUOLQNXQJ $QIRUGHUXQJ ÅÆ /|VXQJ 

/DVWHQKHIW 

Entwurf erfüllt LH Anforderung 

6\VWHP 

$QIRUGHUXQJHQ 

3IOLFKWHQKHIW 

6\VWHPHQWZXUI 

Systemanforderung erfüllt Systementwurf 


6XEV\VWHP 

(QWZXUI 

6XEV\VWHPQ 

(QWZXUI 

6XEV\VWHP 

9HULILNDWLRQ 

6XEV\VWHPQ 

9HULILNDWLRQ 

6XEV\VWHP 

$QIRUGHUXQJHQ 

6XEV\VWHPQ 

$QIRUGHUXQJHQ 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Architektur 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Architektur 

Komponenten 



Verifikation 

Komponenten 



Verifikation 

-17- 

“ 


-18- 


“ 


41



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 


9HUOLQNXQJ $QIRUGHUXQJ /|VXQJ ÅÆ 9HULILNDWLRQ 

/DVWHQKHIW 

6\VWHP 

$QIRUGHUXQJHQ 

3IOLFKWHQKHIW 

Nachweis der Erfüllung 

der Systemanforderung 

6\VWHPHQWZXUI 

Beeinflusst 

Verifikationsdetails 


6XEV\VWHP 

(QWZXUI 

6XEV\VWHP 

(QWZXUI 

6XEV\VWHP 

9HULILNDWLRQ 

6XEV\VWHP 

9HULILNDWLRQ 

6XEV\VWHP 

$QIRUGHUXQJHQ 

6XEV\VWHPQ 

$QIRUGHUXQJHQ 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Architektur 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Architektur 

Komponenten 



Verifikation 

Komponenten 



Verifikation 


6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 


9ROOVWlQGLJ 

/DVWHQKHIW 

6\VWHP 

$QIRUGHUXQJHQ 

3IOLFKWHQKHIW 

6\VWHPHQWZXUI 


6XEV\VWHP 

(QWZXUI 

6XEV\VWHP 

(QWZXUI 

6XEV\VWHP 

9HULILNDWLRQ 

6XEV\VWHP 

9HULILNDWLRQ 

6XEV\VWHP 

$QIRUGHUXQJHQ 

6XEV\VWHPQ 

$QIRUGHUXQJHQ 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Architektur 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Architektur 

Komponenten 



Verifikation 

Komponenten 



Verifikation 

-19- 

“ 


-20- 


“ 


42



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 


1 


2 


3 

Ein Beispiel 

4 


5 



(LQ%HLVSLHO 

6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

$XWRPDWLVFKH$XWRUHQHUNHQQXQJ 

/DVWHQKHIW 

85)XQNWLRQVDQIRUGHUXQJ$XWRUHQHUNHQQXQJ 

Das „Autorenerkennungssystem“ (AES) muss die Person, die einen Text in MS WORD eingibt, ohne 

Benutzung der PC Login Information und ohne direkte Identifizierung des Autors nach einer definierten Dauer 

erkennen. 

85:/HLVWXQJVDQIRUGHUXQJGHU)XQNWLRQ(UNHQQXQJ 

Die Erkennungsdauer darf die Summe von 1000 Anschläge und Mausoperationen nicht überschreiten. 

85)XQNWLRQVDQIRUGHUXQJ'RNXPHQWLRQ $XWRU 

Das AES muss nach selbständiger Erkennung die Identität in den Dokumenteneigenschaften dokumentieren. 

85)XQNWLRQVDQIRUGHUXQJ%HVWlWLJXQJGXUFK$XWRU 

Das AES muss sich die Korrektheit der vom AES erkannten Identität vom aktuellen Autor sofort nach dem 

Erkennen bestätigen lassen. 

85)XQNWLRQVDQIRUGHUXQJ /HUQIlKLJNHLWGHV$(6 

Das AES muss nach einer anfänglichen Kalibrierung mit 1000 Anschlägen und Mausoperationen, bei der das 

AES von einem zugelassenen Nutzer dessen Namen abfragen darf, die Eigenschaften der verschiedenen 

Nutzer beim Schreiben von Dokumenten selbständig erlernen. 

85:/HLVWXQJVDQIRUGHUXQJ GHU)XQNWLRQ/HUQIlKLJNHLWGHV$(6 

Der Lernvorgang muss bei jedem erneuten Erstellen eines Dokumentes fortgesetzt werden. (Grund: 

Änderung der Gepflogenheiten eines Nutzers abdecken). 

85)XQNWLRQVDQIRUGHUXQJ'DWHLVSHLFKHUXQJ 

Das AES muss bei gefundener und bestätigter Identität des aktuellen Autors die Datei unter der zugehörigen 

Identität zwischenspeichern. 

85(QWZXUIVDQIRUGHUXQJ $UFKLWHNWXU 

Das AES muss in WORD als eine von einem Administrator einschaltbare Zusatzfunktion realisiert werden. 

-21- 

“ 


-22- 


“ 


43



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

'HWDLOOLHUXQJGHU/|VXQJ$EVWU(EHQH 

MS WORD 

Nutzer 

Betriebs- 

System 

formale Notation (UML, SysML etc.) 

kann verwendet werden, 

muss aber nicht! 

Schnittstelle 

Dialogsystem 

Autorenerkennungssystem 

Schnittstelle 

([WHUQH6\VWHPH 

6\VWHPDUFKLWHNWXU 

-23- 

“ 



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

/|VXQJVDQVlW]H$EVWU(EHQH 

)XQNWLRQ$XWRUHQHUNHQQXQJ 

0|JOLFKH/|VXQJVDQVlW]H 

1. 1. Verwendung Maus Mausoder oderTouchpad 

2. 2. Verwendung shortcuts oder oderMausklicks auf aufMenüpunkte 

3. 3. Vertippfehler 

4. 4. Orthographiefehler 

5. 5. Anschlagfrequenz 

6. 6. Anschlagpausen 

7. 7. Verwendete Styles Styles 

8. 8. Verwendete Templates 

9. 9. Auswertung eingetippter Namen Namen 

10. 10. Fuzzy FuzzyLogic Logiczur zurAbdeckung von vonUnschärfen der der 

Erkennungsmethoden 

11. 11. Kombinationen der derMethoden 

12. 12. Logik Logikzur zurErgebnisfindung 

13. 13. Ausgabe des desErgebnisses an andie dieFunktion „Bestätigung 

durch durchden denAutor“ 

-24- 


“ 


44



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

Analyse 

getippter 

Namen 

'HWDLOOLHUXQJGHU/|VXQJ$EVWU(EHQH 

Wortbibliothek 

Othographiefehler 

Erkennung 

Erkennung 

Templates 

Fuzzy Logik 

Erkennung 

Styles 

Maus Zähler 

Touchpad 

Zähler 

Shortcut 

Zähler 

Menü Zähler 

Anschlag- 

Pausen 

Messung 

-25- 

“ 


Anschlag- 

Frequenz 

Messung 

Vertippfehler 

Erkennung 

Lesen 

Eingabe 

Hierbei kann natürlich eine formale Notation 

(UML, SysML etc.) verwendet werden! 

(UJHEQLV/RJLN 

• Vergleich mit 

Kalibrierwerten 

• Kombination der 

Einzelergebnisse 

Ausgabe 

Ergebnis und 

Rückfrage 

Analyse 

Eingabe 

Speichern 

erkannter Autor 


6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

7LHIHUJHKHQGH'HWDLOOLHUXQJGHU/|VXQJ 

)XQNWLRQ$XWRUHQHUNHQQXQJ/|VXQJVDQVDW]$EVWU(EHQH 

9HUZHQGXQJ0DXVRGHU7RXFKSDG Æ 

a) Erfassung der Maus Aktion über Schnittstelle 

b) Zwischenspeicherung der Maus Aktion 

c) Zählen der Maus Aktionen pro Zeiteinheit 

d) Speicherung der Maus Aktionen nach jeder Zeiteinheit, akkumulierend 

e) Erfassung der Touchpad Aktion über Schnittstelle 

f) Zwischenspeicherung der Touchpad Aktion 

g) Zählen der Touchpad Aktionen pro Zeiteinheit 

h) Speicherung der Touchpad Aktionen nach jeder Zeiteinheit, akkumulierend 

i) Errechnen des Verhältnisses von Maus- und Touchpadaktionen nach jeder 

Zeiteinheit 

2.Verwendung shortcuts oder Mausklicks auf Menüpunkte Æ 

3.Vertippfehler 

4.Orthographiefehler 

5.Anschlagfrequenz 

6.Anschlagpausen 

7.etc. bis Lösung 13 

Namensbibliothek 

Verhältnisbildung 

Verhältnisbildung 

-26- 


“ 


45



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

$UFKLWHNWXUHQWZXUI7HLOIXQNWLRQ0DXV 

7RXFKSDG 

Teilfunktion 1 

I/F 

Erfassung der 

Maus Aktionen 

Zeiteinheit 

Zwischenspeicherung 

der 

Maus Aktionen 

Zählen der 

Maus Aktionen 

Pro Zeiteinheit 

Speicherung der 

Maus Aktionen nach 

Jeder Zeiteinheit, 

akkumulierend 

I/F 

Erfassung der 

Touchpad Aktionen 

Zeiteinheit 

Laufende 

Berechnung des 

Verhältnisses 

I/F 

Zwischenspeicherung 

der 


Zählen der 


Pro Zeiteinheit 

Speicherung der 

Touchpad Aktionen nach 

Jeder Zeiteinheit, 

akkumulierend 

Hierbei kann natürlich eine formale Notation (UML, SysML etc.) verwendet werden! 


6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 


9HUOLQNXQJ $QIRUGHUXQJ ÅÆ /|VXQJ 

/DVWHQKHIW 

Entwurf erfüllt LH Anforderung 

6\VWHP 

$QIRUGHUXQJHQ 

3IOLFKWHQKHIW 

6\VWHPHQWZXUI 

Systemanforderung erfüllt Systementwurf 

Systemvalidierung 

6XEV\VWHP 

(QWZXUI 

6XEV\VWHPQ 

(QWZXUI 

Subsystem 1 

Verifikation 

Subsystem n 

Verifikation 

6XEV\VWHP 

$QIRUGHUXQJHQ 

6XEV\VWHPQ 

$QIRUGHUXQJHQ 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Architektur 

Komponenten 

Anforderungen 

Komponenten 

Anforderungen 

Komponenten 

Architektur 

Komponenten 



Verifikation 

Komponenten 



Verifikation 

-27- 

“ 


-28- 


“ 


46



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 


1 


2 


3 

Das Beispiel 

4 


5 



=XVDPPHQIDVVXQJ 

6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

Beim Ableiten von Lösungen aus Anforderungen 

kommt meist das systematische Vorgehen zu kurz 

Das Ableiten der Architektur ist auch deshalb 

notwendig, damit die Anforderungen der nächsten 

Ebene erstellt werden können (Unteraufträge!) 

Anforderungsmanagement und Architekturentwurf 

sind (in beiden Richtungen) voneinander abhängig! 

-29- 

“ 


-30- 


“ 


47



6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 

(LQLJHXQEHVSURFKHQHEH]RJHQH7KHPHQ 

• Modellierung 

• Lösungsauswahl (tradeoff) 

• Entwurfsmethoden 

• Erfüllungskriterien 

• Erfüllungsgrad 

• Änderungsmanagement 


6\VWHPV 

(QJLQHHULQJ 

6XSSRUW 


1 


2 


3 

Das Beispiel 

4 


5 


-31- 

“ 


-32- 


“ 


48

7 Andreas Bogner »Anforderungsmanagement in der Entwicklung komplexer 

Fahrwerksregelsysteme« 

Anforderungsmanagement in 

der Entwicklung komplexer 

Fahrwerksregelsysteme 

Dr. Andreas Bogner 

Entwicklung Fahrdynamik 

Hot Spots Workshop Requirements Engineering 

08.10.2009 

BMW Group 

Dr. Bogner 


Seite 2 

Anforderungsmanagement in der Entwicklung 

komplexer Fahrwerksregelsysteme 

Inhalt 

Ausgangssituation und Ziele 

Umsetzung 

Herausforderungen 

Fragestellungen 

49

BMW Group 

Dr. Bogner 


Seite 3 



Ausgangssituation und Ziele 

Ausgangssituation: 

Hohe Anzahl komplexer Fahrwerksregelsysteme 

Überschneidende Wirkungen der Regelsysteme auf das 

Fahrverhalten 

Hohe Anzahl beteiligter Entwickler 

Anforderungen aus verschiedenen Bereichen 

Ziele: 

Sicherstellung der Qualität des Entwicklungsergebnisses 

Aufwandsreduzierung und Arbeitserleichterung im gesamten 

Entwicklungsprozess 

BMW Group 

Dr. Bogner 


Seite 4 



Umsetzung 

50

BMW Group 

Dr. Bogner 


Seite 5 



Umsetzung 

Zur Sicherstellung der Übersichtlichkeit erfolgt die 

Formulierung der Anforderungen in einer Ebenenstruktur 

Vereinfachte Zuordnung der Testinstanz 

 

 

 

 

Vereinfachte Zuordnung von Verantwortlichkeiten 

Klare Trennung bei der Vergabe von 

Entwicklungsumfängen 

Vereinfachte Vergleichbarkeit von Anforderungen 

Vereinfachte Ermittlung der Abhängigkeiten zwischen 

verschiedenen Anforderungen 

BMW Group 

Dr. Bogner 


Seite 6 



Umsetzung 

Wankverhalten 

10 

Beispiel! 

8 

Eigenschaft 6 

6 

4 

Eigenschaft 2 

2 

0 

Eigenschaft 5 

Eigenschaft 3 

Eigenschaft 4 

BMW X5 

51

BMW Group 

Dr. Bogner 


Seite 7 



Umsetzung 

Fahrzeug 

BMW Group 

Dr. Bogner 


Seite 8 



Umsetzung 

Fahrzeug 

„Das Fahrzeug muss bei stationären Querbeschleunigungen einen 

maximalen Wankwinkel nach unten stehendem Diagramm aufweisen.“ 

Max. Wankwinkel [°] 

4 

3 

2 

Beispiel! 

1 

0 

-10 -5 0 5 10 

-1 

-2 

-3 

-4 

Querbeschleunigung [m/s 2 ] 

52

BMW Group 

Dr. Bogner 


Seite 9 



Umsetzung 

Fahrzeug 

Hardwareverbund 

Regelsystemverbund 

… 

… 

BMW Group 

Dr. Bogner 


Seite 10 



Umsetzung 

Fahrzeug 



… 

„Der Abstand des 

Fahrzeugschwerpunktes … von der 

Wankachse des Fahrzeugs darf 

maximal [x] m betragen.“ 

53

BMW Group 

Dr. Bogner 


Seite 11 



Umsetzung 

Fahrzeug 



… 

Einzelfunktion 

… 

BMW Group 

Dr. Bogner 


Seite 12 



Umsetzung 

Fahrzeug 

„Die Wankstabilisierungsfunktion muss stationär an den Rädern 

der Vorderachse eine radbezogene Vertikalkraft nach unten 

stehendem Diagramm zur Verfügung stellen. “ 


10000 Regelsystemverbund 

8000 

6000 

Vertikalkraft [N] 

… 

… 

4000 

2000 

-4000 


Beispiel! 

0 

-10 -5 0 5 10 

-2000 

VR 

VL 

-6000 

-8000 

-10000 

Querbeschleunigung [m/s 2 ] 

54

BMW Group 

Dr. Bogner 


Seite 13 



Umsetzung 

Fahrzeug 



… 


… 

Aktuatorik 

Steuergeräteverbund 

BMW Group 

Dr. Bogner 


Seite 14 



Umsetzung 

Fahrzeug 



… 


… 

Aktuatorik 


„Der Schwenkmotor im aktiven 

Vorderachsstabilisator muss ein 

maximales Moment von [x] Nm 

aufbringen können.“ 

55

BMW Group 

Dr. Bogner 


Seite 15 



Umsetzung 

Fahrzeug 



… 


… 

Aktuatorik 


„Der Schwenkmotor im aktiven 

Vorderachsstabilisator muss ein 

maximales Moment von [x] Nm 

aufbringen können.“ 

„Der Steuergeräteverbund muss 

eine PWM-Sollspannung für die 

Stellventile ausgeben.“ 

BMW Group 

Dr. Bogner 


Seite 16 



Umsetzung 

Fahrzeug 



… 


… 

Aktuatorik 


Basissoftware 

STG-Hardware 

Module 

Sensorik 

56

BMW Group 

Dr. Bogner 


Seite 17 



Umsetzung 

Fahrzeug 



… 


… 

Aktuatorik 


„Das aufbereitete 

Querbeschleunigungssignal 

Basissoftware STG-Hardware 

muss eingelesen werden.“ 

Module 

Sensorik 

BMW Group 

Dr. Bogner 


Seite 18 



Umsetzung 

Fahrzeug 



… 


… 

Aktuatorik 


Basissoftware 

STG-Hardware 

Module 

Sensorik 

57

BMW Group 

Dr. Bogner 


Seite 19 



Herausforderungen 

Zielkonflikt bei der Festlegung der Ebenenanzahl und -inhalte 

Notwendige Granularität 

Komplexität bei der Befüllung 

Anforderungsformulierung bei der Festlegung dynamischer 

Eigenschaften mit problematischer Objektivierbarkeit 

Zielkonflikt zwischen Aufwand und Nutzen 

Auswahl geeigneter Tools mit passenden Schnittstellen zur 

durchgängigen Verlinkung der Anforderungen 

BMW Group 

Dr. Bogner 


Seite 20 



Fragestellungen 

Wie sieht bei ähnlichen Ebenenansätzen eine sinnvolle 

Strukturierung aus 

Bis zu welchem Grad bzgl. Eindeutigkeit, Vollständigkeit und 

Genauigkeit ist eine Anforderungsformulierung bei der 

Festlegung dynamischer Eigenschaften sinnvoll 

Welche Erfahrungen gibt es bezüglich einer geeigneten 

Toolauswahl 

58

8 Wolfgang Wiehle »Anforderungsmanagement in einem industriellen 

Großprojekt« 

Anforderungsmanagement in einem 

industriellen Großprojekt 

HSE-Workshop „Requirements Engineering“ 

TU München, Garching, 08.10.2009 

Wolfgang Wiehle 

Übersicht 

Das Projekt „Verkäufer-Arbeitsplatz“ 

Die Rolle des Anforderungsmanagements im Projekt 

Extraktion der Anforderungen aus dem Fachkonzept 

Schnittstellen des Anforderungsmanagements 

Fazit 

2 

© 2009 iteratec GmbH 

59


Wesentliche Projektdaten 

Kunde: Ein Automobil-Konzern 

iteratec ist als Projektpartner des Hauptauftragnehmers in der 

Projekt involviert 

Systemzweck: Optimierung der Abläufe beim Pkw-Verkauf 

Gesamt-Auftragsvolumen: über 10 Mio. € 

Start des Realisierungs-Projekts: August 2008 

Grundlage: vorliegendes Fachkonzept (ca. 6000 Seiten) 

3 


Anforderungsmanagement im Projekt „Verkäufer-AP“ 

Besondere Rahmenbedingungen 

Es liegt bereits ein ausgearbeitetes Fachkonzept vor 

Kein Anforderungsmanagement „von Null beginnend“ 

Sehr detaillierte Vorgaben 

(Leider) Keine Use Cases beschrieben 

Warum Tool-basiertes Anforderungsmanagement 

Beherrschung des großen Volumens an Vorgaben 

Nachverfolgung (Traceability) der Anforderungen erforderlich 

Weiterverarbeitung der Anforderungen für Planung, Design, Test 

Projekt-Vorgaben 

Vorgehensmodell des Kunden 

Entwicklungs-Richtlinien des Hauptauftragnehmers 

Festlegung auf IBM Rational Tools (mit wenigen Ausnahmen), 

für das Anforderungsmanagement Festlegung auf Requisite Pro 

4 


60

Übersicht 





Fazit 

5 



Einbindung in die Projekt-Prozesse 

6 


61


Unterstützung durch Werkzeuge 

Change Management 

u.a. Auswertungen in Requisite Pro 

Projekt-Management, 

hier: Planung, Reporting 

u.a. Planungs-Datenbank (MS Access) 

Anforderungsmanagement 

Fachkonzeption 

Erstellung 

initiales 

Fachkonzept 

(abgeschl.) 

Fachliches Design 

Strukturierung 

der 

Anforderungen 

Requisite Pro 

CR-Fachkonzeption 

Ganz überwiegend MS Word 

Detaillierte 

Modellierung 

Rational Software Architect 

Entwicklung 

RAD, WID u.a. 

Test 

HP Quality Center 

7 


Übersicht 





Fazit 

8 


62


Ausgangslage – Wo soll es hin gehen 

Der Kunde liefert uns: 

Unterschiedlichste Anforderungs- und 

Fachkonzeptbeschreibungen mit insgesamt über 6000 Seiten 

verteilt auf über 30 verschiedene Dokumente basierend auf 

mehreren unterschiedlichen Strukturvorlagen 

viele wenig strukturierte Informationen (Prosatext) 

abschnittsweise auch redundante Beschreibungen 

Die Herausforderung: 

Bereitstellung der Fachkonzeptinhalte in der Werkzeug-Kette 

Zerlegung in „handliche“ Elemente 

Bereitstellung in einer einheitlichen Struktur 

Filterung der Informationsfülle auf das Wichtige 

Effiziente Weiterverarbeitung 

( Schnittstellen des Anforderungsmanagements) 

9 



Die Lösung 

Elemente des Fachkonzepts wie Anforderungen behandeln 

Fachkonzept-Elemente sind hier: 

Geschäftsprozesse 

Dialoge (Abläufe / Datenbeschreibungen) 

GUI-Prototypen (detailliert) 

Applikationsfunktionen (Funktionale Beschreibungen) 

Druckausgaben 

Schnittstellen zu externen Systemen 

Fachliches Objektmodell 

Basis für Anforderungstypen-Modell in Requisite Pro 

10 


63


Wie sieht das aus 

11 



Warum Fachkonzept-Elemente als Anforderungen 

Vorteile 

Überführung in das Anforderungsmanagement-Tool der 

Produktionskette ( Requisite Pro) 

Fachkonzept-Elemente werden auch in Planung verwendet 

Navigierbare Struktur über alle Dokumente 

Einheitliche Struktur durch Anforderungstypen-Modell 

Nachteile 

Anforderungstypen-Modell ist nicht für klassische 

Anforderungsanalyse geeignet 

Vorgehen ist sehr projektspezifisch 

12 


64


Traces – Beziehungen zwischen Fachkonzept-Elementen 

Zwischen den Fachkonzept-Elementen existieren 

unterschiedlichste Beziehungen und Abhängigkeiten 

Beispiel: 

Was soll geschehen, wenn im Dialog ein Button gedrückt wird 

Verweis auf Applikationsfunktion 

Beziehungen werden mit Traces dargestellt 

Geforderte und erlaubte Traces werden im Traceability-Modell 

definiert 

Traces erlauben eine schnelle, effiziente Analyse von 

Zusammenhängen zwischen Anforderungen 

Abdeckungs-Analyse 

Analyse der Auswirkungen von Änderungen 

13 



Analysieren und Setzen von Traces 

FK-xy FK-xy 

3.4 

3.4 

Dialoge 

Dialoge 

3.5 

3.5 

AFs 

AFs 

3.6 

3.6 

Printouts 

Printouts 

5.3.2 

5.3.2 

Interfaces 

Interfaces 

Traceability-Matrix 

Process No Process Name Step No Step Name 

1.1.1.1 Present products 1 

Identify prospect’s/customer’s wishes and 

requirements 

5.1.1.2 

Put customer through/Offer 

3 Identify prospect’s/customer’s wishes 

return call 

5.1.2.3 Introduce Sales Person 3 Identify prospect’s/customer’s wishes 

5.1.4.2 Lead candidate pre-qualification 3 Acquire vehicle requirements 

5.1.4.3 Lead candidate evaluation 3 

Enrich candidate, check sales opportunity and verify 

prospect 

5.1.4.6 Manual lead creation 3 Acquire vehicle requirements 

5.1.4.7 Manual lead data enrichment 3 Acquire vehicle requirements 

5.1.5.1 Perform first contact 3 Enrich lead and check sales opportunity 

Analyseergebnis: 

SPEC DLGDataAreaVehicleRequirements 

BPEPC Present Products (R 1.1.1.1) 

SPEC DLGDataAreaVehicleRequirements 

BPEPC Introduce Sales Person (R 5.1.2.3) 

Abbildung in in ReqPro 

14 


65


Traceability-Baum – Hierarchische Sicht auf Abhängigkeiten 

15 


Übersicht 





Fazit 

16 


66


… zu Design und Implementierung 

Vorteile durch Werkzeug-Integration: 

In Requisite Pro vorliegende Fachkonzept-Abschnitte 

(z.B. Funktions-Beschreibungen) werden mit Design-Elementen 

(z.B. Methoden) im Rational Software Architect (RSA) verbunden 

Auch umgekehrt: Für Design-Elemente im RSA (z.B. Use Cases) 

können Repräsentanten („Proxies“) in Requisite Pro erstellt und 

dort mit Anforderungen verknüpft werden 

Die Business-Objekte (die im Fachkonzept feingranular auf Excel- 

Basis vorliegen) werden über ein Plug-In in den RSA importiert 

Automatische Erzeugung von Word-Dokumentationen, die sich 

auf verknüpfte Inhalte aus Requisite Pro und RSA stützen 

Brüche in Werkzeug-Kette oder Vorgehensweise: 

Geschäftsprozesse (spezifiziert mit ARIS-Zeichnungen) können 

nicht auf der Ebene einzelner Schritte integriert werden 

Das Fachkonzept kennt keine Use Cases, daher ist teilweise ein 

Reverse Engineering des Fachkonzepts (!) erforderlich. 

17 



Beispiel für die Integration zwischen RSA und Requisite Pro 

18 


67


… zum Test-Management 

Vorteile durch Werkzeug-Integration: 

Import der Anforderungen aus Requisite Pro in das 

Testmanagement-Werkzeug (HP Quality Center) über ein 

Synchronisations-Werkzeug 

Erstellung von Testfällen mit Verknüpfung zu Anforderungen und 

nachmodellierten Use Cases 

Verfolgung der Auswirkungen von Anforderungs-Änderungen auf 

die Testfälle 

Die Verknüpfungen zwischen Anforderungen und Testfällen 

schaffen eine Grundlage für die Test-Abdeckungsanalyse 

19 



… zum Projekt-Management 

Vorteile durch Werkzeug-Nutzung und -Integration: 

Genaue Kenntnis der umzusetzenden Fachkonzept-Elemente 

(Listen-Export aus Requisite Pro ist Grundlage für QS der 

Projekt-Planungs-Datenbank) 

Erfassung der Abhängigkeiten (Traces) zwischen den 

Anforderungen (Fachkonzept-Elementen) kann die Stufen- 

Planung unterstützen 

Verknüpfung der Anforderungen mit Design-Elementen und 

(mittelbar) den Arbeitspaketen der Projektplanung erleichtert 

Analyse des Projektfortschritts. Ein Werkzeug-unterstütztes 

Reporting über die Fachkonzept-Abdeckung wird möglich 

20 


68

Umgang mit Änderungen von Anforderungen 

Änderungsverfahren ist festgelegt 

CRs werden mit Bezug auf das Fachkonzept und in einem hierauf 

abgestimmten Format erstellt 

Die Änderungs-Anforderungen werden in Requisite Pro erfasst 

und über Traces mit den betroffenen Elementen verknüpft 

Später werden die Änderungen in die „lebende“ Fachkonzeption in 

Requisite Pro eingearbeitet 

Nachverfolgung der Änderungen bei Anforderungen durch 

regelmäßiges Ziehen von „Baselines“ in Requisite Pro und 

Werkzeug-gestützten Abgleich 

Einschränkung: Requisite Pro unterstützt kein modernes 

Konfigurations-Management – es ist kein direkter Zugriff auf 

ältere Versionen von Anforderungen möglich (nur über die 

Baselines). 

21 


Übersicht 





Fazit 

22 


69

Fazit (1/2): Erfahrungen im Projekt „Verkäufer-AP“ 

Das Anforderungsmanagement im Projekt „Verkäufer- 

Arbeitsplatz“ kann nur durch intensiven Werkzeug-Einsatz 

beherrscht werden 

Die besondere Projekt-Situation macht ein Vorgehen 

abweichend vom klassischen Anforderungs-Management 

erforderlich 

Ein Tool-basiertes Anforderungsmanagement von Anfang an 

hätte vieles vereinfacht und insbesondere die Übernahme der 

fertigen Fachkonzeption in die Werkzeug-Kette erspart 

Planvolles Vorgehen von Anfang an ist für den Erfolg 

wesentlich 

Geschickte Nutzung der Potenziale von Werkzeugen schafft 

erheblichen Effizienz-Gewinn und reduziert Fehler-Risiken 

23 


Fazit (2/2): Erfahrungen mit Requisite Pro 

Vorteile von Requisite Pro im Projekt-Kontext 

Integration mit MS Word erleichtert die Übernahme des in 

Textform vorliegenden Fachkonzepts 

Besondere Integration mit Rational Software Architect ermöglicht 

intensive Verknüpfung der Modelle mit den Anforderungen 

Nachteile von Requisite Pro im Projekt-Kontext 

Eher umständliche Bedienung 

Requisite Pro unterstützt kein modernes Konfigurations- 

Management. Das erschwert die Verwaltung von Änderungen 

durch Change Requests 

Gesamtsicht: Für die Bewältigung der Aufgaben im Projekt sind 

wir mit Requisite Pro recht zufrieden 

24 


70

Ihre Fragen 


Wolfgang.Wiehle@iteratec.de 

Kontakt: 


iteratec GmbH 

Inselkammerstr. 4 

82008 München-Unterhaching 

Wolfgang.Wiehle@iteratec.de 

Tel. 089 / 614 551 - 0 

www.iteratec.de 

71

Tagungsband zum HSE-09 - Software and Systems Engineering ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?