Software Engineering. 2. Requirements Engineering. Franz-Josef Elmer, Universität Basel, HS 2012

Transkript

1 Software Engineering 2. Requirements Engineering Franz-Josef Elmer, Universität Basel, HS 2012

2 Software Engineering: 2. Requirements Engineering 2 Definitionen Anforderungen (Requirements) legen fest, was man von einem Softwaresystem als Eigenschaften erwartet. Balzert: Lehrbuch der Softwaretechnik Funktionale Anforderung legen eine vom Softwaresystem oder einer seiner Komponenten bereitzustellende Funktion oder Service fest. Balzert: Lehrbuch der Softwaretechnik Nichtfunktionale Anforderungen: Alle anderen Anforderungen, wie z.b.: Resourcenverbrauch (Zeit, Speicher, IO Kanäle, etc.) Qualität (Zuverlässigkeit, Sicherheit, Wartbarkeit, etc.) Entwicklungsprozess Anwendungsfall (Use Case): Beschreibung einer funktionalen Anforderung im Hinblick auf ein Benutzerziel. Spezifikationen geben vor wie die Anforderungen technische umgesetzt werden sollen. Welcher Input führt zu welchem/r Output/Zustandsänderung.

3 Software Engineering: 2. Requirements Engineering 3 Anforderungsanalyse Anforderung ermitteln Dialog zwischen Kunde bzw. Anwender und Entwickler Interviews mit Anwendern Machbarkeit evaluieren Normen und Standards berücksichtigen Anforderungen dokumentieren (Pflichtenheft) Kurzfassung für das Management (Welche Ziele sollen erreicht werden?) Benutzerrollen (Wer/was interagiert mit dem Softwaresystem?) Use Cases (Was sind die Interaktionsszenarien?) Fachglossar (Wie sind Fachbegriffe definiert?) Anforderungen validieren Spezifikationen schreiben (Lastenheft) Technologische Lösungsvorschläge: grobe Architektur Klassendiagramm der Beziehungen zwischen Fachelementen Zustandsdiagramme für komplexe Lebenszyklen Zerlegung in sinnvolle Pakete Abhängigkeiten zwischen den Paketen ermitteln Aufwand abschätzen

4 Software Engineering: 2. Requirements Engineering 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: 2. Requirements Engineering 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: 2. Requirements Engineering 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: 2. Requirements Engineering 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: 2. Requirements Engineering 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: 2. Requirements Engineering 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 4.Kunde kann abbrechen oder seine Kreditkartendaten erneut eingeben.

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

11 Software Engineering: 2. Requirements Engineering 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: 2. Requirements Engineering 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: 2. Requirements Engineering 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: 2. Requirements Engineering 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: 2. Requirements Engineering 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: 2. Requirements Engineering 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: 2. Requirements Engineering 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: 2. Requirements Engineering 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: 2. Requirements Engineering 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ählt 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: 2. Requirements Engineering 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: 2. Requirements Engineering 21 Use Case Diagramme Leser Blog lesen authentifizieren <<include>> Blog Eintrag schreiben Benutzer Ein UML Diagrammtyp Nützlich nur für Übersicht Test zyklische Abhängigkeiten von Use Cases

22 Software Engineering: 2. Requirements Engineering 22 Aufwandsschätzungen Die Schätzung des Aufwands zur Durchführung eines Softwareprojektes ist essentiell für die Kosten des Projekts die zeitliche Planung (Milestones) den personellen Aufwand Aufwandsschätzung beruht auf Erfahrung. Die meisten Schätzverfahren gehen prinzipiell so vor: Zerlegung der gesamten Aufgabe in Teilaufgaben. Jede Teilaufgabe ist ähnlich einer Aufgabe, deren Aufwand aus Erfahrung bekannt ist. Summierung über den Aufwand aller Teilaufgaben. Der Aufwand wird oft unterschätzt: Teilaufgaben wurden vergessen (z.b. Testing, Dokumentation) Teilaufgaben wurden als zu einfach eingeschätzt. Es gibt unerwartete technische Probleme. Es gibt keine vergleichbaren Erfahrungen. Einarbeitungszeit in neue Technologien wurde nicht berücksichtigt. Grosse Unterschiede der Produktivität im Team.

23 Software Engineering: 2. Requirements Engineering 23 Links Alistair Cockburn: Use Cases, ten years later (2002) Giovanni Asproni: Fingers in the air: a Gentle Introduction to Software Estimation (2008)