Requirements Engineering. Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer 1



Ähnliche Dokumente
Einführung und Motivation

Requirements-Management Ein praktisches Beispiel

T1 - Fundamentaler Testprozess

Prozess-Modelle für die Softwareentwicklung

Requirements Engineering für IT Systeme

Abschnitt 16: Objektorientiertes Design

Übungen zur Softwaretechnik

,$ -. "+0 *+*+ ! / -#$%$. #$%'' $ () 1 2$ #$%$! 1 2$3 )!

Softwaretechnik. Fomuso Ekellem WS 2011/12

Software Engineering. 3. Analyse und Anforderungsmanagement

T2 Fundamentaler Testprozess

Wirtschaftsinformatik I Teil 2. Sommersemester Übung

Software Engineering

FUTURE NETWORK REQUIREMENTS ENGINEERING

Software Engineering. Bibliographisches Institut & F. A. Brockhaus AG, Mannheim; Spektrum Akademischer Verlag GmbH, Heidelberg, 2003

Qualitätsmanagement. Andreas Bäuml SWT-Projekt WS 07/08

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Technische Dokumentation: wenn Englisch zur Herausforderung wird

Das Wasserfallmodell - Überblick

Some Software Engineering Principles

Softwareanforderungsanalyse

Lernen durch Feedback aus Inspektionen Dr. Andrea Herrmann

Functional Safety. Systems Engineering als Schlüsseldisziplin in Projekten mit funktionaler Sicherheit

Anforderungsanalyse, Requirements Engineering

Software Engineering. Dokumentation! Kapitel 21

Das Pflichtenheft. Dipl.- Ing. Dipl.-Informatiker Dieter Klapproth Ains A-Systemhaus GmbH Berlin

Requirements Engineering

Qualitätssicherung im Lebenszyklus des itcs. Anspruch und Wirklichkeit.

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Software Systems Engineering

Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, WS 2006/07

Typisierung des Replikationsplan Wirries, Denis Datenbankspezialist

16 Architekturentwurf Einführung und Überblick

Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert

Projektmanagement. Vorlesung von Thomas Patzelt 9. Vorlesung

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt

Requirements-Engineering Requirements-Engineering

Übung Einführung in die Softwaretechnik

Dr. Wolfgang Göbl Raiffeisen Solution

Usability Engineering in agilen Projekten

Content Management System mit INTREXX 2002.

SERVICE SUCHE ZUR UNTERSTÜTZUNG

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Was versteht man unter einem Softwareentwicklungsmodell?

SDD System Design Document

Grundlagen Software Engineering

Übungsaufgaben zum Software Engineering: Management

6. Programmentwicklung

Anforderungen aufnehmen: (Soft-) Skills für den Requirements Engineer

Software Engineering. Dokumentation. Wintersemester 2005/06. Kapitel 21. Universität Zürich Institut für Informatik

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Umfrage zum Informationsbedarf im Requirements Engineering

Qualitätsmanagement im Projekt

Seamless Model-based Engineering of a Reactive System

Informationssystemanalyse Lebenszyklusmodelle 3 1. Lebenszyklusmodelle sollen hauptsächlich drei Aufgaben erfüllen:

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Angepasste Software Standards für DLR- Eigenentwicklungen - Die DLR Software Basisstandards -

Erfolgreiche Realisierung von grossen Softwareprojekten

Comparing Software Factories and Software Product Lines

Einführung Spezifikation von Software-Systemen

Software- Entwicklungsaktivitäten und Vorgehensmodelle. Lebenszyklusmodell

Über den Unterschied zwischen Business Analysis und Requirements Engineering & Management

Dokumentation für die Software-Wartung

Qualitätserlebnis statt Qualitätssicherung. Eine Mehrfachfallstudie agiler Teams

PRÜFUNG FÜR ELEKTROINGENIEURE. Softwaretechnik I. Musterlösung SS Ohne Gewähr -

Universität Stuttgart Institut für Automatisierungstechnik und Softwaresysteme Prof. Dr.-Ing. M. Weyrich. Softwaretechnik I

Fragebogen zur Anforderungsanalyse

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Testplan. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw,

SysInventor. Jakobstr. 64 D Konstanz. Kontakt: Phone +49 (0) Fax +49 (0)

Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil.

Requirements Engineering (Anforderungstechnik)

Übung 6: Feinentwurf. Prof. Dr. Dr. h.c. Manfred Broy Dr. Herbert Ehler, Martin Feilkas 6. Juli 2006 Bernd Spanfelner, Sebastian Winter

Die Softwareentwicklungsphasen!

Wir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen. Wir bringen Qualität. Wir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen

Validierung und Verifikation!

Audits und Assessments als Mittel zur Risk Mitigation in der Aviatik. Helmut Gottschalk. AeroEx

Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen

OUTSOURCING ADVISOR. Analyse von SW-Anwendungen und IT-Dienstleistungen auf ihre Global Sourcing Eignung. Bewertung von Dienstleistern und Standorten

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

Neue Funktionen in Innovator 11 R5

Betriebswirtschaftliche Kriterien, Aufwand und Nutzen von CMMI-Implementierungen

Partizipation von Fachabteilungen in Requirements-Engineering-Prozessen für kaufmännische Anwendungen in KMU

Herausforderungen beim verteilten RE: Ergebnisse einer Umfrage

Qualitätssicherung. Was ist Qualität?

Interpretation des agilen Manifest

Anforderungen an die HIS

Dokumentation. Projekt: Innovation Management Plattform To Activate Creative Thoughts

Block R (Rahmen): SE Aktivitäten Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Basiswissen Requirements Engineering

Requirements Engineering I. Der Spezifikationsprozess!

Requirements-Traceability in der industriellen Praxis Ziele und Einsatz

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Testmanagement in IT-Projekten

IT-Projekt-Management

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Transkript:

Requirements Engineering Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer 1

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 2 Dr. D. Fehrer

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

V-Modell 97 (grob) Anwendungsszenarien Systemtest Abnahmetest Testfälle Feinentwurf Grobentwurf Integrationstest Testfälle Implementation Modultest Tf. Anforderungsdefinition Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer 4

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 5

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

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 7

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 8

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 9

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 10

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 11

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

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 13

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 14

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 15

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 16

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 17

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 18

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

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

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 21

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 22

Phasen System- Spezifikation Kundenwünsche frühe Phase R-Management späte Phase Domänenwissen Gewinnung Verhandlung Kontextbeschreibungen Gewinnung Verhandlung Spezifikation Validierung Altsystemrandbedingungen Anforderungsmodelle Spezifikation Verifikation Entwurf Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer 23

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 24

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

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 26

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 27

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 28

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

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 30

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 31

Die 3 Dimensionen des RE Inhalt vollständig und korrekt Übereinstimmung gemeinsame Sicht vage individuelle Sichten informell formal Repräsentation Uni Freiburg, 24.7.2008 Requirements Engineering Dr. D. Fehrer 32

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

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 34

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 35