Aktivität

[Eigene Ergänzungen/Erfahrungen bearbeiten]

Anforderungsanalyse

A-226 Anforderungsworkshop durchführen (Vorbereitungsphase)

Ein maximal 2-tägiger Workshop wird mit den wichtigsten Anforderungsbeitragenden durchgeführt. Darin werden die grundlegenden Anforderungen in kurzer und abstrakter Form dokumentiert. In den Folgephasen werden sie weiterentwickelt und detailliert.

Aktivität muss durchgeführt werden in Vorbereitungsphase (Singuläre Aktivität)


Der erste Anforderungsworkshop wird mit allen wichtigen Anforderungsbeitragenden innerhalb eines Tages (max. 2 Tage) durchgeführt. Während des Workshops werden die wichtigsten Anforderungen gesammelt und grob dokumentiert. Die daraus resultierenden Ergebnisse bilden die Basis für die folgenden Aktivitäten und werden in späteren Phasen weiterentwickelt und detailliert.

Bei der Anforderungssammlung sollte so vorgegangen werden, dass sich alle gesammelten Anforderungen auf dem gleichen Abstraktionsnieveau befinden. Um dies zu erreichen, wird zunächst eine Liste mit den wichtigsten Systemanwendungsfällen erstellt. Anschließend werden die wichtigsten Systemanwendungsfälle in einer bestimmten Form, der so genannten essenziellen Beschreibung, beschrieben. Dies ergibt eine gute Ausgangsbasis: Die wichtigsten Anforderungen wurden genannt und befinden sich auf der gleichen Abstraktionsebene. Bei den weiteren Ergebnissen fällt es den Teilnehmenden nun leichter zu entscheiden, welche wirklich wichtig sind und mit der Systemidee zu tun haben, und sie haben ein Gefühl dafür bekommen, unterschiedliche Abstraktionsebenen zu erkennen und bei der Analyse einzuhalten.

Der Workshop wird von einem Systemanalytiker moderiert. Die einzelnen Aktivitäten werden in festgelegten Timeboxen durchgeführt. Ziel des Workshops ist es, kurze prägnante Ergebnisse zu erzielen. Langatmige und Zeit raubenden Detaildiskussionen sind zu vermeiden. Der Moderator ist für die Vorgehensweise und zielführende Moderation verantwortlich.

Folgende Aktivitäten werden in folgender Reihenfolge in begrenzten Zeitabschnitten durchgeführt:



Systemgrenze definieren
Die Anforderungsanalyse beginnt zunächst damit, die Systemgrenze zu ermitteln. Für wen oder was soll ein System entwickelt werden? Dabei stehen folgende Fragen im Vordergrund:
Die Ergebnisse werden dokumentiert und den Projektmitgliedern zur Verfügung gestellt.

Systemanwendungsfall-Übersicht (Liste der wichtigsten Systemanwendungsfälle) erstellen
Die wichtigsten im Projekt zu berücksichtigenden Systemanwendungsfälle sollen identifiziert werden, soweit sie zu diesem Zeitpunkt bekannt sind.

Es wird eine Liste mit den Systemanwendungsfällen angelegt.

Jeder Systemanwendungsfall erhält eine Bezeichnung, die mindestens aus einem Substantiv und einem Verb besteht (z.B. "Vertrag anlegen"). Soweit notwendig sind erste einfache Recherchen und Rückfragen bei anwesenden Experten über das Anwendungsgebiet durchzuführen. Die Systemanwendungsfälle können, soweit entsprechende Informationen vorliegen, mit einer Kurzbeschreibung (1 - 3 Sätzen), möglichen Vor- bzw. Nachbedingungen und Akteuren kommentiert werden.

Ebenfalls können zu jedem Systemanwendungsfall die Namen von Ansprechpartnern/Experten notiert sowie andere Informationsquellen (Dokumente etc.) genannt werden, soweit diese hier bereits bekannt sind.

Der Systemanalytiker ist für die Vollständigkeit der Systemanwendungsfall-Identifizierung verantwortlich.

Negativliste:
Sofern nahe liegende Systemanwendungsfälle explizit vom Projektumfang ausgeschlossen werden sollen, werden sie in gleicher Weise beschrieben, erhalten jedoch den Status "ausgeschlossen".

Zusätzlich können die identifizierten Systemanwendungsfälle mit Hilfe von Systemanwendungsfalldiagrammen dargestellt werden. Dies ist in dem ersten Workshop nicht unbedingt nötig, die grafische Darstellung hilft zur besseren Abgrenzung zum Systemumfeld, außerdem können die Zusammenhänge der identifizierten Systemanwendungsfälle und ihrer Akteure veranschaulicht werden.

Das Systemanwendungsfallmodell enthält alle identifizierten Systemanwendungsfälle und die an ihnen beteiligten Akteure.

Ein Systemanwendungsfalldiagramm enthält eine Menge von Systemanwendungsfällen und deren Beziehungen untereinander sowie zu ihren Akteuren. Es enthält jeweils eine überschaubare Menge von Systemanwendungsfällen (1 Seite), d.h., in Abhängigkeit von der Anzahl der Systemanwendungsfälle werden ggf. mehrere Einzeldiagramme angelegt. Jeder identifizierte Systemanwendungsfall kommt in mindestens einem Diagramm vor. Alle in den Systemanwendungsfällen genannten Akteure sind auch in den Diagrammen zu verwenden. Bei einer geringen Anzahl von Systemanwendungsfällen (weniger als 6) macht die Darstellung als Systemanwendungsfalldiagramm keinen Sinn.

Essenzbeschreibungen für die wichtigsten (ca. 20 %) Systemanwendungsfälle
Die identifizierten Systemanwendungsfälle werden detailliert durch: Derart beschriebene Systemanwendungsfälle führen den Status "essenziell beschrieben". Essenzielle Systemanwendungsfälle sind eine spezielle Form der Anwendungsfallbeschreibung, die keine Annahmen über bestimmte Technologien, Implementierungsbedingungen, Entwicklungsumgebungen etc. treffen, sondern in abstrakter Weise nur die eigentliche Intention beschreiben. Beispielsweise wird im Systemanwendungsfall "Geld aus Geldautomat holen" statt "1. Karte einschieben, 2. PIN eingeben" ganz abstrakt die Formulierung "Kunde identifizieren" verwendet. Ein essenziell beschriebener Systemanwendungsfall besteht dadurch nur noch aus wenigen aufgelisteten Sätzen. Systemanwendungsfälle mit dem Status "ausgeschlossen" werden nicht weiter detailliert.

Sofern während dieser Aktivität neue Systemanwendungsfälle erkannt werden, werden sie in die Liste der Systemanwendungsfälle aufgenommen (vorangehende Aktivität) und anschließend ebenfalls essenziell beschrieben.

Soweit notwendig, sind erste einfache Recherchen und Rückfragen bei anwesenden Experten über das Anwendungsgebiet durchzuführen.

Alle wichtigen Fachbegriffe (inkl. Synonyme und Homonyme), die im Rahmen der Systemanwendungsfallanalyse vorkommen, werden in einem Fachglossar erläutert (ca. 2 - 10 Zeilen Text). Das Glossar wird vom Domänenexperten erstellt und gepflegt. Der Systemanalytiker prüft am Ende dieser Aktivität, ob alle wichtigen Fachbegriffe aus den Systemanwendungsfällen im Glossar eingetragen und verständlich erläutert sind.

Nichtfunktionale Anforderungen identifizieren
Mit Systemanwendungsfällen werden vorwiegend funktionale und geschäftsorientierte Anforderungen beschrieben. Systemanwendungsfälle können im Kontext ihrer Anforderungen auch nichtfunktionale Anforderungen, wie beispielsweise anwendungsfallspezifische Qualitäts- und Sicherheitsanforderungen, beinhalten.

Grundsätzliche Anforderungen an Qualität, Sicherheit, Systemverfügbarkeit, Robustheit usw. werden, soweit vorhanden, im Rahmen dieser Aktivität separat dokumentiert.

Ebenso werden alle funktionalen und nichtfunktionalen Anforderungen, deren Relevanz zwar nahe liegt, die aber im Rahmen dieses Projektes nicht erfüllt werden müssen bzw. nicht erfüllt werden sollen, explizit erwähnt und kurz in einer Ausschlussliste beschrieben.

Zu den nichtfunktionalen Anforderungen gehören unter anderem: Features identifizieren
Ein Feature ist eine Sammlung einer Menge einzelner Anforderungen jedweder Granularität. Eine detaillierte Planung aufgrund von Features ist daher nicht möglich, sie helfen jedoch in der Anforderungsanalyse bei der Sammlung von Anforderungen. Übergangsweise stellen sie jeweils ein Sammelbecken für unterschiedlichste Anforderungen dar, vor allem wenn noch keine eindeutige Zuordnung zu einer Anforderungsart (funktionale Anforderung, allgemeine Anforderung, etc.) möglich ist und die Vollständigkeit, Widerspruchs- und Redundanzfreiheit noch nicht gewährleistet ist. Zu einem späteren Zeitpunkt können die gesammelten Features genauer untersucht und einer Anforderungsart zugeordnet werden.
Bei der Sammlung von Anforderungen ist vielen Anforderungsbeitragenden schnell klar, dass zum Beispiel eine Kundenverwaltung oder Dokumentenverwaltung benötigt wird. Zu diesem Zeitpunkt im Workshop sind bereits die wichtigsten Systemanwendungsfälle benannt, sie können zu sinnvollen Features gebündelt werden. Weitere genannte Features helfen, um noch nicht bekannte Systemanwendungsfälle oder andere Anforderungen zu identifizieren.
Die genannten Features werden auf einer Liste dokumentiert. Ggf. sind Ansprechpartner mit aufzunehmen.

Auszuschließende Anforderungen identifizieren
Systemanwendungsfälle, nichtfunktionale Anforderungen oder Features, die nicht für das zu realisierende System relevant sind, werden als solche in ihren Beschreibungen gekennzeichnet und auf einer Ausschlussliste gesammelt. Sie sind im Allgemeinen nicht näher zu detaillieren.

Subsysteme identifizieren und, soweit es sich ergibt, ein erstes grobes Geschäftsklassenmodell entwickeln
Das Gesamtsystem wird in fachliche Subsysteme untergliedert.

Ausgangsbasis hierfür sind die Systemanwendungsfälle, das Glossar, das Geschäftsklassenmodell (soweit vorhanden) und die darin genannten Fachbegriffe und Geschäftsklassen.

Beispiel: Im Rahmen eines Versicherungssystems ließen sich die Subsysteme "Partner", "Vertrag", "Schaden" etc. identifizieren. Die Unterteilung in fachliche Subsysteme ist notwendig, um das zukünftig zu entwickelnde System zu veranschaulichen. Aus dem Ergebnis können aber auch zahlreiche Anhaltspunkte abgeleitet werden, wie die zukünftige Projektorganisation günstig gestaltet werden könnte.

Bei kleineren Projekten wird das Projekt komplett als ein "Subsystem" betrachtet, eine Untergliederung ist dann nicht sinnvoll. Das Ergebnis ist als UML-Subsystemmodell darzustellen. Die strukturellen Zusammenhänge der wichtigsten fachlichen Gegenstände werden in Form eines UML-Geschäftsklassenmodells beschrieben.

Aus den Systemanwendungsfällen werden die wichtigsten fachlichen Gegenstände abgeleitet. Eine Liste der identifizierten Geschäftsklassen wird erstellt, ein erstes grobes Geschäftsklassenmodell abgeleitet.

Dieses Geschäftsklassenmodell soll die grundsätzliche Problemstruktur und die Zusammenhänge der wichtigsten fachlichen Begriffe beschreiben. Es werden somit ganz allgemeine und damit den Systemanwendungsfällen übergeordnete Anforderungen beschrieben (beispielsweise "1 Kunde hat n Anschriften"). Auf eine Detaillierung wird in der Vorbereitungphase verzichtet.

Alle im Geschäftsklassenmodell vorkommenden Geschäftsklassennamen sollten als Fachbegriffe im Glossar definiert sein.

In nachfolgenden Iterationen oder wenn aus anderen Gründen jetzt bereits ein Geschäfsklassenmodell vorliegt, wird dieses aktualisiert und ggf. restrukturiert, um neue Erkenntnisse aus den genannten Beschreibungen, Dokumenten etc. einzuarbeiten.

Es werden nur die fachlich relevanten Klassen, die sog. Geschäftsklassen betrachtet, und von diesen ggf. nur eine ausgewählte Menge, d.h. die wichtigsten. Durch Abstraktion gefundene Klassen, Basisklassen, technisch motivierte Klassen, Schnittstellen, Steuerungsklassen u.Ä. werden außer Acht gelassen.

Eventuell. vorhandene Referenzmodelle (alte oder aktuelle Datenmodelle u.Ä.) können herangezogen werden, um Hinweise oder Lösungskonzepte zur fachlichen Strukturierung des Anwendungsgebietes zu erhalten.

Bei der Erstellung des Geschäftsklassenmodells sollte der Fokus auf den Assoziationen liegen (inkl. den Spezialformen Aggregation und Komposition). Beziehungs- und Rollennamen, Multiplizitäten und Zusicherungen sollten, soweit bekannt, notiert werden. Vererbungsbeziehungen sollten nur soweit notwendig modelliert werden. Eine aktive Suche nach Generalisierungen/Spezialisierungen und der elegantesten Vererbungsstruktur sollte vermieden werden.

Berichte und Auswertungen identifizieren
Alle externen Erzeugnisse, die von dem System produziert werden sollen oder deren Produktion durch das System ausgelöst werden, sind zu identifizieren.

Als externe Erzeugnisse des Systems werden hier alle Dinge betrachtet, die zur Erfüllung oder als Ergebnis der unterstützten Geschäftsprozesse entstehen, beispielsweise Als Erzeugnisse gelten hierbei unter anderem

Ob es sich dabei um individuelle, standardisierte oder automatisierte Erzeugnisse handelt, ist nebensächlich. Ebenso, in welchem Medium die Ergebnisse zu finden sind (Papier, Postversand, Fax, E-Mail, Datenträger, Chipkarten, andere kodierte Karten, Barcodes etc.)

Es ist eine Liste der identifizierten Systemerzeugnisse zu erstellen, die die Erzeugnisse benennt (möglichst je ein Substantiv), Inhalt, Zweck und Häufigkeit kurz beschreibt (2 - 10 Zeilen Text), auf ein Muster verweist und die derzeitig produzierende/verantwortliche Stelle benennt. Gegebenenfalls gibt sie auch Hinweise zu Änderungswünschen bezüglich der Erzeugnisse (Was soll geändert werden? Wann? Wer benötigt dies?).

Erzeugnisse, deren Produktion vom System erwartet wird oder werden könnte, die aber nicht im Rahmen des aktuellen Projektes enthalten sein sollen, sind ebenfalls zu betrachten und als solche zu kennzeichnen. Sie werden ebenfalls in die Ausschlussliste aufgenommen.

Batch-Programme identifizieren
Identifizierung von Funktionalitäten und Systemanwendungsfällen, die keinen menschlichen Akteur haben, sondern automatisch ausgelöst werden, sowie von Funktionalitäten, die außerhalb der objektorientierten Anwendungsarchitektur liegen.

Batchprogramme und nichtobjektorientierte Programme sollten unter Umständen nicht in Form von Systemanwendungsfällen beschrieben werden (auch wenn dies prinzipiell möglich wäre). Stattdessen werden die Spezifikations- und Dokumentationsformen verwendet, die hierfür bislang in der Entwicklungsorganisation verwendet wurden.
Im Rahmen dieser Aktivität geht es zunächst darum, diese Programm- bzw. Systemteile zu identifizieren. Betrachtet werden sollen solche Funktionalitäten, die Neben den beteiligten Experten, die befragt werden müssen, sind die vorhandenen Systemanwendungsfallbeschreibungen systematisch nach möglichen Kandidaten hierfür zu durchsuchen.

Systemschnittstellen identifizieren und klassifizieren
Systeme und Schnittstellen, zu denen das zu entwickelnde System Kontakt hat, werden identifiziert und bezüglich ihrer Komplexität kurz bewertet.

Alle Schnittstellen und Systeme, die vom zu entwickelnden System möglicherweise zu berücksichtigen sind, werden genannt und dokumentiert.

Zu jeder Schnittstelle soll beschrieben werden: Sofern sich herausstellt, dass eine Schnittstelle im Rahmen des Projektes nicht berücksichtigt werden muss, wird sie dennoch in obiger Form beschrieben, jedoch mit einem Ausschlusshinweis versehen, der darüber informiert, warum die Schnittstelle nicht berücksichtigt werden muss.

Soweit bereits in dem ersten Workshop bekannt, werden zusätzlich dokumentiert: Die vorhandenen Systemanwendungsfall-Beschreibungen werden systematisch ausgewertet, um Hinweise auf Schnittstellen und externe Systeme zu erhalten.

Der Domänenexperte ist ergebnisverantwortlich, wird aber Untersuchungen u.Ä. an den Schnittstellenexperten delegieren. Systemanalytiker und Chefarchitekt wirken insoweit mit, als dass sie die Zusammenhänge und Abhängigkeiten mit der fachlichen und technischen Architektur betrachten und somit zur Bewertung der Schnittstellen beitragen.

Ggf. werden im Rahmen der Schnittstellenanalyse noch weitere Systemanwendungsfälle und sinnvolle Glossareinträge entdeckt.

Als Hilfmittel für den Workshop eignen sich Flipchart-Papier, freie Flächen und eine Digitalkamera. Alle Arbeitsergebnisse werden mit unterschiedlichen Arbeitstechniken (Brainstorming, Brainwriting, Clustering, Mindmapping etc.) entwickelt und zu Papier gebracht. Am Ende jeder Timebox werden die Ergebnisse fotografiert. Eine neue Session kann beginnen. Alle am Ende des Workshops gesammelten Ergebnistypen werden elektronisch ins Projektverzeichnis zur weiteren Bearbeitung gestellt.


Begründung:

Auslöser:

Vorbedingung:

Die Anforderungsbeitragenden müssen identifiziert und dokumentiert worden sein. Ein Projektauftrag muß bestehen, die Systemidee und Zielsetzung muß den teilnehmenden Personen verständlich sein.

Unterlagen:

E-150 Liste der Anforderungsbeitragenden
E-1 Projektauftrag
E-148 Systemvision

Gegenbedingung:

Ergebnisse:

E-2 Systemanwendungsfallübersicht
E-7 Fachliches Glossar
E-115 Geschäftsklassenmodell
E-6 Systemanwendungsfallbeschreibung [essenziell]
E-76 Katalog der Stapelverarbeitungsprogramme
E-75 Katalog der Druck- und Ausgabeerzeugnisse
E-9 Katalog externer Schnittstellen
E-71 Katalog nichtfunktionaler Anforderungen
E-77 Bericht
E-63 Schnittstellenspezifikation
E-24 Katalog aller offenen Probleme
E-155 Ausschlussliste
E-158 Liste mit Features und übergreifenden Anforderungen
E-168 Workshop-Protokoll
E-58 Subsystem [*]
E-54 Subsystemmodell

Besond. Hilfsmittel:

Flip-Chart-Papier, freie Flächen
Foto/Kamera
Problemdatenbank
Textverarbeitung
UML-Modellierungswerkzeug
Wiki

Verantwortlicher:

projektintern.SystemanalytikerIn

Beteiligte:

projektintern.Fachliche Projektleitung
projektintern.Fachexperte
projektextern.AnwenderIn
projektintern.FachlicheR ArchitektIn

Nachfolg. [Beding.]:

A-228 Anforderungsworkshop durchführen [Im zweiten Anforderungsworkshop werden die Arbeitsergebnisse aus diesem Workshop weiterentwickelt und detailliert.]
A-15 Anforderungsspezifikation zusammenstellen

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