Requirements Engineering Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Phasen der SW-Entwicklung (nach Balzert) Planung Definition Entwurf Implementierung Abnahme & Einführung Wartung & Pflege Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer Wasserfall-Modell System- Anforderungen Software- Analyse Entwurf Codierung Testen Betrieb Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer 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. Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
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 Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer Motivation Spezifikation Entwurf Codierung Test Abnahme Betrieb 10 200 100 ca. 65% der schwerwiegenden Fehler in Programmen sind auf Fehler bei der Analyse zurückzuführen! Relative Fehlerbehebungskosten Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
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?) Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer warum Analyse? bessere Beurteilbarkeit im Vorfeld Erhebung von Vergleichsdaten für künftige Projekte Wiederverwendung von Entwürfen GERADE für Änderungen/Varianten! weniger zur Erfolgserzielung als zur Fehlervermeidung (defensiv) Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
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) Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
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 Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer 2 2 2 2 2
Requirements Engineering Dr. D. Fehrer Zur Terminologie Klassische Bezeichnung: Requirements Analyse legt traditionelles Phasenmodell nahe Voraussetzungen: gut verstandene Domäne existierende Lösungen (in SW nachbauen) Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Schwierigkeiten der Analyse Aufwand der Dokumenterstellung (Automatisierung!) inadäquate Methodik (lernen!) unterschiedliche Sprachen (graphisch!) Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
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 Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer Analyse ist schwierig: heterogene Personengruppen mit unterschiedlichen Zielvorstellungen ist frustrierend! ist schlecht definierbar: es ist oft nicht einmal klar, wann sie zuende ist Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer 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.“ Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Der „Tuning-Kanal“ muß offen bleiben 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!!! Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer Die Realität Oftmals nur vage Produkt- / Lösungsidee unterschiedlichste Vorstellungen der verschiedenen Entscheider („stakeholder“) Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer Konsequenzen „erarbeiten“ statt nur „aufdecken“ (Requirements Engineering!) gegenüberstellen und gewichten (Priorisierung) laufend anpassen (Requirements Management) und frühzeitig spiegeln (ablauffähige Modelle?) Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Lösung 2: iterative Entwicklung (Spiralmodell) Test Design Plus: hohe Flexibilität rasches Feedback risikobasiert gute Erfolgskontrolle der einzelnen (Zwischen-)Ergebnisse kein „Hellsehen“ nötig Minus: schlecht langfristig planbar schlechte Gesamt-Fortschrittskontrolle Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer 2 2 2 2 2
Requirements Engineering documenting discovering maintaining Vgl. Sommerville&Sawyer eliciting modelling communicating agreeing evolving Vgl. Nuseibeh&Easterbrook Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer Aktivitäten im RE Anforderungsgewinnung (Elicitation) Verhandlung (Negotiation) Spezifikation (inkl. Dokumentation) Validierung / Verifikation Management Change Versionierung Tracing Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer Vorgehen Feld festlegen (nicht zu speziell, aber ...) betroffene Benutzer identifizieren Interviews Diagramme erstellen Walkthroughs mit Nutzern (Validierung) Veröffentlichung des Resultats Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer System- Spezifikation „Phasen“ Kunden- wünsche frühe Phase späte Phase R-Management Domänen- wissen Anforderungs- modelle Kontext- beschrei- bungen Gewinnung Verhandlung Spezifikation Validierung Gewinnung Verhandlung Spezifikation Verifikation Altsystem- randbedingungen Entwurf Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
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 Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Ideale Eigenschaften von Anforderungsmodellen graphisch hierarchisch streng wartbar iterativ logische Sicht, nicht physikalisch (aber ...) Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Arten von Anforderungsmodellen: Lösungsorientiert Strukturbeschreibungen, Schnittstellen, Zustände ... Zielmodellierung Hierarchie von Teilzielen, Abhängigkeiten, Konflikte ... Szenarien und Use Cases Verwendung, Validierungsorientierte Tests, ... Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
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. Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Arten von Anforderungen Funktionale Anforderungen Design-Anforderungen (!) Schnittstellen-Anforderungen Performance-Anforderungen Physikalische Anforderungen Qualitätsattribute Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Beispiele für eingebettete Systeme Funktion Performanz Qualität Zuverlässigkeit Latenz Messen Sicherheit (safety) Timing Parametrierung Wartbarkeit Energieverbrauch Messwertdarstellung Verfügbarkeit Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
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 Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
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 Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer Die 3 Dimensionen des RE Inhalt vollständig und korrekt vage Überein- stimmung individuelle Sichten gemeinsame Sicht informell formal Repräsentation Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer 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 Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer Fazit Wichtiges Thema hohe Komplexität es gibt Techniken und Methodik es gibt für einiges sogar Werkzeuge hoher Anteil persönlicher Skills Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer
Requirements Engineering Dr. D. Fehrer 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 Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer