Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, HS 2010

Transkript

1 Software Engineering 3. Anforderungsanalyse Franz-Josef Elmer, Universität Basel, HS 2010

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. Diese sind z.b.: Resourcenverbrauch (Zeit, Speicher, IO Kanäle, etc.) Programmiersprache und Technologie Entwicklungsprozess Anwendungsfall (Use Case): Beschreibung einer funktionalen Anforderung im Hinblick auf ein Benutzerziel. Spezifikation: Technische Konkretisierung der Anforderungen.

3 Software Engineering: 3. Anforderungsanalyse 3 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

4 Software Engineering: 3. Anforderungsanalyse 4 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!

5 Software Engineering: 3. Anforderungsanalyse 5 Anwendungsfälle (Use Cases) 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)

6 Software Engineering: 3. Anforderungsanalyse 6 Use Case: Stakeholders und Interessen Ein Use Case beschreibt ein Ziel welches der Hauptakteur erreichen will. Dies ist das klassische Akteur-Ziel Paradigma. Eine alternative Sicht ist das Stakeholders-Interessen Paradigma: Ein Use Case beschreibt wie die Software die Interessen aller Stakeholders wahrt.

7 Software Engineering: 3. Anforderungsanalyse 7 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. Dasselbe falls der Use Case fehlschlägt, d.h. Garantie falls Fehlschlag: 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.

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; Express- oder Normalversand). 4.System zeigt Gesamtpreis inklusive Versandkosten. 5.Kunde gibt seine Kreditkartendaten an. 6.System autorisiert den Verkauf. 7.System gibt sofort eine Bestätigung aus. 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 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 Ziel ab? 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?

12 Software Engineering: 3. Anforderungsanalyse 12 Beispiel: Blog Service Blog Service: Eine Web Applikation für Blogger. Jeder Blog hat einen Namen, gehört einem angemeldete Benutzer, hat beliebig viele Einträge mit beliebig vielen Leserkommentaren zu einem Eintrag. Jeder Webbenutzer kann alle Blogs und Kommentare lesen. Jeder angemeldete Benutzer kann genau einen Blog einrichten oder zu einem Blogeintrag einen Kommentar schreiben. Ein Administrator sorgt dafür, dass die Netiquette eingehalten werden. Alle Benutzer, die dagegen verstossen, werden gesperrt. Ihre Blogs und Kommentare können nicht mehr gelesen werden.

13 Software Engineering: 3. Anforderungsanalyse 13 Blog Service: Akteure und Use Cases Akteure: Leser Registrierter Benutzer Administrator Use Cases: 1. Blog lesen 2. Benutzer registrieren 3. Benutzer authentifizieren 4. Blog erzeugen 5. Blog Eintrag schreiben 6. Blog Eintrag kommentieren 7. Registrierten Benutzer sperren

14 Software Engineering: 3. Anforderungsanalyse 14 Beispiel: Blog Service UC1 UC1: Blog lesen Hauptakteur: Leser Hauptszenario: 1. Leser gibt die URL des Blog Services ein. 2. System liefert die Einstiegsseite mit der Liste aller Blogs. 3. Leser klickt auf einen Blog. 4. System zeigt den ausgewählten Blog mit den Titeln aller Einträge sowie die Zahl der Kommentare. 5. Der Leser kann einen Eintrag auswählen und lesen. 6. Der Leser kann alle Kommentare zu diesem Eintrag lesen.

15 Software Engineering: 3. Anforderungsanalyse 15 Beispiel: Blog Service UC2 UC2: Benutzer registrieren Hauptakteur: Leser Garantie falls erfolgreich: Neuer Benutzer registriert Garantie falls Fehlschlag: Kein neuer Benutzer registriert Hauptszenario: 1. Leser gibt die URL des Blog Services ein. 2. System liefert die Einstiegsseite mit Registrierungslink. 3. Leser klickt auf diesen Link. 4. System zeigt das Registrierungsformular. 5. Leser macht alle notwendigen Angaben (voller Name, Blogger Name, ) und schickt das Formular ab. 6. System überprüft die Angaben, registriert den neuen Benutzer und schickt ihm via das Passwort. Erweiterungen: 6a: Blogger Name gibt es schon 1. Zurück zu Schritt 5 um anderen Namen einzugeben

16 Software Engineering: 3. Anforderungsanalyse 16 Beispiel: Blog Service UC3 UC3: Benutzer authentifizieren Hauptakteur: Registrierter Benutzer Garantie falls erfolgreich: Benutzer ist authentifiziert Garantie falls Fehlschlag: Benutzer nicht authentifiziert Hauptszenario: 1. Benutzer gibt die URL des Blog Services ein. 2. System liefert die Einstiegsseite mit Login Formular. 3. Benutzer gibt Blogger Name und Passwort ein. 4. System zeigt Einstiegseite plus Begrüssung des Benutzers mit seinem vollen Namen. Erweiterungen: 4a: Authentifizierung schlägt fehl: 1. Statt Begrüssung erscheint Fehlermeldung.

17 Software Engineering: 3. Anforderungsanalyse 17 Beispiel: Blog Service UC4 UC4: Blog erzeugen Hauptakteur: Registrierter Benutzer Garantie falls erfolgreich: Blog erzeugt Garantie falls Fehlschlag: Blog existiert bereits Hauptszenario: 1. Registrierter Benutzer authentifiziert sich (UC3). 2. System liefert die Einstiegsseite mit Link zum Erzeugen seines Blogs. 3. Benutzer klickt auf diesen Link. 4. System zeigt ein Formular. 5. Benutzer macht alle notwendigen Angaben (Titel, Kurze Beschreibung) und schickt das Formular ab. 6. System erzeugt neuen Blog und zeigt ihn dem Benutzer. Erweiterungen: 2a: Benutzer hat schon seinen Blog erzeugt 1. Kein Blogerzeugungslinks. Schritte 3-6 entfallen.

18 Software Engineering: 3. Anforderungsanalyse 18 Beispiel: Blog Service UC5 UC5: Blog Eintrag schreiben Hauptakteur: Registrierter Benutzer Vorbedingung: Blog für den Benutzer existiert Garantie falls erfolgreich: Neuer Eintrag. Hauptszenario: 1. Registrierter Benutzer authentifiziert sich (UC3). 2. System liefert die Einstiegsseite mit Link auf sein Blog. 3. Benutzer klickt auf diesen Link. 4. System zeigt komplettes Blog (wie für Akteur Leser) plus Link für die Seite zur Erzeugung eines neuen Eintrags. 5. Benutzer klickt auf diesen Link. 6. System zeigt Formular mit Feld für den Titel und ein mehrzeiliges Texteingabefeld für den Inhalt. 7. Benutzer schreibt den neuen Eintrag und schickt ihn ab. 8. System zeigt den Blog mit dem neuen Eintrag.

19 Software Engineering: 3. Anforderungsanalyse 19 Beispiel: Blog Service UC6 UC6: Blog Eintrag kommentieren Hauptakteur: Registrierter Benutzer Garantie falls erfolgreich: Neuer Kommentar Hauptszenario: 1. Registrierter Benutzer authentifiziert sich (UC3). 2. System liefert die Einstiegsseite mit allen Blogs. 3. Benutzer wählt ein Blog. 4. System zeigt Blog. 5. Benutzer wünscht die Kommentare zu einem Eintrag. 6. System zeigt alle Kommentare (wie für Akteur 'Leser') und eine mehrzeiliges Texteingabefeld für einen neuen Kommentar. 7. Benutzer gibt Kommentar eine und schickt ihn ab. 8. System zeigt all Kommentar inklusive neuen Kommentar.

20 Software Engineering: 3. Anforderungsanalyse 20 Beispiel: Blog Service UC7 UC7: Registrierten Benutzer sperren Hauptakteur: Administrator Garantie falls erfolgreich: Blog und Kommentare des gesperrten Benutzers werden nicht angezeigt Hauptszenario: 1. Administrator gibt die URL der Admin Page ein. 2. System zeigt Authentifizierungformular. 3. Administrator gibt Login Name und Passwort ein. 4. System zeigt all Benutzer. 5. Administrator wählt einen Benutzer zur Sperrung aus. 6. System verlangt eine Bestätigung der Sperrung durch das Administrator Passwort. 7. Nach der Bestätigung werden Blog und Kommentare des Benutzers sofort gesperrt.

21 Software Engineering: 3. Anforderungsanalyse 21 Use Case Diagramme? Leser Blog lesen authentifizieren <<include>> Blog Eintrag schreiben Benutzer Wenig informative: Nur Verknüpfung Akteure und Use Cases Nützlich nur für Übersicht Test zyklische Abhängigkeiten von Use Cases

22 Software Engineering: 3. Anforderungsanalyse 22 Links Wikipedia: Use Cases Alistair Cockburn: Use Cases, ten years later (2002)