Freitag, 27. Juni 2014

Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil Praktisches Beispiel zur Kontextuntersuchung.
3. Teil Praktisches Beispiel zu User Stories.
4. Teil Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.


Im letzten praktischen Post haben wir aus einer User Story Haupt-, Alternativ- und Ausnahmeszenarien entwickelt und diese zu einem Use Case zusammengesetzt. Die gefundenen Szenarien wurden in tabellarischer Darstellung näher erläutert, wenn es notwendig war. Nicht jede Information kann in UML beschrieben werden, manchmal ist einfach die natürliche Sprache notwendig. Allgemeine Attribute, die sich auf den erzeugten Use Case bezogen, wurden in einer spezifischen Schablone für den Use Case beschrieben. Solche Attribute waren Akteur, Name, Beschreibung, Vorbedingung, Nachbedingung und Ergebnis. Die gefundenen Use Cases können in einem Use-Case-Diagramm zum Zwecke des Überblicks und der Ordnung dargestellt werden. Wie wir Use Cases gruppieren und ordnen wird in einem späteren Post gezeigt. Auch die Notwendigkeit Abnahmekriterien zu entwickeln ist Bestandteil eines Späteren Beitrages.

Heute wollen wir den theoretischen Artikel Drei Perspektiven öffnen uns den Weg zu den Anforderungen am praktischen Beispiel erläutern. Die drei Perspektiven sind die Daten-, die Funktions- und die Verhaltensperspektive. Für jede dieser Perspektiven wurde ein spezifisches UML-Diagramm verwendet. Für die Datenperspektive verwenden wir das Klassendiagramm, für die Funktionsperspektive das Aktivitätsdiagramm und für die Verhaltensperspektive das Statusdiagramm.

Dem Team wird der Use Case Gruppenbildung von Stakeholdern mit der ID UC0001 vorgelegt. Dafür haben wir im letzten praktischen Post die Schablone ausgefüllt und die entsprechenden Szenarien gefunden. Nun fragen wir uns, welche Datentypen, mit welchen spezifischen Attributen sowie welche Beziehungen zwischen den Datentypen notwendig sind, um diesen Use Case umzusetzen. Stellen wir uns vor, dass in einem früheren Use Case bereits ein Stakeholder angelegt wurde, so dass das Team auf die Beschreibung dieses Datentyps zurückgreifen kann. Allerdings ist der neue Datentyp StakeholderGroup enthalten. Er dient der Erfassung der anzulegenden Stakeholdergruppen. Für diesen müssen wir nun spezifische Attribute finden und außerdem entsprechende Beziehungen zu dem Datentyp Stakeholder beschreiben. Im folgenden Bild ist eine entsprechende Möglichkeit dargestellt.



Zu jedem Diagramm gibt es in meinem Ansatz für das Dokumentieren von Anforderungen eine klärende Tabelle, mit deren Hilfe man die entsprechenden Diagramme revers wieder zusammensetzen könnte. Die Tabelle in unserem Beispiel hat das folgende Aussehen.

ID-ParentID Typ Untertyp Anforderungsname Beschreibung
1-0 Klasse - StakeholderGroup Eine Stakeholdergruppe fasst mehrere Stakeolder zusammen.
2-1 - Attribut name Jede Stakeholdergruppe muss einen eindeutigen Namen besitzen.
3-1 - Attribut description Jede Stakeholdergruppe kann eine Beschreibung besitzen.
4-1 - Verhalten compare Stakeholdergruppen können mit anderen Stakeholdergruppen verglichen werden. Sie sind gleich, wenn die in der Gruppe enthaltenen Stakeholder gleich sind.
5-1 - Verhalten addStakeholder Einer Stakeholdergruppe wir ein Stakeholder zugeordnet. Jeder Stakeholder kann nur einmal der Stakeholdergruppe hinzugefügt werden.
6-1 - Verhalten removeStakeholder Ein der Stakeholdergruppe zugeordneter Stakeholder kann aus der Stakeholdergruppe entfernt werden.
7-1 - Beziehung Stakeholders Jede Stakeholdergruppe besitzt eine Liste von Stakeholdern.


Nach diesen Überlegungen besitzen wir also eine Klasse StakeholderGroup, die drei Attribute besitzt: name, description und eine Liste von Stakeholdern. Für diese Attribute können nun tiefergehende Überlegungen angestellt werden. Darf die Liste leer sein? Wie groß darf die Liste werden? Wie lang darf eine Name für eine StakeholderGroup sein? Welche Zeichen darf er enthalten? Am Ende haben Sie mit dieser einen Perspektive bereits eine Fülle von notwendigen zu beschreibenden Anforderungen gefunden. Auch sind in dieser Perspektive bereits Bestandteile der Funktionsperspektive versteckt, die wir genauer mithilfe von Aktivitätsdiagrammen beschreiben können.

In einer vorstellbaren Diskussion wird die Anforderung compare beispielsweise vertiefend diskutiert. Es wird gefordert, dass zwei Stakeholdergruppen, die genau die gleichen Stakeholder in der Liste Stakeholders haben, nicht abgespeichert werden. Es muss also eine Möglichkeit geschaffen werden, die Listen zweier Stakeholdergruppen miteinander zu vergleichen. Vielleicht ist die Aufzeichnung dieses kurzen Algorithmus nicht erforderlich, aber in diesem Artikel soll es auch nur ein Beispiel sein, in welcher Art und Weise die Funktionsperspektive zu behandeln ist.



ID-ParentID Typ Untertyp Anforderungsname Beschreibung
4-1 - Verhalten compare Stakeholdergruppen können mit anderen Stakeholdergruppen verglichen werden. Sie sind gleich, wenn die in der Gruppe enthaltenen Stakeholder gleich sind.
8-4 - Aktivität sort list one Die Stakeholder, die zur ersten Stakeholdergruppe gehören, werden sortiert.
9-8 - Aktivität sort list two Die Stakeholder, die zur zweiten Stakeholdergruppe gehören, werden sortiert.
10-9 - Aktivität compare list one and list two Die beiden Stakeholdergruppen werden miteinander verglichen. Es wird vermerkt, ob die Stakeholdergruppen gleich sind oder nicht.


Nachdem das Team über weitere Algorithmen nachgedacht hat, die es lohnen aufgezeichnet zu werden, betrachtet es die Verhaltensperspektive. Dabei werden alle Klassen in Augenschein genommen und in Bezug auf mögliche Zustände untersucht. Stellen wir uns vor, eine Stakeholdergruppe soll die folgenden verschiedenen Zustände haben: Angelegt, Aktiv, Inaktiv und Gelöscht. Diese Anforderungen könnten z.B. dadurch entstanden sein, weil es Benutzer gibt, die das Recht haben Stakeholdergruppen anzulegen. Andere Benutzer dürfen diese jedoch nur nutzen, wenn die Gruppen freigeschaltet sind. Die Ersteller haben außerdem das Recht, dem nutzenden User dieses Recht wieder zu entziehen. Weiterhin sollen Stakeholdergruppen nicht physisch gelöscht werden, sondern sie müssen aus Nachvollziehbarkeitsgründen im System erhalten bleiben.



ID-ParentID Typ Untertyp Anforderungsname Beschreibung
1-0 Klasse - StakeholderGroup Eine Stakeholdergruppe fasst mehrere Stakeolder zusammen.
11-1 - Zustand start Es gibt die Stakeholdergruppe noch nicht.
12-11 - Zustandsübergang create Die Stakeholdergruppe wird angelegt.
13-12 - Zustand created Die Stakeholdergruppe wurde angelegt.
14-13
14-17
- Zustandsübergang activate Die Stakeholdergruppe wird für die Benutzung freigeschaltet.
15-14 - Zustand enabled Die Stakeholdergruppe kann in diesem Zustand benutzt werden.
16-15 - Zustandsübergang deactivate Die Stakeholdergruppe wird gesperrt.
17-16 - Zustand disabled Die Stakeholdergruppe ist in diesem Zustand für die Nutzung gesperrt.
18-17 - Zustandsübergang delete Die Stakeholdergruppe wird mit einem Löschvermerk gekennzeichnet. Sie kann dann nicht mehr benutzt werden.
19-18 - Zustand deleted Die Stakeholdergruppe besitzt einen Löschvermerk und kann nicht mehr aktiviert werden.


Die Diskussion dieser Perspektiven im Team ermöglicht ein schnelles Auffinden einer Vielzahl von Anforderungen. Jedes Teammitglied sieht etwas anderes und fügt seine spezifische Sicht zum Ganzen hinzu. Der Kunde muss fester Bestandteil dieses Teams sein. In der Diskussion ergänzen sich die methodischen Kenntnisse des Entwicklerteams und die Fachsicht des Kunden.

vorheriger Post dieses Themas


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

Keine Kommentare:

Kommentar veröffentlichen