REQUIREMENTS ENGINEERING

Universität zu KölnProjektplanung für Softwareprojekte: KLIPS 2.0Prof. Dr. phil. Manfred Thaller

Simone Kollmann (s.m.kollmann@gmx.de)Christian Weitz (cweitz0@smail.uni-koeln.de)

2

Buch

Christof Ebert:

Systematisches Requirements Engineering

Anforderungen ermitteln, spezifieren, analysieren und verwalten

2010³, dpunkt.verlag

3

Was ist eine Anforderung?(Ebert 2010, 21)

Eigenschaft oder Bedingung, die zur Erreichung eines Ziels benötigt wird

Eigenschaft oder Bedingung, die ein System erfüllen muss, um einen Vertrag, eine Norm, oder eine Spezifikation zu erfüllen

Dokumentierte Repräsentation einer Eigenschaft oder Bedingung

Eine Anforderung ist keine Lösung

4

Sichten auf Anforderungen(Ebert 2010, 24ff)

Marktanforderungen = Anforderungen aus Sicht des Kunden

Produktanforderungen = Anforderungen aus Sicht der Realisierung einer späteren Lösung

Komponentenanforderung = Anforderung an eine Komponente eines Produkts

5

Arten von Anforderungen(Ebert 2010, 28)

Funktionale Anforderung

Qualitäts-anforderung

Benutzersicht Benutzerschnittstelle Anwendungsfälle Dienstleistungen

Entwicklungssicht Architektur Lastbalancierung Stromversorgung

Benutzersicht Performanz Sicherheit Benutzbarkeit

Entwicklungssicht Testbarkeit Wartbarkeit Portierbarkeit

Randbedingung Kosten Marketing Durchlaufzeit Vertrieb und

Verteilung Organisation Dokumentation

Anforderungen

6

Was ist Requirements Engineering? (Ebert 2010, 33ff)

Systematisches Vorgehen zur Ermittlung, Spezifikation, Analyse, Vereinbarung, Validierung und Verwaltung von Anforderungen

Kerndisziplin der Ingenieurwissenschaften

Nicht auf Beginn der Entwicklungsphase beschränkt, sondern begleitet den Entwicklungsprozess

7

Ziel und Zweck von RE(Ebert 2010, 33)

Ziel: Qualitativ gute – nicht perfekte – Anforderungen zu generieren, die es erlauben, das Projekt mit einem akzeptablen Risiko zu beginnen

Zweck: Einverständnis zwischen dem Kunden und dem Softwareprojekt über jene Anforderungen zu erreichen, die durch das Projekt abgedeckt werden

8

Standards und Normen(Ebert 2010, 41)

9

Herausforderungen im Requirements Engineering(Ebert 2010, 52)

Zeitraum bis zur Nutzbarkeit der Software Zeitraum bis zum wirtschaftlichen Nutzen

der Software Produktqualität der erstellten Software Umsetzungskosten der Anforderungen in der

Entwicklung Kosten der Anforderungen über den

gesamten Produklebenszyklus Anpassbarkeit der Software an neue

Herausforderungen

10

Methodik des Requirements Engineerings(Ebert 2010, 54)

Ermittlung

Spezifikation Validierung

VereinbarungAnalyse

Verwaltung

Einflüsse,Aufwand,Risiko

PrioritätenZeitpunkteStatus

Markt-,Produkt-

Anforderungen,Modelle

Marktan-forderungen

Abhängigkeiten StatusKomponenten-AnforderungenSpezifikationen,Testfälle

Proj

ekt,

Prod

ukt

Bedü

rfni

sse,

Vis

ion,

Eins

chrä

nkun

gen

11

Produktlebenszyklus(Ebert 2010, 58ff)

Beschreibt alle wichtigen Aktivitäten oder Prozessschritte, um ein Produkt zu definieren, zu entwickeln, zu produzieren, zu betreiben, zu pflegen, zu warten, zu erweitern und schließlich zu beenden.

Wird in Phasen aufgeteilt, die durch Meilensteine getrennt werden

Eine neue Phase kann erst begonnen werden, wenn die vorhergehende beendet ist

Lebenszyklus setzt keine bestimmte Abfolge der Phasen voraus

12

Vorgehensmodell(Ebert 2010, 56ff)

1. Strategie und Konzeption

= „Upstream“-Phase, bevor das Projekt begonnen wird

Inhalte, Ziele und Meilensteine werden vereinbart

Business-Case wird vereinbart Wichtig: gesamten weiteren Zyklus

beachten

13

Vorgehensmodell2. Entwicklung

= Umsetzung der Anforderungen

Implementierungund Verifikation

Systemanalyse

System- undSoftwareentwurf

Anforderungs-ermittlung

Integrationstest

Systemtest

Freigabetest,Abnahme

Anforderungen,Lastenheft

Systemmodell,Pflichtenheft

Architektur,Entwurf

System in Produktion

System inEntwicklung

Legende:

Xxx EntwicklungsphaseÜberlappungen und Iterationen sind möglich

Yyy Entwicklungsergebnis

Bedürfnisse Lösung

14

Vorgehensmodell

So viel Prozess wie nötig, um die Geschäftsziele anhaltend zu erreichen, und so wenig Prozess wie möglich, um Flexibilität, Kreativität und Innovationskraft nicht einzuschränken.

15

Vorgehensmodell

3. Markteintritt

  Akzeptanz eines Produkts variiert in

ihrem Zeitpunkt und in ihrer Dauer abhängig von Externen Einflüssen

16

Vorgehensmodell

4. Evolution/ Wartungsphase

Beginnt mit Ende der Entwicklung oder mit Markteinführung

Zwei Änderungsarten am existierenden Produkt: Fehlerkorrekturen und Erweiterungen

17

Interessensvertreter im RE(Ebert 2010, 90ff)

Auftraggeber/ Kunde: erwartet eine Lösung innerhalb bestimmter Rahmenbedingungen

Benutzer: benutzen oder betreiben das System Projektmanager: sorgt dafür, dass

Anforderungen, Zeitdauer und Aufwand mit den vorhandenen Ressourcen korrespondieren

Produktmanager: verantwortlich über den gesamten Produktlebenszyklus, verantwortet den Business-Case eines Produkts.

18

Umgang mit Interessensvertretern(Ebert 2010, 86)

1. Identifizieren von Interessensvertretern

2. Beziehungen der Interessensvertreter zum Projekt und untereinander feststellen

3. Beziehungen zwischen Interessensvertretern ausarbeiten, irrelevante Gruppen ausklammern

4. Mögliche Konfliktpotentiale analysieren

5. Win-Win-Möglichkeiten für Schlüsselpersonen entwickeln

6. An Realisierung der Win-Win-Möglichkeiten arbeiten

7. Relevante Perspektiven der Interessensvertreter zur Anforderungsentwicklung feststellen

8. Bild der Interessenssphären vervollständigen

19

Anforderungen ermitteln(Ebert 2010, 125ff)

Produktvision Was wird das Produkt verändern? Warum ist das Produkt für die Kunden nötig? Welche Erfahrung soll der Kunde damit

machen? Wer wird durch das Produkt profitieren? Wie? Wie wird durch das Produkt Geld verdient? Welche Kosten und Risiken sind wir bereit zu

tragen?

20

Anforderungen ermitteln

Einflüsse auf Produktvisionen Kunden Strategie Wettbewerb Produkte Technologien Verfügbare Ressourcen als Restriktion

21

Anforderungen ermitteln

Schlüsselfrage an Produktvision Was wird bei den Kunden oder

Benutzern oder in meinem eigenen Unternehmen anders sein, wenn das Projekt ausgeführt ist?

22

Techniken zur Entwicklung der Anforderungen(Ebert 2010, 131ff)

1. Schritt: Mögliche Anforderungen erfassen = Verstehen von Kundenbedürfnissen, Märkten, Wettbewerben und Technologien

2. Schritt: Vision und Umfang festlegen = Abklären, was der Kunde möchte und braucht und was man selbst zur Realisierung braucht.

23

Techniken zur Entwicklung der Anforderungen

3. Schritt: Unbekannte Anforderungen und Randbedingungen identifizieren → schwierig zu ermitteln

4. Schritt: Methodische Vervollständigung der Anforderungen

durch Erarbeiten einer Liste mit potentiellen Funktionen

24

Techniken zur Entwicklung der Anforderungen

5.Schritt: Erste Analyse der Anforderungen, um Zusammenhänge und Einschränkungen zu verstehen.

→ bezieht sich sowohl auf Produktmanagement, als auch auf technische Ebene

25

Techniken zur Entwicklung der Anforderungen 6. Schritt Priorisierung der Anforderungen

→ wirtschaftliche Entscheidung 7. Schritt: Entscheidung für die

getroffenen Annahmen, akzeptierte Randbedingungen, Einschränkungen und Prioritäten

→ Festlegungen müssen in Form einer Vereinbarung dokumentiert werden

→ werden zum Bestandteil der Anforderungen

26

Qualitätsanforderungen: ISO/IEC 9126(Ebert 2010, 139ff)

Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Änderbarkeit Portierbarkeit

27

Anforderungen spezifizieren (Ebert 2010, 154ff)

Anforderungen strukturieren, dokumentieren und in Zusammenhang bringen durch:

  Klare und konsistente Spezifikation Vorlagen und Templates Strukturierung Verwenden von Attributen

28

Vielen Dank!

29

Anforderungsanalyse und -verbesserung(Ebert 2010, 185ff)

Sind Anforderungen eindeutig beschrieben?

Wie müssen sie ggf. abgeändert werden?

→ Projekt in Modellen beschreiben

30

Methoden der Anforderungsanalyse(Ebert 2010, 194ff)

31

Kontextanalyse(Ebert 2010, 199f)

Systemabgrenzung Schnittstellen erkennen Ggf. Teilsysteme definieren

AufzugBenutzer Service-techniker

32

Glossar (Ebert 2010, 207f)

Beschreibt die im Projekt verwendeten Begriffe

Hilft dabei, Missverständnisse zu vermeiden

33

Use Cases / Anwendungsfälle (Ebert 2010, 200ff)

Modellierung wichtiger funktionaler Szenarien

Deckt grundlegende Unklarheiten und logische Widersprüche auf

34

Funktionale Dekomposition Beschreibt Systemkomponenten Erster Schritt um Teilprojekte zu

identifizieren

35

Funktionale Dekomposition (Ebert 2010, 202)

Aufzug

Sensorik Aktorik Kabinen-Controller Alarm- undFehlerdetektion

Hardware Software

Tür-Controller

LichtschrankeTür

Rauchsensor

Stockwerkskonsole

Geschwindigkeits-messer

Kabinenmotor

Türmotor

Verwaltung offenerFahranforderungen

Fahrzielverwaltung

Motorsteuerung

Feuermelder

36

Zustandsübergangsmodell(Ebert 2010, 204f)

Fahr-anforderung

BewegeKabine

aufwärts

BewegeKabine

abwärts

FeueralarmFeueralarmquittiert

Feueralarm

Feueralarm

Stockwerkerreicht

Fahranforderungoben

Fahranforderungunten

Stockwerkerreicht

37

Zustandsübergangsmodell

Formalisierbar Erkennen von Blockaden Ausschluss kritischer Zustände

38

CRC-Karten,UML-Klassendiagramm(Ebert 2010, 208ff)

Class Responsibility Collaboration Unified Modeling Language Nähe zur Implementationsebene

39

CRC-Karten,UML-Klassendiagramm

ClassAufzugskabine

Responsibilities Fahre Kabine nach oben Fahre Kabine nach unten Kabine auf nächstem Stockwerk anhalten Nothalt im Alarmfall …

Collaboration Rauchmelder Aufzugskonsole ...

+FahreAufwärts()+FahreAbwärts()+Stop()+Nothalt()

-Betriebszustand : int

Aufzugskabine -Alarm : bool

Rauchmelder

-Stockwerk : int

Aufzugskonsole

1

1

1

1

40

Risikomanagement(Ebert 2010, 220ff)

Erweiterbarkeit / Modularität Striktes und systematisches

Änderungsmanagement Priorisieren von Anforderungen

Zwei Prioritäten: hoch und niedrigVerhältnis 75% zu 25% für (Zeit-)Budget

41

Qualitätskriterien von Anforderungen(Ebert 2010, 235ff)

Eindeutigkeit Realisierbarkeit Konsistenz Prüfbarkeit Relevanz/Geschäftsnutzen

42

Qualitätsverbesserung von Anforderungen(Ebert 2010, 240ff)

Standards und Vorlagen Reviews und Inspektionen Missbrauchsszenarien Linguistische Analyse Benutzerdokumentation

43

Änderungsmanagement(Ebert 2010, 285ff)

Anforderungen ändern sich Unklarheiten in Anforderungen Falsche Annahmen und Unsicherheiten Sich ändernde Kundenanforderungen

oder Marktbedürfnisse Projekte nicht länger als 12-18 Monate

44

Aufwandschätzung(Ebert 2010, 213ff)

Geld Zeit Produktivität Umfang

SlimControl KnowledgePlan

45

Werkzeugunterstützung(Ebert 2010, 319ff)

OSRMT DOORS eASEE IRqA MKS Integrity Reqtify RequisitePro RMTrak TruereqPLM

46

Requirements Engineering(Ebert 2010, 351ff)

~10% des Projektaufwands Kein Selbstzweck Planungsphase kleiner als 50%

Projektdauer

47

Vielen Dank!