Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert

Transkript

1 Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert

2 2

3 Nach derbefragung aller Stakeholder und der Dokumentation der Antworten geht es im zweiten Schritt darum, mögliche Lösungen (Lösungswege) zu beschreiben, vergleichen, Die Beschreibung der Lösung führt uns aber oft nicht nur zu neuen Fragen, sondernauch zu weiteren Anforderungen. 3

4 EinProblem hat immer ganz verschiedene Aspekte und muss darum von allen Seiten begutachtet werden. Nurdurch das Betrachten desproblems aus verschiedenen Blickwinkeln können wir alle Aspekte erkennen und beschreiben/modellieren. 4

5 Der gesamte Ablauf des RequirementsEngineeringbeginnt mit den Befragungen beim Kunden, wo diegeschäftsprozesse (Business UseCases) erfasst, erste MindMapserstellt 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 jenach 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üssenauch 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. 5

6 Entscheidungsbäume gehörennicht zur UML Sprache, weshalb sie nicht standardisiert sind. Es ist daher wichtig, diese Symbole möglichst einfach (und immer gleich) zu wählen. 6

7 BPMN steht für Business Process Model and Notation. DieseMatrix 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. 7

8 Anforderungen werden zuerstgrob 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. 8

9 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). Diagrammemüssen, wo nötig und nicht selbsterklärend, durch natürliche Sprache ergänzt werden. 9

10 Nicht-funktionale Anforderungen werden (fast) immer in natürlicher Sprache spezifiziert. Hier ist eine klare, messbare, testbareund unmissverständliche Formulierung extrem wichtig (siehe Kapitel 3. Requirements spezifizieren). 10

11 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. 11