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

Transkript

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

2 Software Engineering: 3. Anforderungsanalyse 2 Definitionen Anforderungen (Requirements): Beschreibung aller Leistungen, die die zu erstellende Software erbringen soll. Funktionale Anforderungen: Beschreibung was die Software in bestimmten Situationen bzw. Eingaben tun soll. Nichtfunktionale Anforderungen: Anforderungen, die über die Funktionalität der Software hinausgeht. Beispiele: Das System unterstützt Volltextsuche. Benutzeranfragen müssen in weniger als 5 Sekunden beantwortet werden. Die Applikation muss mit IE und Firefox funktionieren. Jede Transaktion muss protokolliert werden. Pro Jahr kommen ca Dokumente hinzu. funktional nichtfunktional nichtfunktional funktional nichtfunktional

3 Software Engineering: 3. Anforderungsanalyse 3 Spezifikation Konkretisierung der Anforderungen. Beispiel: Anforderung: Der Benutzer gibt das Lieferdatum ein. Spezifikation: Das Eingabefeld für das Lieferdatum ist ein Textfeld mit freier Eingabe. Es ist mit dem momentanen Datum vorbelegt. Das Datum kann auch über ein Kalender Tool (Details Kapitel x.y.z) eingegeben werden. Es wird client-seitig überprüft, ob der Inhalt des Textfeldes tatsächlich ein Datum ist.

4 Software Engineering: 3. Anforderungsanalyse 4 Anforderungsanalyse Anforderung ermitteln Dialog zwischen Kunde bzw. Anwender und Entwickler Interviews mit Anwendern Machbarkeit evaluieren Anforderungen dokumentieren Kurzfassung für das Management Benutzerrollen Use Cases Fachglossar Klassendiagramm der Beziehungen zwischen Fachelementen Zustandsdiagramm für komplexe Lebenszyklen Anforderungen validieren Spezifikation schreiben Technologische Lösungsvorschläge, grobe Architektur Zerlegung in sinnvolle Pakete für eine iterative Entwicklung Abhängigkeiten zwischen den Paketen ermitteln Aufwand abschätzen

5 Software Engineering: 3. Anforderungsanalyse 5 Anforderungen validieren Anforderungen an die Anforderungen: Verständlich: Kunde, Benutzer und Entwickler müssen die Anforderungen verstehen. Kein softwaretechnischer Jargon. Glossar der Fachbegriffe Konsistent: Keine logischen Widersprüche oder Mehrdeutigkeiten. Explizit: Alle Anforderungen müssen explizit beschrieben sein. Keine impliziten Annahmen. Realisierbar: Die Anforderungen müssen technisch, personell und finanziell realisierbar sein. Nachprüfbar: Aus den Anforderungen sind Akzeptanztests ableitbar. Kurz und bündig: Keine Romane!

6 Software Engineering: 3. Anforderungsanalyse 6 Use Case: The name of the game Die korrekte Rückübersetzung von Use Case lautet: A Geschäftsprozess B Geschäftsfall C Anwendungsfall D Gebrauchsfall Aus dem schwedischen Anvendningsfall Use Case

7 Software Engineering: 3. Anforderungsanalyse 7 Use Case: Definition Beschreibung typischer Interaktionen zwischen Benutzer und dem Softwaresystem. Jeder Use Case hat ein Ziel welches der Benutzer (Hauptakteur) erreichen will. Akteur: Eine Rolle, die der Benutzer (Mensch oder Maschine) im Hinblick auf das System spielt. Akteure sind immer ausserhalb des Systems. Ein Akteur ist in einem oder mehreren Use Cases beteiligt. Ein Use Case hat einen Hauptakteur und eventuell weitere Nebenakteure. Szenario: Eine Folge von Schritten, die eine Interaktion beschreiben. Ein Use Case hat ein Hauptszenario und eventuell mehrere Erweiterungen (Nebenszenarios)

8 Software Engineering: 3. Anforderungsanalyse 8 Use Cases: Beispiel UC13: Artikel kaufen Hauptakteur: Kunde Nebenakteure: keine Hauptszenario: 1.Kunde stöbert durch den Katalog (UC6) und wählt Artikel (UC8). 2.Kunde geht zur Kasse. 3.Kunde gibt Versandinformationen an (Adresse; Expressoder Normalversand). 4.System zeigt Gesamtpreis inklusive Versandkosten. 5.Kund gibt seine Kreditkartendaten an. 6.System autorisiert den Verkauf. 7.System gibt sofort eine Bestätigung 8.System sendet eine Bestätigung als an den Kunden.

9 Software Engineering: 3. Anforderungsanalyse 9 Use Cases: Beispiel (Fortsetzung) Erweiterungen: 3a: Der Kunde ist Stammkunde 1.System zeigt aktuelle Versand-, Preis- und Rechnungsdaten an. 2.Kunde kann diese Voreinstellungen ändern oder akzeptieren. 3.Weiter mit Schritt 6 des Hauptszenarios 6a: Autorisierung fehlgeschlagen 1.Kunde kann abbrechen oder seine Kreditkartendaten erneut eingeben.

10 Software Engineering: 3. Anforderungsanalyse 10 Use Cases schreiben Einfach zu lesen. Kurz und klar, nicht zu viele Schritte. Ein Use Case muss ein Ziel haben. Keine Benutzerschnittstelle beschreiben.

11 Software Engineering: 3. Anforderungsanalyse 11 Use Case: Stakeholders und Interessen Ein Use Case beschreibt ein Ziel welches der Hauptakteur erreichen will. Dies ist das klassische Akteur-Ziel Paradigma. Use Cases im Stakeholders-Interessen Paradigma A sind Beschreibungen, die den Stakeholders zeigen, welcher ihrer Interessen (Ziele) wie erreicht werden. B zeigen welche Interessen der Stakeholders hinter den Zielen stecken. C zeigen welche Akteure (Stakeholders) welche Interessen (Ziele) haben. D sind Beschreibungen, wie die Software die Interessen aller Stakeholders wahrt.

12 Software Engineering: 3. Anforderungsanalyse 12 Use Case Diagramme? Katalog durchstöbern «include» Artikel kaufen «include» Kunde Artikel wählen Wenig informative: Nur Verknüpfung Akteure und Use Cases Nützlich nur für Übersicht Test zyklische Abhängigkeiten von Use Cases

13 Software Engineering: 3. Anforderungsanalyse 13 Use Case Template Use Case Nummer: Bezeichnung Die Bezeichnung sagt ganz knapp was getan wird. Ziel: Längere Beschreibung des Ziels, falls Bezeichnung nicht klar genug. Hauptakteur: Der Akteur, der das Ziel erreichen will Nebenakteure: Akteure, die an der Erreichung des Ziels beteiligt sind. Vorbedingung: Erwarteter Systemzustand bevor der Use Case beginnt. Auslöser: Auslösendes Ereignis. Garantie falls erfolgreich: Beschreibung was das System am Ende eines erfolgreichen Use Cases garantieren muss. Garantie falls Fehlschlag: Dasselbe falls der Use Case fehlschlägt, d.h. das Ziel nicht erreicht wird. Hauptszenario: Beschreibung des schrittweisen Ablaufs. Jeder Schritt ist eine Aktion eines Akteurs oder des Systems. Erweiterungen: Beschreibung von Erweiterungen oder Alternativen zu einzelnen Punkte des Hauptszenarios. Offene Punkte: Auflistung noch offener Entscheidungen bezüglich dieses Use Cases.

14 Software Engineering: 3. Anforderungsanalyse 14 Use Cases validieren Checkliste: Ist der Use Case komplett? Fehlen wichtige Schritte? Wird das Ziel des Hauptakteurs erreicht? Decken die Erweiterungen alle möglichen Fehlschläge zur Erreichung des Zieles ab? Decken die Use Cases alle wichtigen Ziele ab? Werden die Interessen der Stakeholders gewahrt? Gibt es sehr ähnliche Use Cases? Können diese zusammengefasst werden? Gibt es zyklische Abhängigkeiten zwischen Use Cases? Können Use Cases durch leichte Änderung der Anforderungen vereinfacht werden?