1 / 47

Requirements Engineering

Requirements Engineering. Universität zu Köln Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. phil. Manfred Thaller Simone Kollmann (s.m.kollmann@gmx.de) Christian Weitz (cweitz0@smail.uni-koeln.de). Buch. Christof Ebert: Systematisches Requirements Engineering

santos
Download Presentation

Requirements Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Engineering Universität zu Köln Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. 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)

  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)

  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

  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

  35. Funktionale Dekomposition(Ebert 2010, 202)

  36. Zustandsübergangsmodell(Ebert 2010, 204f)

  37. Zustandsübergangsmodell • Formalisierbar • Erkennen von Blockaden • Ausschluss kritischer Zustände

  38. CRC-Karten,UML-Klassendiagramm(Ebert 2010, 208ff) • Class ResponsibilityCollaboration • 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

  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!

More Related