Requirements Engineering Vortragender: David Kurmann 2. Teil April 2008 Autor: Antoine Hauck

Transkript

1 Requirements Engineering Vortragender: David Kurmann 2. Teil April 2008 Autor: Antoine Hauck Inhaltsverzeichnis 1 Rückblick Dokumentierung/Spezifizierung Vorgehehensmodelle Beschreibungsarten Dokumentationsmethoden Vorgehensstrategie Textuelle Modelle Anforderungen in natürlich Sprache Formale Text-Anforderung Volere Template Glossar Grafische Modelle Modell-Arten Kontext-Diagramm Actor-Map Use-Case Anwedungsfall UML Diagramm Aktivitätsdiagramm UML Diagramm Zustandsdiagramm UML-Diagramm Sequenzdiagramm... 8 S e i t e 1 / 8

2 1 Rückblick Was ist Req. Engineering? - Kommunikation - Anforderungs-Stufen: Businness, User, System - Stakeholder - Systemgrenze - Dokumentierte Entscheidungen - Problemraum versus Lösungsraum (Problem beschreiben, nicht die Lösung) - Iterativer Prozess Strukturierung (Kreislauf) von Req. Engineering: - Requirements Management (wie managen wir die Anforderungen?) - Requirements Development (Entwickeln von Requirements) o Erheben o Analyse o Validieren o Spezifizieren 2 Dokumentierung/Spezifizierung - Textbasierte Werkzeuge - Modellbasierte Werkzeuge 2.1 Vorgehehensmodelle - Code & Fix: Implementieren und evtl. aufkommende Fehler beheben - Wasserfallmodell: SW-Konzept Spezifikation... Systemtest o Sequentielles Modell o Für kleine Projekte in Ordnung o Für grössere Projekte eher ungeeignet - RUP o Teilt die Arbeit in neue Disziplinen auf Business Modeling, Deployment, Umgebung etc. o Grobes Phasenmodell (Inception, Elaboration, Construction, Transition) Eine Phase beinhaltet eine oder mehrere Iterationen o Iteratives, inkrementelles Vorgehen Inkrementell, da immer mehr Funktionalität hinzugefügt wird 2.2 Beschreibungsarten - Informal: Natürliche Sprache, verschiedene Interpretationsarten - Formal: Bspw. Mathematik ist eine formale Sprache, geregelt, wenig Interpretationsarten 2.3 Dokumentationsmethoden - Domainmodell S e i t e 2 / 8

3 - Aktivitätsdiagramme - Glossar - Use-Case Modell - Glossar - GUI Layout 2.4 Vorgehensstrategie Vision & Ziele (textuell) Kontextabgrenzung (grafisch) Use Case Modellierung (grafisch) Use Case Beschreibung (textuell) und/oder Verhaltensmodellierung (grafisch) Datenmodellierung (Klassendiagramm, grafisch) und/oder Anforderungen in natürlicher Sprache (textuell) 2.5 Textuelle Modelle Anforderungen in natürlich Sprache - Einfach zu verstehen - Einfach zu handhaben - Anfällig auf Mehrdeutigkeit - Man weiss nicht, ob man alles verstanden hat, ob die Anforderung komplett ist - Werden gross für grosse Systeme Regeln - Kurze Sätze schreiben - Gut strukturieren, klare Kapitel - Eine Anforderung pro Satz o Alle geforderten Qualitäten in einen Untersatz verpacken - Bei komplizierten Zusammenhängen: Einsatz von Pseudocode oder Entscheidungstabellen Formale Text-Anforderung Anforderungsschablone (Sophist-Regelwerk) Wie soll ein Satz genau aussehen? Beispiel: Wenn der Bankkunde Geld beziehen will, muss der Bank-o-mat fähig sein, Banknoten im Betrag von 50 CHF bis 1000 CHF auszugeben Übung Innerhalb von 7 Minuten soll jeder Student drei Anforderungssätze zum Sushi-Automaten erstellen S e i t e 3 / 8

4 Antworten: - Wenn der Benutzer ein Sushi kaufen will, soll das System ihm die Möglichkeit bieten, ein Sushi seiner Wahl zu beziehen. - Jeder Verkauf muss vom Sushi-Automat protokolliert werden - Der Geschäftsbesitzer wird pro verkaufte Sushi-Einheit vom Sushi-Automaten mind. 20 Rp. verdienen Volere Template Weisses A5-Blatt wo man eine Anforderung beschreiben kann Folgende Elemente sind notwendig: - Nummerierung: Bsp Beschreibung: Bsp. Der Status jeder Flug-Reservation ist sichtbar - Begründung: Bsp. Es ist wichtig, dass das System weiss, wie es mit Reservationen zu verfahren hat - Quelle: Bsp. Firmen-Prozess Kunden-Flugblatt - Fit-Kriterium: Bsp. Jede Reservation braucht einen akkuraten Statuswert, in dem ersichtlich ist, ob eine Reservation Vorläufig, Gebucht, Bezahlt, Ticket-Ausgestellt, Eingecheckt, im Flug, Geflogen, Abgeschlossen oder Annuliert ist. - Kunden-Zufriedenheit: Bsp. Anzahl zufriedene Kunden - Kunden-Unzufriedenheit: Bsp. Anz. Unzufriedene Kunden - Abhängigkeit: Bsp Konflikt - Kommentare - Geschichte Glossar - Begriffe und Definitionen sind grundlegend o Bsp. für Sushi-Automaten Sushi Sushi-Arten Automat Japan-Food-Company-Card Kochwerk Konsument des Monats Portion Betreiber Zentrale Benutzer = Konsument - Definition von speziellen Begriffen für das Projekt - Glossar möglichst früh im Projekt erstellen - Zujedem Begriff eine dazugehörige Erklärung und evtl. eine Abkürzung S e i t e 4 / 8

5 2.6 Grafische Modelle Modell-Arten - Verhalten o Orientiert sich an Prozessen, Aufgaben oder Abläufen - Struktur o Komponenten und deren Beziehungen (statische Modelle) Domain-Modelle, Klassendiagramme - Dynamik o Wie verändern sich Dinge über die Zeit Ereignis-Tabellen, Zustandsdiagramme - Überwachung o Entscheidungen und Vorschriften Business Regeln, Entscheidungstabelle Modelle reduzieren die Welt, als würde man durch eine Brille blicken. In einem Projekt macht es durchaus Sinn mehrere Modell-Arten zu verwenden Kontext-Diagramm Wird nicht näher darauf eingegangen Actor-Map Übung anhand des Sushi-Automaten Beispiels Auflistung von direkten und indirekten Benutzer eines Systems (Aktoren). Es soll eine hierarchische Aufteilung entstehen. S e i t e 5 / 8

6 2.6.4 Use-Case Anwedungsfall - Modellierung von Verhalten - Eine Interaktion zwischen einem Benutzer (Akteur) und dem System, die dem Benutzer etwas von Wert liefert - Verwendung auf unterschiedliche Ebenen (Summary Goals, User Goals, Subfunctions) - Anwendungsfälle sind Anforderungsquellen - Use-Cases sind Container für funktionale Anforderungen - Kann gut mit anderen Modelltypen eingesetzt werden Erarbeitung in drei Schritten 1. Use-Case Modell mit Aktoren a. Use-Case Name definieren b. Kurzbeschreibung der Use-Cases c. Aktoren identifizieren 2. Happy Day Szenario a. Vor- und Nachbedingungen und Normalablauf der Use-Cases 3. Spezialfälle a. Alternative, Ausnahmen Bsp. Detail eines Use-Cases (Person prüfen) - Vorbedingung o Neue Rechnung im System - Ergebnis/Nachbedingung o OK: Personen sind gültig Eine Person ist als Leistungsbezüger akzeptiert o Nicht OK: Person nicht bekannt S e i t e 6 / 8

7 - Fachlicher Auslöser o Der Sachbearbeiter möchte die Personen auf der Rechnung mit den Stammdaten überprüfen - Normalablauf o Sachbearbeiter gibt Vorname und Nachname ein und startet die Suche Übung Erarbeitung eines Use-Cases anhand des Sushi-Automaten Use-Case Teilpunkt Beschreibung Erarbeitungsschritt Use Case Name Sushi kaufen Aktor Benutzer Beschreibung Ablauf, wie der Kunde am Sushi-Automaten Sushi kaufen 1 kann Vorbedingung Automat korrekt installiert/konfiguriert, Automat mit (gültigen) Zutaten gefüllt Nachbedingung Sushi hergestellt und an Kunde ausgegeben Geld vom Kunden kassiert (Bar, Prepaid), Betreiber erhält 20 Rp. Gewinn Warenbestand aktualisiert Priorität hoch 2 Normalablauf Kunde wählst Sushi-Art, Kunde wählt Zutaten aus, Kunde wählt Zahlmethode aus, Zubereitung des Sushi und anschliessende Ausgabe, Bestand wird aktualisiert Alternative wurde nicht behandelt Ausnahme wurde nicht behandelt Special Requirements wurde nicht behandelt 3 Ausnahmen/Bemerkung wurde nicht behandelt Eine Exception bedeutet, dass nicht alle Nachbedingungen eingetroffen sind. Eine Exception führt dazu, dass der Normalablauf nicht auf die gewohnte Weise durchgeführt/terminiert wird UML Diagramm Aktivitätsdiagramm Modellierung von Verhalten Quelle: Erni Essentials No.5, S.56, November 2007 S e i t e 7 / 8

8 2.6.6 UML Diagramm Zustandsdiagramm - Modellierung von Dynamik - Wechsel der inneren Zustände - Zusammen mit Domain Modell UML-Diagramm Sequenzdiagramm - Modellierung von Verhalten - Parallele zeitliche Abläufe - Szenarios - Spezialfälle - Verschachtelung - Komplexe Abläufe auf Haupt- und Subszenarien aufteilen S e i t e 8 / 8