Requirements Engineering Gastdozent: David Kurmann Modul: SWE SS08 Datum: 14 April 2008 Autor: Marco Röösli Inhaltsverzeichnis 1 Rückblick auf Requirements Engineering Teil 1... 2 1.1 Was ist Requirements Engineering?... 2 1.2 Wie kann man Requirements Strukturieren (nach welchen Tätigkeiten)... 2 2 Dokumentieren/Spezifizieren... 3 3 Iterative Vorgehensmodelle...3 4 Dokumentationsmethoden...3 4.1 Text und Grafik...4 5 Textuelle Dokumentationsformen... 4 5.1 Anforderung an Natürliche Sprache... 4 5.1.1 Vorteile...4 5.1.2 Nachteile... 4 5.1.3 Regeln... 4 5.2 Sätze formulieren...5 5.3 Übung zu Sätze formulieren in 7 min... 5 5.4 Kundenanforderungen Vorlage...6 5.5 Glossar... 6 6 Grafische Modelle... 7 6.1 Übersicht...7 6.2 Übung zu Actor Map... 8 6.3 Use Case Anwendungsfälle... 8 6.3.1 Use Case sind Container für funktionale Anwendungen... 8 6.3.2 Ebenen der Use Cases:...8 6.3.3 Use Cases werden in 3 Schritten erarbeitet...9 6.3.4 Beispiel eines Use Case Modells... 9 6.3.5 Modelle Use case Erarbeitung... 10 6.3.6 Übung Use Case erstellen für den Shushi Automaten...10 6.3.7 Ausnahmen und Alternativen bei Use Cases... 11 6.4 Aktivitätsdiagramme (Alt. Flussdiagramme)... 11 6.5 UML Diagramm Zustandsdiagramm...12 6.6 Sequenz Diagramm...12 Marco Röösli -= 1-12 =- 15.04.08
1 Rückblick auf Requirements Engineering Teil 1 1.1 Was ist Requirements Engineering? Kommunikation Stufen (Business/ User / System) Stakeholder (Wissen wer damit zu tun hat) System Grenze (was ist innen was ist aussen) Entscheidungen (Dokumentierte Entscheidungen) Design Problemraum beschreiben nicht die Lösung Iterativer Prozess 1.2 Wie kann man Requirements Strukturieren (nach welchen Tätigkeiten) Requirements Management Requirements Development Kreis mit 4 Tätigkeiten im iterativen Prozess E rheb en (erfragen) A nalyse V alid ieren S p ezifizieren Marco Röösli -= 2-12 =- 15.04.08
2 Dokumentieren/Spezifizieren Wird auf zwei Methoden aufgeteilt: Textbasierte und Modellbasierte Methoden 3 Iterative Vorgehensmodelle Code and Fix Wasserfallmodell Sequentielles Modell Für kleine Projekte geeignet Für grosse Projekte ungeeignet RUP (rational unified prcocess) Teilt die Arbeit in neue Disziplinen auf (Business Modeling, Deployment, Umgebung) Grobes Phasenmodell (Inception, Elaboration, Construction, Transition) Iteratives, inkrementelles Vorgehen (Eine Phase beinhaltet eine oder mehrere Iterationen) Inkrementell, da immer mehr Funktionalität hinzugefügt wird 4 Dokumentationsmethoden Nicht formale Beschreibungsarten Wenig Rahmenbedingungen Viel Arten von Interpretationen Formale Beschreibungen Diagramme, Mathematik etc. Von hoher Abstraktion zu Detailiertheit Formalität Domain Aktivität Szenario Glossar Use Case Natürlichesrpache GUI Details Marco Röösli -= 3-12 =- 15.04.08
4.1 Text und Grafik Text und Grafik kombinieren, weil einige Leute gut Texte lesen können während andere nur Grafik verstehen. Darum muss man die Dokumentationsform mixen: Vision Ziel Kontext agrenzung Use-Case Use-Case Beschreibung Verhaltensmodell Detailmodell Sprache 5 Textuelle Dokumentationsformen 5.1 Anforderung an Natürliche Sprache 5.1.1 Vorteile Einfach zu verstehen Einfach zu handhaben 5.1.2 Nachteile Sind anfällig auf Mehrdeutigkeit Schwierig raus zu finden ob man alles hat Werden gross für grosse Systeme 5.1.3 Regeln Sätze und Absätze kurz halten Nur eine Anforderung pro Satz Qualitäten an eine Software in Untersätze verpacken Bei logischen Kombinationen lohnt sich der Einsatz von Pseudocode oder Entscheidungstabellen (Statt verschachtelten Sätzen) Marco Röösli -= 4-12 =- 15.04.08
5.2 Sätze formulieren Beschreibung wie ein Satz aussehen soll: Bsp.: Wenn der Bankkunde Geld beziehen will, muss der Bankomat fähig sein Bankkonten im Betrag von 50 Fr bis 1000 Fr auszugeben Auslöser (Wann) Muss soll kann Das System -- Für wen Fähig sein Objekt Prozesswort Verbindlichkeit 5.3 Übung zu Sätze formulieren in 7 min Aufgabe 3 Requirements für den Sushi Automat in der obigen Form (Grafik) 1 Wenn der Kunde Sushi will muss der Sushiautomat fähig sein die Sushi Arten Nigeri und Maki auf der Ablage bereit zu stellen 2 Wenn der Kunde online bestellen will, muss der Sushiautomat fähig sein die Bestellung über Internet entgegen zu nehmen und zu verarbeiten 3 Wenn ein Techniker den Automaten auf Statistiken abfragen möchte, muss der Sushiautomat fähig sein seine Anfragen auszuwerten und ihm in einer digitalen Form zu liefern. Marco Röösli -= 5-12 =- 15.04.08
5.4 Kundenanforderungen Vorlage Requirement #Nr. Ereignis: usecasr # n/a Beschreibung <<Beschreibung>> Begründung: <<Wieso ist der Use Case wichtig>> Qulle: <<von wo ist die Information>> Fit Kriterum: <<Kriterium für den Status>> Kundenzufriedenheit <<Wert von 1-10>> Abhängigkeit: <<Use Case #Nr.>> Kommentare: <<Kommentare>> Geschichte: <<Was ist mit dem Use Case schon gelaufen>> 5.5 Glossar Begriffe und Definitionen sind grundlegend Beschleunigt die Kommunikation Hilft dem gegenseitigen Verständniss Erstellen sie das Glossar früh im Projekt und halten sie es stets aktuell Definieren sie spezielle Begriffe für ihr Projekt Synonyme hinzufügen Begriffe verwenden die im Projekt Umfeld wie auch im täglichen Umfeld existieren Benutzen sie ein Glossar von das auf andere Dokumente refernziert Falls notwendig, wenden sie dem Glossar eine Person zu Sushi Glossar Automat Japan Good Comp card Kochwerk Konsument des Monats Portion Betreiber Zentrale Marco Röösli -= 6-12 =- 15.04.08
6 Grafische Modelle 6.1 Übersicht Verhalten Orientiert sich an Prozessen Aufgaben und Abläufen z.b. Use Case, Szenarios, Prozess Karten Strukturieren Komponenten und deren Beziehungen z.b. Modelle, Klassendiagramme Dynamik Wie verändern sich Dinge über die Zeit z.b. Ereigniss Tabellen Zustandsdiagramme Überwachung Entscheidungen und Vorschriften z.b. Business Regeln Entscheidungstabelle Marco Röösli -= 7-12 =- 15.04.08
6.2 Übung zu Actor Map Actor Map für den Sushi Automaten erstellen Stakeholder Aktoren Stakeholder Kunden Anwender Andere Dirket Indirekt Experten Entwickler Geschäfsführer Hungrige Inetuser Monteur Refiller Support Map-Anbieter Koch Behörden Gesetze Analysten Erfinder Machienenbauer Programmierer Transport 6.3 Use Case Anwendungsfälle Modellierung von verhalten Auf unterschiedlichen Ebenen Helfen Funktionale Anforderungen zu finden Eignet sich schlecht um nicht funktionale Anforderungen auf zu listen Kann gut mit anderen Modelltypen eingesetzt werden 6.3.1 Use Case sind Container für funktionale Anwendungen Alle Funktionen des Systems Erzählen Geschichte von einem Aktor der das System benützt Bedienungshandbuch Ping - Pong System Sicht des Aktors Grundlage für testen, Designplanung Beispiele Geld abheben Telefon in Betrieb nehmen Messresultate auswerten 6.3.2 Ebenen der Use Cases: Business Usecases User Usecases System usecases Von oben nach unten Wie? Von unten noch oben Warum? Marco Röösli -= 8-12 =- 15.04.08
6.3.3 Use Cases werden in 3 Schritten erarbeitet 1 Use Case Modell alle Use Cases identifizieren Kurzbeschreibung der Use Cases alle Aktoren identifizieren 2 Happy Day Szenario Vor und Nachbedingungen und Normal Ablauf der Use Cases erstellen 3 Spezialfälle Alternativen Ausnahmen 6.3.4 Beispiel eines Use Case Modells System U1 U2 U3 Marco Röösli -= 9-12 =- 15.04.08
6.3.5 Modelle Use case Erarbeitung Use Case Name Aktor Beschreibung Vorbedingungen Nachbedingungen Priorität Normalablauf Ausnahmen Spezialanforderung Annahmen Alternative 1 2 3 6.3.6 Übung Use Case erstellen für den Shushi Automaten Aufgabe: Einen Use Case für den Sushiautomaten erstellen! Use Case Name Aktor Beschreibung Vorbedingungen Nachbedingungen Priorität Normalablauf Ausnahmen Spezialanforderung Annahmen Alternative Sushi Kaufen Benutzer Zeigt den Ablauf wie ein Kunde am Sushiautomat Sushi kaufen kann 1) Sushi Zutaten muss vorhanden sein (darf nicht leer sein) 2) Sushi Zutaten muss frisch sein (darf nicht abgelaufen sein) 2) Der Automat wurde korrekt installiert und in Betrieb genommen 1) Der Sushi Bestand hat abgenommen 2) Die Sushi wurde bezahlt 3) Der Betreiber hat 20 Rappen Gewinn eingenommen Hohe Priorität 1) Sushi Automat zeigt Sushi Arten die kaufbar sind 2) Kunde wählt Sushi Art aus 3) Kunde wählt Menge aus 4) System berechnet den Preis 5) Kunde wählt Bezahlungsart aus 7) Kunde bezahlt 8) Sushi wird produziert 9) Kunde erhält Shushi 10) Sushi Bestand wird aktualisiert 11) Fehler werden geloggt Marco Röösli -= 10-12 =- 15.04.08
6.3.7 Ausnahmen und Alternativen bei Use Cases Wie werden Ausnahmen und Alternativen in USE Cases behandelt? Alternative: z.b. Ausgewähltes Sushi ist nicht mehr verfügbar dann muss eine Alternative gewählt werden. Bei einer Alternative werden alle Nachbedingungen erfüllt Ausnahme: z.b. Keine einzige Zutat ist mehr vorhanden Shushi kann nicht mehr produziert werden Alles was dazu führt dass die Nachbedingungen nicht mehr erfüllt wird Darum muss man die neue Nachbedingung beschreiben Bei einer Ausnahme werden die Nachbedingungen nicht mehr erfüllt Vorgehen: Für jeden Schritt im Normalablauf wird eine Ausnahme bestimmt (gesucht) Für jeden Punkt im Use Case können Qualitäten definiert werden. z.b. Sushi wird in 2min erstellt 6.4 Aktivitätsdiagramme (Alt. Flussdiagramme) Beispiel: Marco Röösli -= 11-12 =- 15.04.08
6.5 UML Diagramm Zustandsdiagramm Modellierung von Dynamik Wechsel der internen Zustände Zusammen mit Domain Modell Beispiel: 6.6 Sequenz Diagramm Modellierung von Verhalten Pralle zeitliche Abläufe Szenarios Spezialfälle Verschachtelung Komplex Abläufe auf Haupt und Subszenarien aufteilen Beispiel: Marco Röösli -= 12-12 =- 15.04.08