RE bei adessofg-re.gi.de/fileadmin/gliederungen/fg-re/Treffen_2014/FGRE... · Innovation!...
Transcript of RE bei adessofg-re.gi.de/fileadmin/gliederungen/fg-re/Treffen_2014/FGRE... · Innovation!...
21.01.15
RE bei adesso Projekte im Spannungsfeld zwischen Gestaltung und Erhebung
Dr. Kim Lauenroth Chief Requirements Engineer
Folien vor 10 Jahren ...
21.01.15 3
15.5.2002© Prof. PohlUniversität EssenSoftware Systems Engineering © Prof. Dr. Pohl 1/37Universität Duisburg-EssenSoftware Systems Engineering © Prof. Dr. Pohl 1 von 10FG-Treffen 2.1.6 „RE“ 25./26. November 2004
Zentrale Variabilitätsmodellierung für Requirements Artefakte in der Produktlinienentwicklung1
Stan Bühne, Günter Halmans, Kim Lauenroth, Klaus Pohl
FG-Treffen 2.1.6 „RE“
25./26. November 2004
1Diese Arbeit wurde gefördert durch die Projekte Cafe, Families und Prime15.5.2002© Prof. PohlUniversität Essen
Software Systems Engineering © Prof. Dr. Pohl 3/37Universität Duisburg-EssenSoftware Systems Engineering © Prof. Dr. Pohl 3 von 10FG-Treffen 2.1.6 „RE“ 25./26. November 2004
Überblick
¾Grundlagen: Variabilität & Produktlinien Framework
¾Herausforderung: RE für Produktlinien
¾ Lösungsansatz: Zentrales Variabilitätsmodell
¾Beispiele
¾Zusammenfassung / Aktuelle Arbeiten
15.5.2002© Prof. PohlUniversität EssenSoftware Systems Engineering © Prof. Dr. Pohl 4/37Universität Duisburg-EssenSoftware Systems Engineering © Prof. Dr. Pohl 4 von 10FG-Treffen 2.1.6 „RE“ 25./26. November 2004
Variabilität als zentrales Konzept der PL Entwicklung
Variante
Variations-punkt
VPAutofarbe
Auto rot
Auto schwarz
Auto weiß
Varianten
Variabilität ist die Fähigkeit änderbaroder gestaltbar zu sein.
15.5.2002© Prof. PohlUniversität EssenSoftware Systems Engineering © Prof. Dr. Pohl 5/37Universität Duisburg-EssenSoftware Systems Engineering © Prof. Dr. Pohl 5 von 10FG-Treffen 2.1.6 „RE“ 25./26. November 2004
Produktlinien Framework
15.5.2002© Prof. PohlUniversität EssenSoftware Systems Engineering © Prof. Dr. Pohl 6/37Universität Duisburg-EssenSoftware Systems Engineering © Prof. Dr. Pohl 6 von 10FG-Treffen 2.1.6 „RE“ 25./26. November 2004
Herausforderungen: RE in PL
1. Konsistente Dokumentation der Variabilität in unterschiedlichen Anforderungsartefakten
2. Definition und Dokumentation der Variabilität im Domain Engineering
3. Bindung der Variabilität im Application Engineering zur Produkterstellung
4. Kommunizierbarkeit von Variabilität (für Kunde/Entwickler/Produktmanager)
15.5.2002© Prof. PohlUniversität EssenSoftware Systems Engineering © Prof. Dr. Pohl 7/37Universität Duisburg-EssenSoftware Systems Engineering © Prof. Dr. Pohl 7 von 10FG-Treffen 2.1.6 „RE“ 25./26. November 2004
ZentralesVariabilitäts-
modell
Lösungsansatz: Zentrales Variabilitätsmodell
Variation Point
Variant
Constraints
requires
exclusive
mandatory
alternative
optional
Requirements Artefact
Goal Scenario Requirement
Requirements
... ...
VariabilityDependency
15.5.2002© Prof. PohlUniversität EssenSoftware Systems Engineering © Prof. Dr. Pohl 8/37Universität Duisburg-EssenSoftware Systems Engineering © Prof. Dr. Pohl 8 von 10FG-Treffen 2.1.6 „RE“ 25./26. November 2004
Requirements Artefakte
VariabilitätsmodellNavigation
VP
Stau-meldung
V
Stimme
VBildschirm-darstellung
V
Alternative
Optional
Z1
Z2 Z3
Z5Z4
A B C
Ziele Szenarien Anforderungen
R1: Die Meldung von Staus
R2: Die Routenführung durch Stimme
R3: Die Routenführung am Bildschirm
Link
Beispiel: Konsistente Dokumentation (1) der Variabilität in unterschiedlichen Artefakten
Routen-führung
V
Mandatory
15.5.2002© Prof. PohlUniversität EssenSoftware Systems Engineering © Prof. Dr. Pohl 9/37Universität Duisburg-EssenSoftware Systems Engineering © Prof. Dr. Pohl 9 von 10FG-Treffen 2.1.6 „RE“ 25./26. November 2004
Zentrales Variabilitätsmodell
Beispiel: Kommunikation (4) und Bindung (3)
Kommunikation mit Kunden/Entwicklern/Produktmanagement
Requirements Artefakte
Scheiben-wischer
Verdeck-steuerung
Fahr-licht
VP VPVP
Interval-steuerung
VInterval-steuerung
VRegen/Licht-sensor
VRegen/Licht-sensor
VWasch-funktion
VWasch-funktion
V
ManuelleSteuerung
VManuelleSteuerung
V
Sensor-steuerung
VSensor-steuerung
VManuelleSteuerung
VManuelleSteuerung
V
Sensor-steuerung
VSensor-steuerung
V
Fahrzeug-typ
VP
Kombi
V
Kombi
V
Cabrio
V
Cabrio
V
Beziehungen
Produkt RequirementsSicht
+ Auswahl
Bindung durch Auswahl von Varianten und Sichtengenerierung
Z1
Z2 Z3
Z5Z4
A B C
Ziele Szenarien Anforderungen
R1: Die Meldung von Staus
R2: Die Routenführung durch Stimme
R3: Die Routenführung am Bildschirm
Z1
Z3
Z5
A B
Ziele Szenarien Anforderungen
R1: Die Meldung von Staus
R2: Die Routenführung durch Stimme
15.5.2002© Prof. PohlUniversität EssenSoftware Systems Engineering © Prof. Dr. Pohl 10/37Universität Duisburg-EssenSoftware Systems Engineering © Prof. Dr. Pohl 10 von 10FG-Treffen 2.1.6 „RE“ 25./26. November 2004
Zusammenfassung
¾ Kernthese: Variabilität als eigenständiges Modell ermöglicht:
� Konsistente Dokumentation in verschiedenen Anforderungsartefakten
� Kommunizierbarkeit von Variabilität
� Ableitung von Beziehungen zwischen Artefakten, dadurch
� konsistente Durchführung von Änderungen
¾ Nachteil: Zusätzlicher Aufwand (durch Verlinkung)
¾ Aktuelle Arbeiten
� Change und Versionsmanagement (mit und im Variabilitätsmodell)
� Analyse von Anforderungsmodellen (bzgl. Verlinkung), z.B. UML 2.0
� Tool-Support & Evaluation mit Industriepartnern
Entwicklungstrend in den vergangenen 15-20 Jahren
21.01.15 6
Steigende Komplexität
Kostendruck
Kürzere Entwicklungszeiten
Software-basierte Innovationen
Steigende Qualitätsanforderungen
Erfolgsquoten für Softwareprojekte
21.01.15 7
Quelle: CAOS Report 1994-2012. Standish Group.
16% 27% 26% 28% 34% 29% 35% 32% 37% 39%
53% 33% 46% 49%
51% 53% 46% 44% 42% 43%
31% 40%
28% 23% 15% 18% 19% 24% 21% 18%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90%
100%
1994 1996 1998 2000 2002 2004 2006 2008 2010 2012
erfolgreich eingeschränkt gescheitert
TOP 5 Gründe für Fehlschläge / Erfolgsfaktoren
1995 (Fehlschläge)
1. mangelnde Einbeziehung der Nutzer
2. unvollständige Anforderungen
3. Änderungen von Anforderungen
4. Fehlende Managementunterstützung
5. technologische Inkompetenz
2012 (Erfolgsfaktoren)
1. Managementunterstützung
2. Einbeziehung der Nutzer
3. Klare Zielvorgaben
4. Emotionale Reife
5. Optimierung
21.01.15 8
Quelle: CAOS Report 1995 & 2012. Standish Group. Hinweise: 1995 benennt der CAOS Report Gründe für Fehlschläge, 2012 werden stattdessen Erfolgsfaktoren benannt
Requirements Engineering (Definition nach IREB) Das Requirements Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:
(1) Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen.
(2) Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentieren
(3) Die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.
9 21.01.15
21.01.15 Anforderungsmanagement in der Auftragsabwicklung 14
"Computers are good at following instructions, but not at reading your mind.“
- Donald E. Knuth
©iStockphoto.com/JamesBrey (11451754)
Crea,vity(is(not(a(talent.((It(is(a(way(of(opera,ng.(
- John Cleese
Wer als Werkzeug nur einen Hammer hat ...
... sieht in jedem Problem einen
Nagel!
- Paul Watzlawick Bild: iStockphoto.com/gilas (1368321)
Anforderung (Definition IEEE 610-1990)
1) Eine Bedingung oder Fähigkeit, die von einem Benutzer zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
2) Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.
3) Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäß (1) oder (2).
System
Stakeholder
An was?
Wer?
Zweck?
Problem
Lösung
Warum?
Wann?
für Anforderung
Was ist eine Anforderung?
21.01.15 Anforderungsmanagement in der Auftragsabwicklung 20
Es(gibt(keine(lösungsneutralen(Anforderungen!(
Problem Lösung Anforderung
Fahrer vor zu geringem Reifenluft- druck warnen
Reifen- druck-
messung
Auswertung von ESP-
Daten
Der Sensor mussden Druck im Bereich zwischen 0 und 5 Bar mit einer Genauigkeit von +/-x% messen.
Der Reifendruck mussl alle y Sekunden gemessen werden.
Das ESP-System musskontinuierlich die Reifendrehzahl aller vier Räder überwachen.
Zu geringer Reifendruck liegt vor, wenn über einen Zeitraum von y Sekunden eine Abweichen in der Drehzahl eines Reifens von z% vorliegt.
Die Reifendrehzahl muss mit einer Genauigkeit von +/-x% gemessen werden.
Zu geringer Reifendruck liegt vor, wenn der gemessene Druck unter den Grenzwert z sinkt.
Bild: iStockphoto.com/1MoreCreative (15251741)
int mult(int a, int b) { return a*b; }
0 1 2 3 4 5
0 0 0 0 0 0 0
1 0 1 2 3 4 5
2 0 2 4 6 8 10
3 0 3 6 9 12 15
4 0 4 8 12 16 20
5 0 5 10 15 20 25
int mult(int a, int b) { int result=0; for (int i=0; i<a; i++) result = result + b return result; }
21.01.15 Anforderungsmanagement in der Auftragsabwicklung 23
Mode-of-Opera4ng-(
Prinzip(1:(Trennung(von(Problem,(Anforderung(und(Lösung(
Problem Anforderung Lösung 21.01.15 24
„Das System zeigt den aktuellen Druck auf allen vier
Reifen im Display unterhalb des Drehzahlmessers
an, so kann der Fahrer sofort erkennen, ob der
Druck auf den Reifen zu gering ist.“
Problem Anforderung Lösung
„Das System zeigt den aktuellen Druck auf allen vier
Reifen im Display unterhalb des Drehzahlmessers
an, so kann der Fahrer sofort erkennen, ob der
Druck auf den Reifen zu gering ist.“
21.01.15 25
„Das System zeigt den aktuellen Druck auf allen vier
Reifen im Display unterhalb des Drehzahlmessers
an, so kann der Fahrer sofort erkennen, ob der
Druck auf den Reifen zu gering ist.“
Bruch der Abstraktionsebene: � Display ist Teil des Systems � Welches Problem wird hierdurch gelöst?
21.01.15 26
APIs, Bibliotheken Hochsprachen
CPUs, RAM Register true, false +5 Volt, -5 Volt
Compiler
Betriebssystem Maschinensprachen
Mensch (Design Patterns,
Frameworks, MDA)
Fachliche Architektur Funktionale Architektur Technische Architektur
Wir sitzen auf einem Eisberg von Abstraktionsstrukturen
21.01.15 30
Nutzer Anwendungs-Entwickler
Framework-Entwickler
Programmiersprachen-Entwickler
Betriebssystem-Entwickler
T
Drei prinzipielle Abstraktionsstufen
Kontext:-System(als(Blackbox;(Beziehung(zur(Umgebung(steht(im(Fokus(
System:(AuMau(des(Systems(mit(logischen(Einheiten-
Technologie:(AuMau(des(Systems(mit(technischen(Einheiten-
21.01.15 32
Kontext
System
System/Technologie
Ein PKW fährt auf einer Straße im Berufsverkehr. Das erste Fahrzeug einer Kolonne von PKWs bremst scharf ab, da ein Kind auf die Straße springt. Die nachfolgenden Fahrzeuge werden vom Fahrzeug unmittelbar durch ein Funksignal über die Notbremsung informiert und leiten ebenfalls automatisch ein Bremsmanöver ein. Das Kind bleibt unverletzt und es passiert kein Auffahrunfall.
Technologie
21.01.15 33
System/Technologie?
Technologie
Kontext
System
Kontext
Ein PKW fährt auf einer Straße im Berufsverkehr. Das erste Fahrzeug einer Kolonne von PKWs bremst scharf ab, da ein Kind auf die Straße springt.
Die nachfolgenden Fahrzeuge werden unmittelbar über die Notbremsung informiert und können dadurch rechtzeitig abbremsen.
Das Kind bleibt unverletzt und es passiert kein Auffahrunfall.
Die Information über Notbremsung wird über ein Funksignal übertragen.
Das rechtzeitige Bremsen kann durch dediziertes automatisches Notbremssystem realisiert werden.
21.01.15 34
21.01.15 Anforderungsmanagement in der Auftragsabwicklung 35
Mode-of-Opera4ng-(
Prinzip(1:(Trennung(von(Problem,(Anforderung(und(Lösung(
(Prinzip(2:(Benennung(und(
Anwendung(von(Abstrak,onsstufen(
Problem Anforderung Lösung
Synthese der Prinzipien: PAL-Modell
Kontext:-System(als(Blackbox;(Beziehung(zur(Umgebung(steht(im(Fokus(
System:(AuMau(des(Systems(mit(logischen(Einheiten-
Technologie:(AuMau(des(Systems(mit(technischen(Einheiten-
21.01.15 36
Lauenroth, K.: Starten Sie mit einem Blatt Papier - Strukturieren und Analysieren von Anforderungen mit dem PAL-Modell. Objektspektrum 03/2013.
Bild: iStockphoto.com/Brigida_Soriano (14696510)
Grau,(teurer(Freund,((ist(alle(Theorie(...(
( ( (P(Mephisto((Goethes(Faust)((
21.01.15 Anforderungsmanagement in der Auftragsabwicklung 39
Beispiel(Abwickler(–(S,rbt(das(
PosUach(mit(dem(Anwalt?(21.01.15 39
21.01.15 Anforderungsmanagement in der Auftragsabwicklung 40
Beispiel(BearbeitungsP
auWragsP(maschine((BAM)(
21.01.15 40
21.01.15 Anforderungsmanagement in der Auftragsabwicklung 41
Beispiel(Erfassung(von(
Risikozuschlägen(21.01.15 41