Aktivität

[Eigene Ergänzungen/Erfahrungen bearbeiten]

Anforderungsanalyse

A-229 Systemanwendungsfall detaillieren

Pro identifiziertem Systemanwendungsfall wird ein vollständiges Ablaufmodell mit allen Ausnahmen und Varianten entwickelt. Anhand des Modells werden Dialoge identifiziert und beschrieben.

Aktivität muss durchgeführt werden in Entwurf-/Architekturphase (Startphase) (Iterative Aktivität) (die wichtigsten, d.h. ca. 30 % der identifizierten Systemanwendungsfälle.)
Aktivität muss durchgeführt werden in Konstruktionsphase (Hauptphase) (Iterative Aktivität) (für Ablaufmodelle und Dialogablaufmodelle bei Bedarf.)


Pro Systemanwendungsfall ein vollständiges Ablaufmodell entwickeln
Nachdem die identifizierten Systemanwendungsfälle essenziell beschrieben wurden, werden sie nun im Detail betrachtet. Sie werden so weit detailliert, dass die einzelnen Aktivitätsschritte bezüglich ihrer Vor- und Nachbedingungen, Akteure, ein- und ausgehender Daten und Ereignisse vollständig sind. Dies geschieht, indem man in zwei Schritten vorgeht:

Textuelle Beschreibungen treffen häufig keine Aussagen darüber, welche Schritte nacheinander bzw. nebenläufig ausgeführt werden können und unter welchen Bedingungen dies ggf. möglich ist. Die Abbildung in Ablaufmodellen bietet diesen Vorteil und beschreibt formal. Daneben wird auf lange textuelle Dokumentation verzichtet.

Standardablauf beschreiben
Aus der essenziellen Systemanwendungsfallbeschreibung werden die einzelnen Schritte übernommen und als Aktivitäten in einem Ablaufdiagramm dargestellt. Dabei wird der Normalablauf notiert, meist handelt es sich häufig um sequenzielle Abfolgen. Sofern sich hinter einem Schritt in der essenziellen Systemanwendungsfallbeschreibung mehrere elementare Einzelaktivitäten verbergen, kann das Ablaufmodell entsprechend erweitert und die Aktivitäten entsprechend zerlegt werden.

Vollständigen Ablauf beschreiben
Nun gilt es, für jede Aktivität alle vorgesehenen Ausnahmen und Verzweigungsmöglichkeiten zu modellieren. Das heißt für jede Aktivität werden die möglichen Ausnahmen und Varianten geklärt. Die Frage lautet nun: Welche anderen Ergebnisse einer Aktivität sind denkbar und fachlich möglich? Ggf. werden Widersprüche, Lücken und neue offene Fragen in den essenziellen Systemanwendungsfallbeschreibungen entdeckt. Diese sind dann dort einzuarbeiten bzw. zu dokumentieren. Die Detailtiefe der Essenzschritte wird dadurch nicht verändert.

So wird mit jeder Aktivität verfahren, bis alle fachlich denkbaren Situationen berücksichtigt wurden und das Diagramm vollständig ist. Wichtig ist, dass nur die fachlichen und ablaufspezifischen Ausnahmen in das Ablaufmodell mit aufgenommen werden. Technische Fehler und Störungen werden nicht modelliert.

Zusätzlich wird eine Liste mit möglichen Kandidaten für sekundäre Systemanwendungsfälle erstellt. Darauf sind der Name des Systemanwendungsfalles mit den Namen für mögliche Kandidaten für sekundäre Systemanwendungsfälle zu notieren. In einer Folgeaktivität werden alle Kandidatenlisten zusammengeführt und bei der Erstellung des Systemanwendungsfallmodells genutzt.

Als Nebenprodukt lassen sich aus der vollständigen Ablaufspezifikation alle fachlich motivierten, ablaufspezifischen Testfälle ableiten. Für jede Transition wird mindestens ein Testfall benötigt.

Soweit möglich und sinnvoll, sollten die Abläufe mit den Anwendern und den Fachexperten durchgesprochen werden.

Dialoge identifizieren
In komplexen Anwendungen treten einzelne Dialoge zumeist in einer Vielzahl verschiedener Kontexte auf. Damit die Anwender nicht für jeden Bearbeitungskontext einen anderen, separaten Dialog vorgesetzt bekommen und auch angesichts der Entwicklungs- und Pflegekosten, sollten Dialoge möglichst universell in verschiedenen Kontexten einsetzbar sein.

Um Dialoge oder Dialogelemente abzuleiten, wird das Ablaufmodell systematisch untersucht, wann ein Dialog oder Dialogelement benötigt wird. Fachlich oder durch den Kontext des Ablaufes zusammenhängende Dialogelemente (z.B. die Einzelfelder zu einer Anschrift) werden identifiziert und benannt. Diese Informationen werden als Bemerkung bzw. Anhang zu den Systemanwendungsfällen oder separat beschrieben. Die notwendigen Dialogelemente (Felder, Schaltflächen u.Ä.) werden mit einem Namen versehen. Soweit möglich, werden die Elemente auch zu Gruppen (die dann auch einen Namen erhalten) zugeordnet. Die einzelnen Elemente einer Gruppe fachlich zusammengehörender Dialogelemente werden in einer Folgeaktivität Dialog spezifizieren detailliert spezifiziert. Alle Ereignisauslöser und Verzweigungsmöglichkeiten in Dialogen sollten auch im Ablaufmodell berücksichtigt sein.


Jeder identifizierte Dialog wird wie folgt essenziell dokumentiert:

In einer Folgeaktivität Dialog spezifizieren werden Dialogelemente der essenziellen Beschreibungen detailliert spezifiziert. Die Konsolidierung aller identifizierten und essenziell beschriebenen Dialoge kann entweder durch die Arbeitsauftragsverantwortlichen untereinander oder durch den fachlichen Architekt geschehen.


Begründung:

Auslöser:

Vorbedingung:

Anforderungsworkshop (Entwurfsphase) wurde durchgeführt. Arbeitsaufträge wurden vergeben. In der Entwurfsphase sollten die Wichtigsten d. h. ca. 30 % der identifizierten Systemanwendungsfälle detailliert werden. Die Übrigen Sytemanwendungsfälle werden in der Konstruktionsphase detailliert.

Unterlagen:

E-20 Anforderungsspezifikation
E-7 Fachliches Glossar
E-6 Systemanwendungsfallbeschreibung [essenziell]
E-2 Systemanwendungsfallübersicht
E-115 Geschäftsklassenmodell

Gegenbedingung:

Ergebnisse:

E-38 Ablauf-/Aktivitätsdiagramm
E-152 Offene-Punkte-Liste
E-45 Dialogkomponentenspezifikation
E-59 Testfall
E-154 Kandidatenliste sekundärer Systemanwendungsfälle
E-139 Dialogablaufdiagramm

Besond. Hilfsmittel:

Als Hilfmittel eignen sich Flip-Chart-Papier, freie Flächen und eine Digitalkamera. Alle Arbeitsergebnisse werden mit Stiften zu Papier gebracht, am Ende fotografiert und aufbereitet ins Projektverzeichnis zur Verfügung gestellt.


Foto/Kamera
GUI-Prototyp Builder
Testunterstützungswerkzeug
Textverarbeitung
UML-Modellierungswerkzeug
Wiki

Verantwortlicher:

projektintern.SystemanalytikerIn

Beteiligte:

projektintern.SystemanalytikerIn
projektintern.Fachexperte

Nachfolg. [Beding.]:

A-233 Systemanwendungsfallmodell entwickeln
A-230 Geschäftsklassenmodell entwickeln
A-231 Berichte und Auswertungen identifizieren und beschreiben
A-26 Dialog spezifizieren

OEP - Object Engineering Process, v3.0, 06.11.2006 11:04:36, Copyright © 2006 by oose Innovative Informatik GmbH