REQUIREMENTS ENGINEERING
Universität zu KölnProjektplanung für Softwareprojekte: KLIPS 2.0Prof. Dr. phil. Manfred Thaller
Simone Kollmann ([email protected])Christian Weitz ([email protected])
2
BuchChristof 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,
Visi
on,
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
VorgehensmodellSo 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
Vorgehensmodell3. Markteintritt Akzeptanz eines Produkts variiert in
ihrem Zeitpunkt und in ihrer Dauer abhängig von Externen Einflüssen
16
Vorgehensmodell4. 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 Interessensvertretern2. Beziehungen der Interessensvertreter zum Projekt und
untereinander feststellen3. Beziehungen zwischen Interessensvertretern
ausarbeiten, irrelevante Gruppen ausklammern4. Mögliche Konfliktpotentiale analysieren5. Win-Win-Möglichkeiten für Schlüsselpersonen
entwickeln6. An Realisierung der Win-Win-Möglichkeiten arbeiten7. Relevante Perspektiven der Interessensvertreter zur
Anforderungsentwicklung feststellen8. 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 ermittelnEinflüsse auf Produktvisionen Kunden Strategie Wettbewerb Produkte Technologien Verfügbare Ressourcen als Restriktion
21
Anforderungen ermittelnSchlü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 Anforderungendurch 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
Aufzugskonsole1
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!
Top Related