Requirements Engineering

Slides:



Advertisements
Ähnliche Präsentationen
Risiko-Management im Projekt
Advertisements

Qualität „Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener.
Integrations- und Funktionstests im Rahmen des V-Modelles
Submodell Softwareentwicklung (SE)
IT-Projektmanagement
Dokumentation von Software Architekturen unter Berücksichtigung von IEEE 1471 Vortrag an der FH Regensburg © Dr. Ulrich Margull, 2004 Dr. Ulrich.
Prof. Dr. Liggesmeyer, 1 Software Engineering: Dependability Prof. Dr.-Ing. Peter Liggesmeyer.
Die Softwarelebenszyklen

Das „Vorgehensmodell“
Die Planungsphase -Anforderungsanalyse-
IT-Projektmanagement
Software-Lebenszyklus
Requirements Engineering
Universität Stuttgart Institut für Kernenergetik und Energiesysteme I nstitut für K ernenergetik und E nergiesysteme Rational Unified Process (RUP) - Definitionen.
Software „Unter Software versteht man die Gesamtheit oder auch einen Teil der Programme für Rechensysteme. Diese Programme ermöglichen zusammen mit den.
Zusammenfassung Risiken sind Bestandteil jeder Projektarbeit
Prüfung von SW-Komponenten – Überblick
Schulung der Mitarbeiter
Was ist Qualität ? Qualität von Produkten oder Dienstleistungen ist das Gesamtergebnis aller Aktivitäten in jeder Phase des gesamten Leistungsprozesses.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Beispiel 2: Iterative-Inkrementelle Vorgehensmodelle Annahmen: Anforderungen sind unvollständig.
Prozessmodelle als Teil des Management-Prozesses
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Links Links sind im Text angegeben. Weitere Links werden kontinuierlich eingefügt.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Testing Frameworks im Internet Testing Framework (xUnit, unit testing)
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Regeln für Tester - best practice 1 Prüfe das eigene Programm nie als Einziger Testen.
Beispiel: Wasserfallmodell als einfaches Phasenmodell
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Links Links sind im Text angegeben. Weitere Links werden kontinuierlich eingefügt.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme MuSofT LE 3.1-4V - Modell Überblick V-Modell Regelungen, die die Gesamtheit aller Aktivitäten,
Testen, Analysieren und Verifizieren von Software
Rational Unified Process (RUP) - Definitionen
Software Risk Evaluation Method (SRE)
eXtreme Programming (XP)
-LABORPRAKTIKUM- SOMMERSEMESTER 2005
Datenbankentwurfsprozess
Vorlesung Gestaltung von soziotechnischen Informationssystemen - RequirementsEngineering und Contextual Design- Thomas Herrmann, Lehrstuhl Informations-
Vorgehensmodelle: Schwergewichtige Modelle
Software Engineering WS 2009
Spezifikation von Anforderungen
Das Wasserfallmodell - Überblick
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Weitere Vorgehensmodelle Der Rational Unified Process RUP –bei IBM.
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering WS 2006 / 2007Folie 1 Agile Vorgehensweisen Hintergrund –in den letzten Jahren hat.
Fünf-Fünf-Zwei der 3. Vorlesung/Übung Requirements Engineering WS 10/11 Marin Zec.
Das Pflichtenheft Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth
Michael Haverbeck System Engineer
Das Redaktionssystem der APA
Projekt M8-Standards Woran erkennen wir, dass wir gut weiterkommen? Anregungen zur Entwicklung eines Performance Boards für die M8 Richard Stockhammer.
Österreichischer IT- & Beratertag 2006 Sind Konflikte in Veränderungsprozessen vorprogrammiert? Konfliktfelder und Lösungswege in IT-Projekten – Konfliktvermeidung.
REQUIREMENTS ENGINEERING
Definitionen der SWT (1)
Software-Technik „Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige.
Vorgehen Einführung einer Kostenrechnung (Phasen)
Wasserfallmodell und Einzelbegriffe
HFWI System Development Teil B Der Softwareentwicklungsprozess
5 Software-Qualität 5.1 Qualität 5.2 Taxonomie der Software-Qualitäten.
Projektmanagement Ziel und Umfang eines Softwareprojektes definieren
Vienna University of Technology Pirker Simon 1. Überblick Definition Motivation Vorteile Entwurf von VP Pirker Simon 2.
Abschlusspräsentation von Fred. Wolfgang Bischoff, Sebastian Krysmanski, Christoph Müller Fred Abschlusspräsentation von Fred Softwarepraktikums 2006 der.
GIS Design: A Hermeneutic View (Michael D. Gould)
Rational Unified Process
Software Engineering Grundlagen
Unified Modeling Language UML
Vorstellung des Arbeitskreises
Requirements Engineering Universität zu Köln Medienkulturwissenschaften/Medieninformatik Kurzreferat in Planung von Softwareprojekten bei Herrn Christoph.
OOSE nach Jacobson Sebastian Pohl/ST7 Betreuer: Prof. Dr. Kahlbrandt.
Seminar: Software-Architektur Einführender Vortrag
© Till Hänisch, 2002 BA Heidenheim Vorgehensmodelle Wie entsteht Software ?
Technische Universität München, Informatik XI Angewandte Informatik / Kooperative Systeme Verteilte Anwendungen: Entwurf Dr. Wolfgang Wörndl
Systems Requirements & Achitectur ENG 2 & ENG 3 Training Kunde,
Systemanalyse BA Heidenheim 2002.
 Präsentation transkript:

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