3. Analysephase - Anwendungsfälle Software Engineering (FB EIT) Wintersemester 2007 / 2008 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Einordnung in den gesamten Kurs 1. Einführung 2. Vorgehensmodelle 3. Analyse-Phase: Anwendungsfälle 4. Analyse-Phase: Datenmodell 5. Analyse-Phase: Dialoge 6. Design-Phase 7. Programmierungs-Phase 8. Test- / Integrationsphase, Einführung 9. Aufwandsschätzung 10. Projektmanagement, Qualitätsmanagement 2 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Agenda Motivation und und Übersicht Übersicht Anforderungen Anwendungsfälle Übung Kontrollfragen
Warum Anforderungsanalyse? Selbst kleine Irrtümer in den Anforderungen können zu großen Problemen führen! Quelle: Caliber RM 4 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Motivation Was der Anwender wollte Wie es der Anwender dem Programmierer sagte Wie es der Programmierer verstanden hat Was der Programmierer bauen wollte Was der Programmierer tatsächlich gebaut hat Was der Anwender tatsächlich gebraucht hätte Quelle: J. Siedersleben (Hrsg.): Softwaretechnik, Hanser-Verlag 2002 5 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Das Vorgehen bei der Anforderungsanalyse Erste Schritte: Projektkontext klären Stakeholder identifizieren Ziele festlegen Systemgrenzen festlegen Anforderungen sammeln Anforderungen prüfen Anforderungen verwalten Anforderungen aufschreiben 6 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Stakeholder identifizieren Stakeholder sind alle Menschen, die von Entwicklung, Einsatz und Betrieb des Systems betroffen sind Stake: Stakeholder: Anteil, Beteiligung, Einsatz Der Geschäftsinteressent 7 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Stakeholder sind alle Menschen, die von Entwicklung, Einsatz und Betrieb des Systems betroffen sind Fachbereich Anwender & Anwender IT-Abteilung Betrieb Management Methodenabteilung Projektgegner Experten Altsysteme Experten Nachbarsysteme Betriebsrat Alle relevanten Stakeholder sind zu identifizieren und mit ihren Rollen zu dokumentieren Ein vergessener Stakeholder ist eine vergessene Anforderung! 8 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Bausteine der Analysephase (Fachkonzept) Anforderungen Zentrale Ziele und Rahmenbedingungen Funktionale Anforderungen Projektanforderungen Nichtfunktionale Anforderungen Einführungsanforderungen Migrationsanforderungen Dialog-Gestaltungsvorgabe Betriebsanforderungen Fachliche Gestaltung Verhalten Geschäftsprozesse Anwendungsfälle Anwendungsfunktionen Fachlicher Überblick Struktur Domänen & Komponenten Logisches Datenmodell & Datentypverzeichnis Interaktion Dialoge Druckausgaben Nachbarsystem-Schnittstellen Batchverarbeitung Querschnittskonzepte und Dienste Glossar Quelle: sd&m Research 9 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Agenda Motivation und Übersicht Anforderungen Anwendungsfälle Übung Kontrollfragen
Bausteine zu den Anforderungen Anforderungen Zentrale Ziele und Rahmenbedingungen Funktionale Anforderungen Projektanforderungen Nichtfunktionale Anforderungen Einführungsanforderungen Migrationsanforderungen Dialog-Gestaltungsvorgabe Betriebsanforderungen Fachliche Gestaltung Verhalten Geschäftsprozesse Anwendungsfälle Anwendungsfunktionen Fachlicher Überblick Struktur Domänen & Komponenten Logisches Datenmodell & Datentypverzeichnis Interaktion Dialoge Druckausgaben Nachbarsystem-Schnittstellen Batchverarbeitung Querschnittskonzepte und Dienste Glossar Quelle: sd&m Research 11 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Anforderungen, Leistungsausgrenzungen und Prämissen Konzepte Anforderungen Nummerierte Liste präziser Beschreibungen in Satzform, was der Umfang des Systems ist (funktional und nicht-funktional) Leistungsausgrenzungen Nummerierte Liste von Beschreibungen in Satzform, welche Funktionen das System explizit nicht abdeckt Beispiele A2: Die Registrierung von Neukunden, die Änderung von Kundendaten und das Abmelden von Kunden soll unterstützt werden. A42: Alle Pflegedialoge sollen ein Antwortzeitverhalten < 1 s haben L1: Die Reservierung von Fitnessräumen wird nicht vom System unterstützt. Diese erfolgt weiterhin auf Papier Prämissen Nummerierte Liste von Beschreibungen in Satzform, welche Voraussetzungen für die erfolgreiche Projektdurchführung erfüllt sein müssen P1: Zur erfolgreichen Durchführung des Projekts muss der Manager des Fitness- Centers jede Woche mindestens 4h für Besprechungen verfügbar sein. 12 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Agenda Motivation und Übersicht Anforderungen Anwendungsfälle Übung Kontrollfragen
Bausteine zum Verhalten: Anwendungsfälle Anforderungen Zentrale Ziele und Rahmenbedingungen Funktionale Anforderungen Projektanforderungen Nichtfunktionale Anforderungen Einführungsanforderungen Migrationsanforderungen Dialog-Gestaltungsvorgabe Betriebsanforderungen Fachliche Gestaltung Verhalten Geschäftsprozesse Anwendungsfälle Anwendungsfunktionen Fachlicher Überblick Struktur Domänen & Komponenten Logisches Datenmodell & Datentypverzeichnis Interaktion Dialoge Druckausgaben Nachbarsystem-Schnittstellen Batchverarbeitung Querschnittskonzepte und Dienste Glossar Quelle: sd&m Research 14 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Anwendungsfälle (Use Cases) Anwendungsfälle (Use Cases) <Use Case Name> Beschreiben die Interaktionen eines Benutzers mit einem System sind immer von einem Ziel des Benutzers getrieben sind aus Benutzersicht beschrieben repräsentieren möglichst in sich abgeschlossene Handlungsfolgen (Zielerreichung!) Heuristik: Wenn der Nutzer nach Abschluss des Use Cases einen Schluck Kaffee trinken würde/könnte, hat er in etwa die richtige Größe Siehe auch: www.usecases.org (Alistair Cockburn) 15 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Ziele auf verschiedenen Ebenen Granularität von Anwendungsfällen Wolkenebene: Langfristige Ziele Die Patienten versorgen Drachenebene: Mittelfristige Ziele Die Stationen mit Medikamenten beliefern Wellenebene: Nutzerziele Eine Bestellung kommissionieren Wir interessieren uns für f r Nutzerziele Fischebene: Handlungsziele Eine Ware in den Karton legen Muschelebene: Schrittziele Den Bestätigungsknopf drücken Quelle: www.musoft.org 16 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
UML Anwendungsfall- (Use Case) Diagramme System: Das System, das benutzt wird (gekennzeichnet durch Systemgrenze) Auftragssystem Stationsschwester Auftrag erfassen Actor: Der Die Nutzer der Nutzerin der Funktionalität Use Case (Anwendungsfall): Beschreibung einer fachlichen Funktionalität Quelle: www.musoft.org 17 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
UML Use Case Diagramme Aktoren Aktoren sind Rollen Lagerist Eine (reale) Person kann mehrere Rollen einnehmen (auch gleichzeitig) Eine Rolle kann von verschiedenen (realen) Personen eingenommen werden Aktoren können auch nicht-menschlich sein DHC-Steuerung <<actor>> Andere Systeme können unser System benutzen (primäre Aktoren) Unser System kann auf andere Systeme zurückgreifen (sekundäre Aktoren) Quelle: www.musoft.org 18 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
UML Use Case Diagramme Aktoren Aktoren können kooperieren Der Use Case Kommissioniervorgang durchführen erfordert Interaktionen mit dem Lageristen und der DHC Steuerung Verwaltung-DemagHorizontalCarrussel (V-DHC) Lagerist Kommissioniervorgang durchführen DHC-Steuerung <<actor>> Quelle: www.musoft.org 19 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Und was ist jetzt das Use Case Diagramm für das Beispiel? V-DHC Kommissioniervorgang durchführen Lagerist Waren einlagern Bestandsanfrage DHC-Steuerung <<actor>> Warenwirtschaftssystem (WWS) <<actor>> Auftrag zur Kommissionierung einstellen Quelle: www.musoft.org 20 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Beschreibung von Anwendungsfällen Use Case Diagramm: Gibt einen Überblick über die Funktionalitäten des Systems und die beteiligten Nutzer. Charakterisierende Informationen: Tabelle mit Details zu einem Use Case, einschließlich Hauptund Alternativszenarien GUI-Skizzen: Jedes Szenario kann von einer GUI-Skizze begleitet sein. Aktivitätendiagramm: Der allgemeine Ablauf des Use Cases (Vereinigung der Szenarien) kann in einem Aktivitätendiagramm dargestellt werden Quelle: www.musoft.org 21 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Charakterisierende Informationen eines Anwendungsfalls Name: Ziel: Auslöser: Vorbedingung: Szenarien: Kommissioniervorgang durchführen Die in den Aufträgen eines KVs bestellten Waren zum Versand an die Empfänger zusammenstellen. Lagerist ruft nächsten KV auf KV vorhanden und zur Bearbeitung freigegeben 1. Warenliste besorgen 2. Alle Waren zusammenstellen 3. Kartonieren Ergebnis: Bemerkungen: 4. Adressieren und frankieren KV abgeschlossen und Kisten bereit für Versand keine Quelle: www.musoft.org 22 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Agenda Motivation und Übersicht Anforderungen Anwendungsfälle Übung Übung Kontrollfragen
Hörsaalübung Legen Sie eine Anwendungsdomäne als Beispiel für das gesamte Semester fest Erstellen Sie die Anforderungen, Leistungsausgrenzungen und Prämissen Entwickeln Sie die relevanten Akteure und Anwendungsfälle 24 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007
Agenda Motivation und Übersicht Anforderungen Anwendungsfälle Übung Kontrollfragen
Kontrollfragen Warum ist die Anforderungsanalyse wichtig? Welche Schritte sind in der Anforderungsanalyse durchzuführen? Was ist ein Stakeholder? Nennen Sie Beispiele! Was sind die Ergebnisse der Anforderungsanalyse Was sind Anforderungen / Leistungsausgrenzungen / Prämissen? Nennen Sie Beispiele! Was sind Anwendungsfälle? Nennen Sie Beispiele! Wie werden Anwendungsfälle beschrieben? 26 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 / 2008. 29.10.2007