Requirements Engineering

Präsentation zum Thema: "Requirements Engineering"—  Präsentation transkript:

1 Requirements Engineering
Universität zu Köln Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. phil. Manfred Thaller Simone Kollmann Christian Weitz

2 Buch Systematisches Requirements Engineering Christof Ebert:
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)
Grafik S.28

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)
Grafik S. 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)
Grafik S. 54

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 Vorgehensmodell 2. Entwicklung = Umsetzung der Anforderungen
Grafik S. 60

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)
Identifizieren von Interessensvertretern Beziehungen der Interessensvertreter zum Projekt und untereinander feststellen Beziehungen zwischen Interessensvertretern ausarbeiten, irrelevante Gruppen ausklammern Mögliche Konfliktpotentiale analysieren Win-Win-Möglichkeiten für Schlüsselpersonen entwickeln An Realisierung der Win-Win-Möglichkeiten arbeiten Relevante Perspektiven der Interessensvertreter zur Anforderungsentwicklung feststellen 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

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 Ggf. mit Folie 8 vereinigen

35 Funktionale Dekomposition (Ebert 2010, 202)

36 Zustandsübergangsmodell (Ebert 2010, 204f)

37 Zustandsübergangsmodell
Formalisierbar Erkennen von Blockaden Ausschluss kritischer Zustände Grafik hinzufügen

38 CRC-Karten, UML-Klassendiagramm (Ebert 2010, 208ff)
Class Responsibility Collaboration Unified Modeling Language Nähe zur Implementationsebene

39 CRC-Karten, UML-Klassendiagramm

40 Risikomanagement (Ebert 2010, 220ff)
Erweiterbarkeit / Modularität Striktes und systematisches Änderungsmanagement Priorisieren von Anforderungen Zwei Prioritäten: hoch und niedrig Verhältnis 75% zu 25% für (Zeit-)Budget i.e. Änderungen und neue Anforderungen folgen dem gleichen Prozess (Ermittlung, Analyse, Spezifikation, Nachverfolgung etc.)

41 Qualitätskriterien von Anforderungen (Ebert 2010, 235ff)
Eindeutigkeit Realisierbarkeit Konsistenz Prüfbarkeit Relevanz/Geschäftsnutzen 1. Nicht ambig. Offene Punkte als solche gekennzeichnet. 2. Realisierbar. Aufwand ist abgeschätzt und vereinbahrt. 3. Inhalt, Abstraktionsgrad, Beschreibung konsistent mit anderen A. 4. Testbar. Begrenzte Zahl Testfälle. 5.

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 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 1. nötig, um nicht zu viele Risiken einzugehen. 2. Es kann auch zu viel geplant werden. Diagramme zu erstellen allein verwirklicht kein Projekt. 3. Daher nicht mehr als 50% für die Planungsphase aufwenden.

47 Vielen Dank!