IEEE Std (1990) Was eigentlich sind Anforderungen? 1

Ähnliche Dokumente
Requirements Engineering I

Die Unified Modeling Language UML

Requirements-Engineering Requirements-Engineering

Requirements Engineering

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert Vgl. Kapitel 4/5 aus Basiswissen Requirements Engineering, Klaus Pohl,

Requirements Engineering I

Unified. Copyright Adriano Gesué UML 2.0 UML 1.4 UML 1.3 UML 1.2 UML 1.1 UML 1.0 UML 0.9. Method 0.8

Grundlagen der Programmentwurfstechnik Fundamentals of Software Engineering 1

Inhaltsverzeichnis. Business Analysis und Requirements Engineering

UML (Unified Modelling Language) von Christian Bartl

Weiterführende Literatur

Software-Engineering

Informationssystemanalyse Requirements Engineering 10 1

Business Analysis Body of Knowledge BABOK v3. Konzepte Scope Struktur. Ursula Meseberg microtool GmbH Berlin

Softwaretechnik 2015/2016

Testen mit Use Cases. Chris Rupp Dr. Stefan Queins

Software Engineering

2. Der Software-Entwicklungszyklus

Requirements Engineering I

Objektorientierte Systementwicklung

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick

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

Inhaltsverzeichnis.

Kundenanforderungen dokumentieren

INSPIRE - Modellierung

ANFORDERUNGSDOKUMENTE. Dr. Peter Hruschka. Requirements Engineering!

Software- und Systementwicklung

Kapitel 1 Applikations-Architektur VIII

Requirements- Engineering und -Management

Objektorientiertes Design

Notationen zur Prozessmodellierung

Tamagotchi-Spezifikation in UML

Requirements Engineering

Softwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus

Rückblick: Entity-Relationship-Modell

Analyse und Modellierung von Informationssystemen

UML 2.0 als Architekturbeschreibungssprache? Seminar: Architekturbeschreibungssprachen Manuel Wickert

Warum Anforderungsmanagement. Warum Anforderungsmanagement. 2.1 Grundlagen

Software Engineering Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen

Universität Karlsruhe (TH)

Gliederung des Vortrages

Objektorientierte Geschäftsprozessmodellierung mit der UML

Application Engineering Grundlagen für die objektorientierte Softwareentwicklung mit zahlreichen Beispielen, Aufgaben und Lösungen

Kapitel 2 - Die Definitionsphase

Objektorientierte Softwareentwicklung

DGQ Regionalkreis Hamburg Anforderungsmanagement ins SW-Projekten. 08. Juni 2011

Methoden des Software Engineering

Software-Engineering

Unified Modeling Language

NACHRICHTENTECHNISCHER SYSTEME

Lehrplan: Business Analyse/ Requirements Engineering (BA- RE)

Unit 8: ARIS and IS Modeling

Objektorientierte Analyse & Design

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Ziele und Tätigkeiten von Architekten

Software Engineering. 3. Analyse und Anforderungsmanagement

Vom Störer zum Vermittler

Requirements Engineering (Anforderungstechnik)

Kapitel 1 Applikations-Architektur VI

Basiswissen Requirements Engineering

Das Entwicklungsteam im agilen Prozess. Aufgaben der Software Architektur. Best Practices & Scrum Integration. Zusammenfassung & Ausblick

Ein Benutzerhandbuch als Systemspezifikation halber Aufwand bei doppeltem Nutzen?

[Hier klicken und Text eingeben] [Hier klicken und Text eingeben] Auftragsnummer: [Hier klicken und Text eingeben] Auftragnehmer:

Kapitel 2: Der Software-Entwicklungsprozess

Modellbasierter Test mit der UML. Vortragender: Lars Westmeier Seminar: Spezifikationsbasierter Softwaretest

3.4 Unified Process Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

Unified Modeling Language (UML )

Einführung in die SWE

Einführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren

Jason T. Roff UML. IT Tutorial. Übersetzung aus dem Amerikanischen von Reinhard Engel

Vorlesung Informationssysteme

4. Mentorium. UML-Modellierung (Lösungshinweise)

Objektorientierte Analyse (OOA) Inhaltsübersicht

Objektorientierte Analyse und Design mit der Unified Modelling Language (UML) Sandra Meißl

Von UML 1.x nach UML 2.0

Unified Modeling Language 2

Agilität trifft Funktionale Sicherheit

Vgl. Oestereich Kap 2.1 Seiten

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert

Requirements Engineering

Objektorientierte Analyse

UML Diagramme. Aktivitätsdiagramm

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

Software Engineering

Unified Modeling Language (UML)

17 Architekturentwurf Vorgehen und Dokumentation

13. Qualitätsmanagement Software Engineering

Modellierung und Programmierung 1

Softwareentwicklung und Projektmanagement Teil 2: Objektorientierte Softwareentwicklung WS 05/06

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting

3.2! Anforderungsmanagement

Erfolgreiche Realisierung von grossen Softwareprojekten

Software-Engineering

Softwaretechnik (Allgemeine Informatik) Überblick

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Vorlesung Software Engineering

Comelio GmbH - Goethestr Berlin. Kurskatalog

Einführung in die objektorientierte Programmierung

IT-Projekt-Management

Business-Analyse Probleme lösen, Chancen nutzen

Transkript:

Zusammenfassung 25.5.2016 Was ist Software Engineering? Software Engineering ist die effektive und effiziente Entwicklung und Weiterentwicklung komplexer SW Systeme sowie begleitender Dokumente in einem bewusst arbeitsteilig gestalteten Prozess unter Anwendung bewährter Prinzipien, Methoden und Modellen. Warum haben Analyse und Definition von Anforderungen an das SW System so große Bedeutung im Entwicklungsprozess? Auch heute werden noch die Hälfte aller SW Projekte nicht wie geplant realisiert. 60% der Fehler resultieren aus Fehlern in der Analysephase. Die Behebung von Fehlern aus der Analysephase sind sehr teuer. 1 Was eigentlich sind Anforderungen? 1 IEEE Std 610.12 (1990) 2 1

Was eigentlich sind Anforderungen? 2 Requirement (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documets. (3) A documented representation of a condition or capability as in (1) or (2). Requirement analysis (1) The process of studying user needs to arrive at a definition of system, hardware, or software requirements. (2) The process of studying and refining system, hardware, or software requirements. IEEE Std 610.12 (1990) 3 Was eigentlich sind Anforderungen? 3 «A requirements is something that the product must do or a quality that the product must have.» Robertson, Suzanne/ Robertson, James Mastering the Requirements Process Seite5f Eine Anforderung ist (aus der Sicht des Nutzers) das, was das Produkt tun soll oder die Qualität, die es haben soll funktionale Anforderungen functional requirements nicht funktionale Anforderungen non functional requirements 4 2

Was eigentlich sind Anforderungen? 4 Anforderungen funktionale Anforderungen nicht funktionale Anforderungen Rahmenbedingungen Qualitätsanforderungen technisch/technologische Rahmenbedingungen rechtliche Rahmenbedingungen organisatorische Rahmenbedingungen 5 Was eigentlich sind Anforderungen? 5 Anforderungen funktionale Anforderungen Rahmenbedingungen Qualitätsanforderungen technisch/technologische Rahmenbedingungen rechtliche Rahmenbedingungen organisatorische Rahmenbedingungen Nach: Pohl, Klaus Requirements Engineering- Grundlagen, Prinzipien. Techniken ISBN 978-3-89864-342-9 6 3

Was eigentlich sind Anforderungen? 6 Beispiele aus dem Kontext der HTW Bibliothek: funktionale Anforderung: Eine Person meldet sich als Benutzer an. Qualitätsanforderungen: Das SW System toleriert beim Anmelden mögliche Eingabefehler wie zum Beispiel die versehentliche Eingabe von Text bei der Datumsangabe. rechtliche Rahmenbedingungen: Für die Erfassung, Speicherung und Verarbeitung der Personendaten gilt die aktuelle Fassung des Datenschutzgesetzes. technisch/technologische Rahmenbedingungen: Die Daten werden in einer relationalen Datenbank gespeichert. Zum Einsatz kommt eine Oracle Datenbank. organisatorische Rahmenbedingungen: Eine Person darf sich nur einmal als Benutzer anmelden. 7 Welche Qualitätsmerkmale hat eine SW System? Funktionserfüllung Benutzbarkeit Wirtschaftlichkeit Zuverlässigkeit/Sicherheit SW-Qualität Flexibilität Erweiterbarkeit/Änderbarkeit/Kompatibilität/Portabilität Wiederverwendbarkeit 8 4

Wie kann die Qualität erreicht werden? 1 SW Qualität konstruktive analytische Produkt Qualität Qualität des SW Produktes Qualität des Supportes während des Einsatzes Prozeß Qualität Qualität des SW Entwicklungsprozesses, d.h. Qualität der Teilprozesse: Analyse/Entwurf/Implementierung/ Test/Inbetriebnahme/Wartung integrierte Dokumentation SW Projektmanagement Qualitätssicherung organisatorisch 9 Wie kann die Qualität erreicht werden? 2 SW Qualität Kosten Zeit SW Qualität erfordert Kosten und Zeit. Das will geachtet sein. 10 5

Wie kann die Qualität erreicht werden? 3 Eisberg Effekt : In der Entwicklung gesparte Kosten müssen um ein Vielfaches in der Wartung investiert werden. Analyse Entwurf Implementierung Test/Installation System Entwicklung System Nutzung Einsatz und Wartung 11 Welche Grundprinzipien stehen zur Verfügung? 1 Abstraktion Strukturierung Zerlegung Kapselung Hierarchisierung Standardisierung (integrierte) Dokumentation 12 6

Welche Grundprinzipien stehen zur Verfügung? 2 Abstraktion Booch, Grady Objektorientierte Analyse und Design Addison Wesley, S. 62 13 Welche Grundprinzipien stehen zur Verfügung? 3 Kontext Modell 1 Kontextmodell Funktionen Modell 2 Funktionsmodell Gesamtes System Daten Datenflusss Modell 3 Modell 4 Datenmodell Datenflussmodell Klassen Modell 5 Klassenmodell Zustand Modell 6 Zustandsmodell Modell 7 Untersuchungsziel / Perspektive /Abstraktion 14 7

Welche Grundprinzipien stehen zur Verfügung? 4 Hierarchisierung Booch, Grady Objektorientierte Analyse und Design Addison Wesley, S. 84 15 Welche Grundprinzipien stehen zur Verfügung? 5 Zerlegung Zusammensetzung Booch, Grady Objektorientierte Analyse und Design Addison Wesley, S. 77 16 8

Welche Grundprinzipien stehen zur Verfügung? 6 Kapselung Booch, Grady Objektorientierte Analyse und Design Addison Wesley, S. 7 17 Welche Grundprinzipien stehen zur Verfügung? 7 Persistenz Booch, Grady Objektorientierte Analyse und Design Addison Wesley, S. 103 18 9

Welche Rolle spielen Anforderungen des Kunden im Rahmen der Software Entwicklung? Anforderungen sind Ausgangspunkt der Entwicklung. Daraus resultiert ihre große Bedeutung (sowohl inhaltlich als auch zeitlich). Die Anforderungen verbinden Kunden und Entwickler. Die Anforderungen sind das Maß der Dinge bei der Übergabe des Produktes. 19 Worin bestehen die Risiken der Anforderungsanalyse? Falsche Anforderungen werden ermittelt. Die Anforderungen werden unvollständige ermittelt. Ermittelte Anforderungen sind missverständlich formuliert. Ermittelte Anforderungen sind widersprüchlich. Die Prioritäten sind falsch gesetzt. Die Anforderungen sind umständlich/zu umfangreich beschrieben. Die Anforderungen sind nicht realisierbar. 20 10

Was kennzeichnet eine qualitativ gute Anforderungsanalyse? Korrektheit Vollständigkeit Eindeutigkeit Konsistenz Angemessenheit Minimalität Realiserbarkeit Nachprüfbarkeit 21 Wie kann den Risiken der Anforderungsanalyse begegnet werden? durch laufende Diskussion mit dem Kunden (auch mit den direkten Anwendern) durch bewusste Arbeit mit Prototypen Oberflächenprototyp Wegwerfprototypen experimenteller Prototyp evolutionärer Prototyp durch Wahl von geeigneten Beschreibungsstechniken grafische Modellierungstechniken (werkzeuggestützt) Satzschablonen (nach Chris Rupp) 22 11

zur Erinnerung: Um das Wesen eines Systems (Prozesses,...) zu verstehen, muss zuerst seine Grenze erforscht werden, d.h. sein Kontext und die Interaktion des Systems mit diesem Kontext muss erforscht werden. (vgl. Definition System ) Kontextmodell 23 Erforschung des Systemkontextes und der Interaktion des Systems mit diesem Kontext Eingabedaten Ausgabedaten besser: Eingabedaten Ausgabedaten 24 12

Aber wer oder was gehört zum Kontext? Die Entwicklung eines Systems bzw. Produkts hat das Ziel, die Bedürfnisse mehrerer Personen, Gruppen und Institutionen zu befriedigen, wobei die Bedürfnisse und Ansprüche sehr unterschiedlich, auch gegenläufig und widersprüchlich sein können. All diese Personen und Institutionen bezeichnen wir als Stakeholder. Requirements Engineering und Management Chris Rupp, SOPHIST GROUP Professionelle, iterative Anforderungsanalyse für die Praxis ISBN 3 446 22877 2 Leseprobe, S. 119 25 Beispiel aus dem Kontext der HTW Bibliothek: Stakeholder: Person Benutzer Bibliotheksleiter(in) ( Bibliothekar(in)) Bibliotheksmitarbeiter DV Beauftragter der Bibliothek Träger der Bibliothek (z.b. HTW Dresden) Partnerbibliotheken (für die Fernleihe) Dezernat für Finanzen der HTW Rechenzentrum der HTW (Bereitstellung der Hardware zur Datenspeicherung, Übergabe der Kennung für Studenten ( s nummer ), Partnerbibliotheken, Bibliotheksverbund 26 13

Ziele definieren Voraussetzung: fundierten Kenntnis der Ausgangssituation, Probleme und Optimierungspotenziale der Ausgangssituation Kenntnis der Stakeholder exakte Beschreibung der: erhobenen Ziele, Rahmenbedingungen Systemgrenzen zum Beispiel durch eine kurze, schlagkräftige Metapher Durch die software gestützte Bibliotheksverwaltung sollen die Holzkästen mit den Karteikarten abgelöst werden. Nach Büchern kann jeder zu jeder Zeit an jedem Ort suchen. Jeder Nutzer kann in bestimmten Umfang Ausleihen selbständig verlängern. 27 Leseprobe Requirements Engineering und Management Professionelle, iterative Anforderungsanalyse für die Praxis Chris Rupp, SOPHIST GROUP, Hanser Verlag ISBN 3 446 22877 2 Kapitel 5 Stakeholder, Ziele und der Systemkontext Was muss ich sehr früh für eine Produkt /Systementwicklung klären? Wie finde ich die Ziele und wie stimme ich sie mit allen relevanten Projektbeteiligten ab? Wie finde, kategorisiere und dokumentiere ich die Stakeholder? Was versteht man unter Stakeholder Relationship Management? Wie werden Ziele und Rahmenbedingungen erfasst und dokumentiert? Was ist unter dem Systembegriff zu verstehen? Wie grenze ich den Systemumfang vom Systemkontext ab? 28 14

Welche Aktivitäten gehören zur Anforderungsanalyse? Anforderungen ermitteln ( erheben ) Ermittlungstechniken Anforderungen dokumentieren Beschreibungstechniken Anforderungen validieren und verifizieren Verifikations, Validierungstechniken Anforderungen verwalten Projektverwaltungswerkzeuge 29 Welche Ermittlungstechniken gibt es? befragen ( Interview, Fragebogen, ) beobachten ( Videoaufzeichnung) Kreativitätstechniken Brainstorming (d.h. Dialog statt Diskussion) Perspektiven wechseln Simulationsmodell bauen ( Prototyp) Essenzbildung (Reduktion auf funktionale Anforderung) Nicht Kommuniziertes zur Sprache bringen (Gefahr: nicht kommunizierte Annahmen) Systemarchäologie als Ausgangspunkt (d.h. Dokumentation des Ist Systems) 30 15

Welche Dokumentationstechniken gibt es? 1. Text schreiben. Jeder kann den Text schreiben/lesen. Aber Text ist u.u. interpretierbar, mißverständlich. Ergänzung durch grafische Darstellungen (mit Legende!), Bildschirmabzüge screen shot, Skizzen,. 31 Kommunikation zwischen Menschen...... also auch zwischen Kunde und Entwickler Gedacht ist nicht zwingend gesagt! Gesagt ist nicht zwingend gehört! Gehört ist nicht zwingend verstanden! 32 16

Die vier Aspekte einer Nachricht nach Prof. Alexander Schulz von Thun (von 1975 bis zur Pensionierung 2009 an der Universität Hamburg) u.a. Miteinander reden Bd. 1-3 33 Diese Baumaßnahme finanziert die Deutsche Kreditbank AG 34 34 17

Welche Dokumentationstechniken gibt es? 1. Text schreiben. Jeder kann den Text schreiben/lesen. Aber Text ist u.u. interpretierbar, mißverständlich. Ergänzung durch grafische Darstellungen (mit Legende!), Bildschirmabzüge screen shot, Skizzen,. 2. Standardisierte Modelle bauen. Modellierungssprache muss erlernt werden. (z.b. UML = Unified Modeling Language) 3. Satzschablonen benutzen. verbindet Vorteile von 1 und 2 35 Tabellarische Beschreibung von essenziellen Funktionen essenzielle Funktion: kleinste, von anderen essenziellen Funktionen unabhängige Funktion wiederholbar, ohne dass eine andere ess. Fkt. ausgeführt werden muss hat einen Auslöser (Eingabedaten oder zeitliches Ereignis) hat eine, keine oder mehrere Reaktionen nach außen (Ausgabedaten) 36 18

Interaktion des Systems mit seinem Kontext (Beispiel Bibliothek) Wenn sich eine Person als Benutzer anmeldet, sind folgende Daten zu speichern: Name und Vorname Anschrift, bei Studenten zusätzlich eine Heimatanschrift, wenn vorhanden Geburtsdatum Der Benutzer erhält nach erfolgreicher Anmeldung einen Benutzerausweis. gewünschte Funktion Vorbedingungen Eingabedaten Ausgabedaten Nachbedingungen Invarianten Person als Benutzer anmelden Benutzer abmelden vollständige Eingabedaten, noch nicht angemeldet, Mindestalter Anmeldedaten Benutzerausweis ggf. Absage keine Ausleih /Mahnvorgänge Abmeldedaten Entlastungsschreiben ggf. Absage Benutzerdaten sind gespeichert Benutzerdaten sind archiviert 37 Erforschung des Systemkontextes und der Interaktion des Systems mit diesem Kontext Wenn sich eine Person als Benutzer anmeldet, sind folgende Daten zu speichern: Name und Vorname Anschrift, bei Studenten zusätzlich eine Heimatanschrift, wenn vorhanden Geburtsdatum Der Benutzer erhält nach erfolgreicher Anmeldung einen Benutzerausweis. gewünschte Funktion Vorbedingungen Eingabedaten Ausgabedaten Nachbedingungen Invarianten Person als Benutzer anmelden Benutzer abmelden vollständige Eingabedaten, noch nicht angemeldet, Mindestalter Anmeldedaten Benutzerausweis ggf. Absage keine Ausleih /Mahnvorgänge Abmeldedaten Entlastungsschreiben ggf. Absage Benutzerdaten sind gespeichert Benutzerdaten sind archiviert 38 19

Erforschung des Systemkontextes und der Interaktion des Systems mit diesem Kontext Wenn sich eine Person als Benutzer anmeldet, sind folgende Daten zu speichern: Name und Vorname Anschrift, bei Studenten zusätzlich eine Heimatanschrift, wenn vorhanden Geburtsdatum Der Benutzer erhält nach erfolgreicher Anmeldung einen Benutzerausweis. gewünschte Funktion Vorbedingungen Eingabedaten Ausgabedaten Nachbedingungen Invarianten Person als Benutzer anmelden Benutzer abmelden vollständige Eingabedaten, noch nicht angemeldet, Mindestalter Anmeldedaten Benutzerausweis ggf. Absage keine Ausleih /Mahnvorgänge Abmeldedaten Entlastungsschreiben ggf. Absage Benutzerdaten sind gespeichert Benutzerdaten sind archiviert Benutzer darf sich nur einmal anmelden, d.h. er hat nur eine Benutzernummer 39 39 Erforschung des Systemkontextes und der Interaktion des Systems mit diesem Kontext Wenn sich eine Person als Benutzer anmeldet, sind folgende Daten zu speichern: Name und Vorname Anschrift, bei Studenten zusätzlich eine Heimatanschrift, wenn vorhanden Geburtsdatum Der Benutzer erhält nach erfolgreicher Anmeldung einen Benutzerausweis. gewünschte Funktion Vorbedingungen Eingabedaten Ausgabedaten Nachbedingungen Invarianten Person als Benutzer anmelden Benutzer abmelden vollständige Eingabedaten, noch nicht angemeldet, Mindestalter Anmeldedaten Benutzerausweis ggf. Absage keine Ausleih /Mahnvorgänge Abmeldedaten Entlastungsschreiben ggf. Absage Benutzerdaten sind gespeichert Benutzerdaten sind archiviert Benutzer darf sich nur einmal anmelden, d.h. er hat nur eine Benutzernummer 40 20

Bau von Modellen grafische Darstellungen UML UML Diagramme sind Strukturdiagramme: Sie besitzen Knoten und Kanten. (Syntax und Semantik) Sie haben eine Topologie. Für die Anforderungsmodellierung geeignete Diagramme: Anwendungsfalldiagramm Aktivitätsdiagramm ( > Datenflussdiagramm) Zustandsdiagramm Analyse Klassendiagramm Laborübung 41 21