Freitag, 25. April 2014

Drei Perspektiven öffnen uns den Weg zu den Anforderungen.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Nachdem gezeigt wurde, wie man aus einer User Story und den dazu gehörenden Akzeptanztests Szenarien entwickelt und diese dann zu Use Cases zusammenfasst, können wir nun untersuchen wie man auf diesem Weg weiter zu sinnvollen Anforderungen gelangt. Seitdem wir mit der Bildung von User Stories die Planungsphase verlassen haben, befinden wir uns mitten in der Entwicklungsphase. Das tiefe Durchdenken der Anforderungen ist Voraussetzung für die Vermeidung einer Reihe von teuren Fehlentwicklungen, die sonst in der Implementierungs- und Bugfixingphase behoben werden müssten. Die Ermittlung guter Anforderungen ist wichtig für die Entwicklung des richtigen Systems.

Inzwischen haben wir ein Geflecht von Ideen, Themen, Kontextobjekten, Zielen, User Stories und Use Cases, die wiederum aus Szenarien zusammengesetzt sind. Jedes dieser Artefakte besitzt eine ganz bestimmte Verantwortung. Laut [POHL08] bilden Ziele und Szenarien die Grundlage für lösungsorientierte Anforderungen. "In der Regel ist es nicht möglich, alle lösungsorientierten Anforderungen vollständig, präzise und im notwendigen Detaillierungsgrad aus den vorhandenen Zielen und Szenarien abzuleiten. Die Vervollständigung, Präzisierung und Detaillierung der lösungsorientierten Anforderungen erfolgt daher inkrementell durch den Einsatz von Gewinnungstechniken. Durch die Gewinnung neuer Ziele und Szenarien wird die Gewinnung von lösungsorientierten Anforderungen bzw. deren Detaillierung fokussiert und unterstützt." [S.184, POHL08] Im beschriebenen Modell sind die anderen Objektarten bei der Gewinnung von Anforderungen jedoch auch zu beachten. Sie bieten das schon erarbeitete Fundament für die weitere Gewinnung von Anforderungen.

Bei der Analyse spielen die folgenden Perspektiven zur Beschreibung von Anforderungen eine große Rolle:

"Datenperspektive: Die Datenperspektive betrachtet die statische Struktur der Daten (d.h. Datentypen, deren Attribute sowie Beziehungen zwischen den Datentypen) und wird daher auch als Strukturperspektive bezeichnet.

Funktionsperspektive: Die Funktionsperspektive betrachtet die Manipulation der Daten durch die Funktion des Systems, d.h. die Transformation von Eingaben und Funktion in Ausgaben.

Verhaltensperspektive: Die Verhaltensperspektive beschreibt das Verhalten des Systems, d.h. dessen Reaktion auf externe Stimuli in Form von erlaubten Zuständen, Zustandsänderungen und erzeugten Ausgaben." [S.184, POHL08]

Die Diskussion der drei Perspektiven erfolgt im Team und mit den jeweiligen Stakeholdern. Jede Perspektive wird dabei mit einer geeigneten Modellsprache durchdacht. Wir verwenden für alle drei Perspektiven die UML. Die Datenperspektive wird mit Hilfe des Klassendiagramms modelliert, die Funktionsperspektive mit Aktivitätsdiagrammen und die Verhaltensperspektive mit Zustandsdiagrammen. Jedes Diagramm wird durch eine Tabelle erläutert, in der genauere Informationen abgelegt werden können.

Im Folgenden stelle ich eine mögliche Dokumentationsform der drei Perspektiven dar. Wir beginnen mit der Daten- bzw. Strukturperspektive. Diese wird, wie beschrieben durch ein Klassendiagramm dargestellt.



Die erklärende Tabelle dient der genaueren Erläuterung des Klassendiagramms und man kann mit Hilfe der Tabelle auch das Diagramm rekonstruieren. In der Tabelle findet man die Klassennamen, die zugehörigen Attribute, Methoden und Beziehungen. In der Tabelle werden außerdem alle Beschreibungen hinterlegt, die sich nicht in Modellelementen ausdrücken lassen. Somit wäre eine automatische Validierung möglich, die eventuelle Unstimmigkeiten im Modell aufzeigt.

ID-ParentID Typ Untertyp Anforderungsname Beschreibung>
1-0 Klasse - Lehrer Ein Lehrer ist eine Fachkraft zum unterrichten von Schülern.
2-1 - Attribut Fach Jeder Lehrer unterrichtet ein spezifisches Fach.
3-1 - Attribut Gehalt Jeder Lehrer bezieht ein festes monatliches Gehalt.
4-1 - Verhalten unterrichten Ein Lehrer unterrichtet Schüler.
5-1 - Beziehung besitzt Klasse Jedem Lehrer ist eine feste Klasse zugeordnet.
6-0 Klasse - Schüler Ein Schüler ist ein junger Mensch, der etwas lernen will.
... ... ... ... ...


Die Funktionsperspektive stellt Algorithmen dar. Somit gibt es eine Verknüpfung mit der Datenperspektive. Ein Untertyp der Datenperspektive ist das Verhalten der Klasse (oben die Methode unterrichten()). In der Funktionsperspektive können wir den zugehörigen Algorithmus durch ein Aktivitätsdiagramm genauer beschreiben.



ID-ParentID Typ Untertyp Anforderungsname Beschreibung>
4-1 Verhalten - unterrichten Ein Lehrer unterrichtet Schüler.
7-4 - Aktivität Klasse begrüßen Der Unterricht wird mit einem freundlichen Hallo eingeleitet.
8-7 - Entscheidung Stundeninhalt entscheiden Der Lehrer trifft eine Zufallsentscheidung, was er in der Stunde machen will.
9-8 - Aktivität Stoff vermitteln Der Lehrer vermittelt den Schülern einen Teil seines umfangreichen Wissens.
10-8 - Aktivität Stoff abfragen Der Lehrer prüft, ob das vermittelte Wissen bei den Schülern angekommen ist.
11-9
11-10
- Aktivität Stunde beenden Der Lehrer beendet die Stunde mit einem freundlichen: Na dann..
... ... ... ... ...


In Verhaltensperspektive werden einzelne Objekte (Klassen) auf ihre Zustände hin untersucht. Ein Lehrer hat in unserem Modell z.B. zwei Zustände: wach, schlafend. Die Zustandsübergänge bilden wieder Methoden, die durch Algorithmen in der Funktionsperspektive abgebildet werden können.



ID-ParentID Typ Untertyp Anforderungsname Beschreibung>
1-0 Klasse - Lehrer Ein Lehrer ist eine Fachkraft zum unterrichten von Schülern.
12-1 - Zustand Startzustand Der Lehrer ist noch keiner.
13-12 - Zustandsübergang Lehrerdasein beginnen Durch das Abschießen eines Studiums wird der Lehrer zum Lehrer.
14-13 - Zustand wach Der Lehrer ist 16 Stunden im wachen Zustand.
15-14 - Zustandsübergang einschlafen Der Lehrer fällt in den Schlaf.
16-15 - Zustand schlafend Der Lehrer träumt 8 Stunden lang.
... ... ... ... ...


Mit Hilfe der Verknüpfung von ID und Parent-ID werden in den Tabellen die erforderlichen Abhängigkeiten verzeichnet. Die gemeinsame Diskussion dieser Perspektiven und deren Dokumentation im Team und mit den jeweils erforderlichen Stakeholdern hat uns einem gemeinsamen mentalen Modell und Verständnis des Anforderungsgegenstandes wesentlich näher gebracht. Im nächsten Post wird es um Qualitätsanforderungen gehen. Diese sind eine wesentliche Voraussetzung zum Entwerfen einer geeigneten Architektur.

  • [POHL08] Klaus Pohl: "Requirements Engineering", 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

1 Kommentar:

  1. Ich finde es verwirrend, dass hier drei Perspektiven verwendet werden. In UML werden die Diagramme nämlich nur in statische und dynamische bzw. Struktur- und Verhaltensdiagramme aufgeteilt. Hier gibt es die Funktions- und die Verhaltensperspektive die sich um die Verhaltensdiagramme streitet. Ein Aktivitätsdiagramm ist für mich ein Verhaltensdiagramm und bedient damit die Verhaltensperspektive. Warum das die Funktionsperspektive bedienen soll, ist mir schleierhaft. Aber man kann natürlich einen Tisch als Stuhl definieren und dann passt es schon...

    AntwortenLöschen