3. Analysephase - Anwendungsfälle Software Engineering (FB EIT)

Transkript

1 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 /

2 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 /

3 Agenda Motivation und und Übersicht Übersicht Anforderungen Anwendungsfälle Übung Kontrollfragen

4 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 /

5 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 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 /

6 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 /

7 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 /

8 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 /

9 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 /

10 Agenda Motivation und Übersicht Anforderungen Anwendungsfälle Übung Kontrollfragen

11 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 /

12 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 /

13 Agenda Motivation und Übersicht Anforderungen Anwendungsfälle Übung Kontrollfragen

14 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 /

15 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: (Alistair Cockburn) 15 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 /

16 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: 16 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 /

17 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: 17 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 /

18 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: 18 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 /

19 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: 19 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 /

20 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: 20 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 /

21 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: 21 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 /

22 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: 22 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Software Engineering (EIT), WS 2007 /

23 Agenda Motivation und Übersicht Anforderungen Anwendungsfälle Übung Übung Kontrollfragen

24 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 /

25 Agenda Motivation und Übersicht Anforderungen Anwendungsfälle Übung Kontrollfragen

26 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 /