Requirements Engineering

1. Requirements Engineering Requirements Engineering Dr. D. Fehrer

2. Phasen der SW-Entwicklung (nach Balzert) Planung Definition Entwurf Implementierung Abnahme & Einführung Wartung & Pflege Requirements Engineering Dr. D. Fehrer Dr. D. Fehrer

3. System- Anforderungen Software- Anforderungen Analyse Entwurf Codierung Testen Betrieb Wasserfall-Modell Requirements Engineering Dr. D. Fehrer

4. V-Modell 97 (grob) Anforderungs- definition Abnahme- test Anwendungsszenarien Grob- entwurf System- test Testfälle Fein- entwurf Integrations- test Testfälle Implemen- tation Modul- test Tf. Requirements Engineering Dr. D. Fehrer

5. Klassische Definition Analyse • ... mündet in ein Zieldokument („Lastenheft“): „was“, nicht „wie“ • detaillierte Funktionsbeschreibung • Vorhersagen für wichtige Parameter(geht ein in Kosten, Nutzen, Performanz) • Übereinstimmung zwischen allen Vertragspartnern Requirements Engineering Dr. D. Fehrer

6. ca. 65% der schwerwiegenden Fehler in Programmen sind auf Fehler bei der Analyse zurückzuführen! 200 100 10 • Spezifikation Entwurf Codierung Test Abnahme Betrieb Motivation Relative Fehlerbehebungskosten Requirements Engineering Dr. D. Fehrer

7. Effekt der Analyse auf den SW-Lebenszyklus • bessere Kommunikation (intern und extern) • Redundanzelimination in der Dokumentation • Doku startet früh • leichtere Änderbarkeit der Dokumentation • vollständige Studie ganzer Felder • aber: der Zyklus wird frontlastig! (Panik?) Requirements Engineering Dr. D. Fehrer

8. warum Analyse? • bessere Beurteilbarkeit im Vorfeld • Erhebung von Vergleichsdaten für künftige Projekte • Wiederverwendung von EntwürfenGERADE für Änderungen/Varianten! • weniger zur Erfolgserzielung als zur Fehlervermeidung (defensiv) Requirements Engineering Dr. D. Fehrer

9. Fehler und Ressourcenmanagement • Fehler in unterschiedlichen Phasen von unterschiedlichen Auswirkungen • „zu viel Zeit verbraten“,„jetzt endlich Resultate sehen“ • schwer vermittelbar (außer Bereiche wie Luftfahrt) Requirements Engineering Dr. D. Fehrer

10. Lösung 1: spezifikationsorientierte Entwicklung („schwergewichtig“) • Plus: • (scheinbar) gute Planbarkeit • viel Hilfestellung durch definierten Prozess • Unterstützung durch Vorlagen und Checklisten möglich • Qualitätssicherung durch frühe Testplanung • Minus: • teilweise sehr aufwändig • Feedback-Schleifen recht lang • hoher Lernaufwand Requirements Engineering Dr. D. Fehrer

11. Zur Terminologie • Klassische Bezeichnung: Requirements Analyse • legt traditionelles Phasenmodell nahe • Voraussetzungen: • gut verstandene Domäne • existierende Lösungen (in SW nachbauen) Requirements Engineering Dr. D. Fehrer

12. Schwierigkeiten der Analyse • Aufwand der Dokumenterstellung(Automatisierung!) • inadäquate Methodik(lernen!) • unterschiedliche Sprachen(graphisch!) Requirements Engineering Dr. D. Fehrer

13. Probleme der Anforderungsanalyse • Unklare Zielvorstellungen (verschiedene Personengruppen) • Hohe Komplexität der Aufgabe (wechselseitige Abhängigkeiten) • Kommunikationsbarrieren • Requirements creeping (Dazulernen) • Schlechte Qualität der Anforderungen (Mehrdeutigkeiten, Redundanzen, Widersprüche) • Gold-plating • Ungenaue Planung und Verfolgung Requirements Engineering Dr. D. Fehrer

14. Analyse • ist schwierig: heterogene Personengruppen mit unterschiedlichen Zielvorstellungen • ist frustrierend! • ist schlecht definierbar: es ist oft nicht einmal klar, wann sie zuende ist Requirements Engineering Dr. D. Fehrer

15. Zitat (Tom De Marco): „So analysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult.In a word, it is fascinating.Once you‘re hooked, the old easy pleasures of system building are never again enough to satisfy you.“ Requirements Engineering Dr. D. Fehrer

16. Kein System wird erfolgreich werden ohne die aktive und bereitwillige Beteiligung seiner Nutzer. Þ Benutzer müssen damit vertraut gemacht werden, wie das System funktioniert, und wie man damit umgeht. Der „Tuning-Kanal“ muß offen bleiben DAS IST DIE AUFGABE DES ANALYTIKERS!!! Requirements Engineering Dr. D. Fehrer

17. Die Realität • Oftmals nur vage Produkt- / Lösungsidee • unterschiedlichste Vorstellungen der verschiedenen Entscheider („stakeholder“) Requirements Engineering Dr. D. Fehrer

18. Konsequenzen • „erarbeiten“ statt nur „aufdecken“ (Requirements Engineering!) • gegenüberstellen und gewichten (Priorisierung) • laufend anpassen(Requirements Management) • und frühzeitig spiegeln(ablauffähige Modelle?) Requirements Engineering Dr. D. Fehrer

19. Test Design Lösung 2: iterative Entwicklung (Spiralmodell) • Plus: • hohe Flexibilität • rasches Feedback • risikobasiert • gute Erfolgskontrolle der einzelnen (Zwischen-)Ergebnisse • kein „Hellsehen“ nötig • Minus: • schlecht langfristig planbar • schlechte Gesamt-Fortschrittskontrolle Requirements Engineering Dr. D. Fehrer

20. eliciting modelling documenting maintaining communicating agreeing evolving Vgl. Sommerville&Sawyer discovering Vgl. Nuseibeh&Easterbrook Requirements Engineering Requirements Engineering Requirements Engineering Dr. D. Fehrer

21. Aktivitäten im RE • Anforderungsgewinnung (Elicitation) • Verhandlung (Negotiation) • Spezifikation (inkl. Dokumentation) • Validierung / Verifikation • Management • Change • Versionierung • Tracing Requirements Engineering Dr. D. Fehrer

22. Vorgehen • Feld festlegen (nicht zu speziell, aber ...) • betroffene Benutzer identifizieren • Interviews • Diagramme erstellen • Walkthroughs mit Nutzern (Validierung) • Veröffentlichung des Resultats Requirements Engineering Dr. D. Fehrer

23. Kunden- wünsche Domänen- wissen frühe Phase späte Phase Kontext- beschrei- bungen Gewinnung Gewinnung Verhandlung Verhandlung Anforderungs- modelle Spezifikation Spezifikation Validierung Verifikation Altsystem- randbedingungen System- Spezifikation „Phasen“ R-Management Entwurf Requirements Engineering Dr. D. Fehrer

24. Partitionierung SW / HW • Annahme V-Modell 97:frühe Auftrennung in HW und SW • eine gemeinsame System-Phase, danach zwei unabhängige Pfade • Beobachtung 1:viele Anforderungen, die das Gesamtsystem betreffen, können erst detailliert werden, wenn man ein Teilsystem genauer betrachtet • Beobachtung 2:viele Anforderungen ergeben sich erst nach der erfolgten Aufteilung Requirements Engineering Dr. D. Fehrer

25. Ideale Eigenschaften von Anforderungsmodellen • graphisch • hierarchisch • streng • wartbar • iterativ • logische Sicht, nicht physikalisch (aber ...) Requirements Engineering Dr. D. Fehrer

26. Arten von Anforderungsmodellen: • Lösungsorientiert • Strukturbeschreibungen, Schnittstellen, Zustände ... • Zielmodellierung • Hierarchie von Teilzielen, Abhängigkeiten, Konflikte ... • Szenarien und Use Cases • Verwendung, Validierungsorientierte Tests, ... Requirements Engineering Dr. D. Fehrer

27. Requirement (Anforderung) Definition (gemäß IEEE Standard Glossary of Software Engineering Terminology 610.12-1990): Eine dokumentierte Darstellung (representation) einer Bedingung oder Fähigkeit (capability) gemäß 1 oder2: 1. Beschaffenheit oder Fähigkeit, die von einem Benutzer zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird. 2. Beschaffenheit oder Fähigkeit, die ein System oder System-Teile erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen. Requirements Engineering Dr. D. Fehrer

28. Arten von Anforderungen • Funktionale Anforderungen • Design-Anforderungen (!) • Schnittstellen-Anforderungen • Performance-Anforderungen • Physikalische Anforderungen • Qualitätsattribute Requirements Engineering Dr. D. Fehrer

29. Beispiele für eingebettete Systeme Funktion Performanz Qualität Zuverlässigkeit Latenz Messen Sicherheit (safety) Timing Parametrierung Wartbarkeit Energieverbrauch Messwertdarstellung Verfügbarkeit Requirements Engineering Dr. D. Fehrer

30. Qualitätskriteria (einzelne Anforderung) • vollständig* (eher: gereift?) • korrekt* (gemäß Stakeholder!) • klassifizierbar (rechtliche Relevanz) • konsistent* • prüfbar* • eindeutig* (kein Interpretationsspielraum) • verstehbar (für alle Stakeholder) • gültig und aktuell • realisierbar (+ Kosten?) • notwendig • verfolgbar* • bewertet* (Priorisierung!) * = IEEE 830-1998 Requirements Engineering Dr. D. Fehrer

31. Qualitätskriteria (gesamte Spec) • angemessener Umfang und klare Struktur (--> Reviews) • sortierbar • qualitativ hochwertig • vollständig (inkl. Normreferenzen) • eindeutig und konsistent • verfolgbar • modifizierbar und erweiterbar* • gemeinsam zugreifbar • optimiert bezüglich Vorgehen * = IEEE 830-1998 Requirements Engineering Dr. D. Fehrer

32. vage individuelle Sichten informell Die 3 Dimensionen des RE Inhalt vollständig und korrekt Überein- stimmung gemeinsameSicht formal Repräsentation Requirements Engineering Dr. D. Fehrer

33. Techniken Bildung von Modellen Umfrage unter allen Stakeholdern Implementierungsprototyp Analyse des Umfelds Verhandlungen bei Unstimmigkeit Prototyp Automatischer Test von Modellen Re-Engineering Generierung von Artefakten Requirements Engineering Dr. D. Fehrer

34. Fazit • Wichtiges Thema • hohe Komplexität • es gibt Techniken und Methodik • es gibt für einiges sogar Werkzeuge • hoher Anteil persönlicher Skills Requirements Engineering Dr. D. Fehrer

35. Literatur Requirements Engineering für eingebettete Systeme, Klaus Pohl / Ernst Sikora, in: Software Engineering eingebetteter Systeme, Peter Liggesmeyer / Dieter Rombach (Hrsg.), Elsevier, München 2005 Requirements-Engineering und -Management, Chris Rupp & die SOPHISTen, Carl Hanser Verlag, München 2007 Requirements Engineering - A good practice guide, Ian Sommerville & Pete Sawyer, Wiley, Chichester 1997 Systematisches Requirements Management, Christof Ebert, dpunkt Verlag, Heidelberg 2005 Software Requirements & Specifications, Michael Jackson, Addison-Wesley, Harlow 1995 Requirements Engineering, Linda A. Macaulay, Springer, London 1996 Lehrbuch der Software-Technik. Software-Entwicklung, Helmut Balzert, Spektrum Akad. Verlag, Berlin 1996 Requirements Engineering Dr. D. Fehrer