4. Requirements analysieren und modellieren
2
Ziel der Analyse Klares Verständnis von Wert, Nutzen und Aufwand der Anforderungen Bewertung von Einflüssen, Abhängigkeiten und Unsicherheiten Detektiv-Arbeit Problem Anforderungen beschreiben Anforderungsmodell Lösungsweg beschreiben Entwurfs- (Lösungs-)Modell Aufgaben des Systems verstehen Priorisierte Anforderungen Nach der Befragung aller Stakeholder und der Dokumentation der Antworten geht es im nächsten Schritt darum, die Anforderungen sauber zu modellieren und (erst) dann mögliche Lösungen (Lösungswege) zu beschreiben, vergleichen, Die Modellierung der Anforderungen (und Lösungen) führt uns aber oft nicht nur zu neuen Fragen, sondern auch zu weiteren Anforderungen. 3
Die drei Perspektiven auf das System Struktur Daten mit Attributen Anforderungen Funktion Funktionalität, Daten-Verarbeitung Verhalten Zustände, Reaktion auf Ereignisse Die verschiedenen Sichten auf das System helfen bei der Aufteilung/Gliederung der Anforderungen. Ein Problem hat immer verschiedene Aspekte und muss darum von allen Seiten begutachtet werden. Nur durch das Betrachten des Problems aus verschiedenen Blickwinkeln können wir alle Aspekte erkennen und beschreiben/modellieren. 3. Requirements spezifizieren 4
Verschiedene Aspekte/Sichten Funktionsperspektive Funktionalität aus Sicht des Benutzers Use Cases (+Beschreibungen) und Aktivitätsdiagramme Strukturperspektive Struktur des Systems und Kommunikation zwischen verschiedenen (Teil)-Systemen Komponentendiagramm, Klassendiagramm, ER-Diagramm, Verhaltensperspektive Reaktionen auf Ereignisse, Zustandswechsel Zustandsdiagramm, Entscheidungsbäume, Und/Oder-Bäume, Für die verschiedenen Sichten werden je die passenden UML-Diagramme verwendet. 5
Analyse Modellierung 1. Mind Map/Kontextdiagramm -> Problem-Raum 2. Glossar (Geschäfts-Wörter/Bereiche) 3. Use Cases / Szenarien a) Zustandsanalyse Initialisierung, Stand-by, Fehlerfall, Störung, Notbetrieb, Backup, b) Aktivitäten-Diagramm c) Entscheidungsbaum 4. Qualitätsanforderungen und Randbedingungen a) Ergonomie, Sicherheit, Performance, 5. Detaillierte Modelle Fachklassen-, Objekt-, verfeinerte Aktivitäten-, Zustands-, Kommunikations- oder Sequenzdiagramme Der gesamte Ablauf des Requirements Engineering beginnt mit den Befragungen beim Kunden, wo die Geschäftsprozesse (Business Use Cases) erfasst, erste Mind Maps oder Use Cases erstellt sowie der Problem-Kontext (das System-Umfeld) grob erörtert wird. Schon sehr früh müssen die Fachbegriffe geklärt werden, was zum Erstellen eines Glossars führt. Im Schritt 3 werden je nach Projekt die verschiedenen System-Zustände (und deren Übergänge, Events), die Arbeits-Abläufe (Aktivitäten) oder die möglichen Prozesse beschrieben. Weiter müssen auch die Fehlerfälle erfasst (und mit Hilfe von Test-Szenarien abgesichert) werden. Schritt 4 enthält möglicherweise einen Prototyp für das User Interface. 6
Definition Ein Modell ist ein abstraktes Abbild einer existierenden oder noch zu schaffenden Realität. Ein Modell dient als Abbild der Realität (was ist vorhanden, was soll «erschaffen» werden) zur Verkürzung/Vereinfachung der Realität (nur die Aspekte welche für diesen Sachverhalt relevant sind) in einem spezifischen Verwendungszweck (Einschränken auf ein spezifisches Problem/Sachverhalt) Ein Anforderungsmodell ist ein konzeptuelles Modell, welches die Anforderungen eines Systems dokumentiert. Ein Entwurfsmodell ist ein konzeptuelles Modell, welches die Aspekte einer Lösung eines Problems dokumentiert. Anforderungs- und Entwurfs-Modelle werden heute üblicherweise mit UML konstruiert. 7
Schwierigkeit Während den Anforderungen darf die Lösung beim RE nicht bereits (im Kopf) vorhanden sein. Der RE muss sich zwingen, Problembasiert und nicht Lösungsorientiert zu arbeiten. Diese Trennung fällt typischerweise nicht leicht, insbesondere bei erfahrenen RE, die schon viele Lösungen entwickelt haben. Auch für erfahrenen Requirements Engineering Spezialisten ist es oft schwierig, während der Anforderungsanalyse nicht bereits eine Lösung anzusteuern (dies würde zu einer unerwünschten Einschränkung der möglichen Lösungen führen). Besonders wenn der Problemkreis gut bekannt ist, besteht die Gefahr, sich nicht von «alten» bereits durchgeführten Projekten (und deren gewählten Lösungen) beeinflussen zu lassen. 8
Zielmodelle Intentionen der Stakeholder in Form von Zielen Gewünschte Eigenschaften des zu entwickelnden Systems Visionen als Grobziel Verfeinerung der Ziele in Ziel-Dekompositionen (welche Nebenziele sind für das Erreichen des zentralen Ziel nötig) Oft dokumentiert durch Und-Oder Bäume 9
Und/Oder Baum ODER - Baum Ziel UND - Baum Ziel Teilziel1 Teilziel2 Teilziel3 Teilziel1 Teilziel2 Teilziel3 Beispiel-Baum Reise buchen Eingeben des Reisewunschs Auswählen einer Reise nach Datum nach Zielort Und/Oder gehören nicht zur UML Sprache, weshalb sie nicht standardisiert sind. Es ist daher wichtig, diese Symbole möglichst einfach (und immer gleich) zu wählen. 10
Modellieren von Abläufen Komplexe Abläufe lassen sich oft nicht einfach durch natürliche Sprache erklären. Beim Beschreiben durch natürliche Sprache besteht die Gefahr, dass Äste oder Bedingungen vergessen gehen. Besser für die Beschreibung von Abläufen sind darum Entscheidungsbäume oder Aktivitätsdiagramme (vgl. OOAD). Aktivitätsdiagramme (Flowcharts oder Activity-Diagramms) werden im OOAD Kurs behandelt. 11
Entscheidungsbäume (einfache Abläufe) Da sie nicht standardisiert sind gibt es verschiedene Arten von Entscheidungsbäumen. 12
Was Wann Womit - Weniger geeignet 0 Neutral + Gut geeignet ++ Seht gut geeignet Akz ept anz bei m Kun den Nota tions - Kenn tniss e Spezi fikati ons- Level Kom plexe Syste me Kon siste nz- Sich erru ng Natürliche Sprache ++ ++ 0-4 - - +/- Use-Case ++ + 0-1 - - - Use-Case Beschreibung ++ + 0-2 0-0 Szenario (User Story) + ++ 0-1 - + + Aktivitätsdiagramm (Ablauf) + - 3-4 ++ + ++ Klassendiagramm (ERM, Domain Model) 0-2-4 ++ + ++ Komponentendiagramm 0-3-4 ++ 0 + Zustandsdiagramm (Ereignisse) - - 3-4 + + ++ Sequenzdiagramm (Kommunikation) - - 3-4 + ++ ++ Und/Oder- oder Entscheidungsbaum + - 2-3 + + ++ Ein de uti gke it Diese Matrix kann helfen die Frage zu beantworten: Welche Teile des Systems sollen womit dokumentiert werden. Nicht alle Dokumentationsarten sind für alle Situationen gleich geeignet. Komplexe Systeme erfordern eventuell ein Dazulernen beim Kunden. Gewisse Diagramme werden erst für den Lieferanten/Auftragnehmer wirklich relevant. 13
Einsatz von Diagrammen Versteht der Kunde die Notation? Lohnt sich der Aufwand für das Zeichnen (und ev. Erlernen) des Diagramm-Typs Bringt die neue Technik genügend Qualitätsgewinn? Wird jede Anforderung an genau einer Stelle dokumentiert (Redundanz-Freiheit) Sind die Diagramme so einfach wie möglich gehalten Anzahl Notations-Elemente (beim Kunden) beschränken Anforderungen werden zuerst grob und je später desto exakter spezifiziert. Daher kann es gut sein, dass in den Kapiteln 1 und 2 die gleiche Anforderung bereits erwähnt wurde. Erst in Kapitel 3 wird sie dann exakt spezifiziert. Dort sollte sie aber nur an einer Stelle dokumentiert werden. 14
Umgang mit Komplexität Natürliche Sprache für sehr einfache oder sehr abstrakte / sehr detaillierte Ebene Gruppieren/Aufteilen/Sortieren der Anforderungen (nach Rolle, Subsystem, Geschäftsprozess, ) Komplexe Abläufe, Situationen durch Diagramme modellieren Diagramme wo nötig durch natürliche Sprache ergänzen. Einfache Anforderungen werden am besten durch natürliche Sprache spezifiziert. Dafür lohnt sich der Aufwand ein Diagramm zu zeichnen normalerweise nicht. Komplexe Abläufe oder Situationen werden dann durch Diagramme erklärt, da die natürliche Sprache hier klar an Grenzen stösst (nicht mehr verstanden wird). Diagramme müssen, wo nötig und nicht selbsterklärend, durch natürliche Sprache ergänzt werden. 15
Nicht-funktionale Anforderungen Qualitätsanforderungen (Performance, Erweiterbarkeit, Ergonomie, ) Technologische Anforderungen (Datenbank-System, Programmier-Umgebung/Sprache, Betriebssystem, ) Durchzuführende Tätigkeiten wie Wartung, Support, Schulung, Rechtliche Anforderungen wie Lizenzbestimmungen oder Kosten Einzuhaltende Standards und Normen. Nicht-funktionale Anforderungen werden (fast) immer in natürlicher Sprache spezifiziert. Hier ist eine klare, messbare, testbare und unmissverständliche Formulierung extrem wichtig (siehe Kapitel 3. Requirements spezifizieren). 16
Struktur-Brüche Übergänge sind unvermeidlich Anforderungen Anforderungsmodell Anforderungsmodell Entwurfsmodell Entwurfsmodell Systemstruktur Systemstruktur Software und Hardwarekomponenten Klare Dokumentation/Unterscheidung zwischen Anforderung und Lösungsentwurf Klare, konsistente, für alle verständliche Modellierung Objektorientierte Analysetechnik Struktur-Brüche sind zwischen den verschiedenen Phasen unvermeidlich. Wichtig ist es, trotzdem klar zwischen Anforderung und Lösungsmodell zu unterscheiden. Dies geschieht durch eine klare Dokumentation (wer ist verantwortlich für oder Autor von welche(n) Bilder(n), Texte(n), Diagramme(n), ). Nur so kann klar getrennt werden zwischen Lösung und Problem (bzw. Anforderung). Ein sauberes objektorientiertes Vorgehen kann Brüche mildern, indem schon zu Beginn die richtigen Namen für Objekte, Methoden, Interfaces, benutzt werden. 17