Das Anwendungsfall-Workshop ist ein organisiertes Brainstorming. Ein breites Wissensspektrum muss verfügbar sein:
-
Kundenanforderungen
-
Systemdesign
-
Einheitendesign
-
Rational Unified Process
-
Tests
Die Mitglieder der Gruppe haben unterschiedliche Hintergründe, Erfahrungen und Kenntnisse. Die Gruppe sollte nicht zu
groß sein (weniger als zehn Personen). Häufig besteht diese Gruppe zur Hälfte aus Entwicklern und zur anderen Hälfte
aus Ansprechpartnern von Benutzern. In der Mitte steht der Moderator. Er fungiert als Katalysator für alle Ideen und
Wünsche.
Es werden folgende Tools benötigt:
-
Zwei große Weißwandtafeln (eine genügt zwar, aber zwei sind besser)
-
Flip-Charts
-
Klebeband
-
Haftnotizen in zwei unterschiedlichen Farben
-
Stifte für die Weißwandtafeln in verschiedenen Farben
-
Bleistifte
-
Wände, auf denen Papier angebracht werden kann; vorzugsweise in einem "War Room", der zwei bis drei Wochen zur
Verfügung steht.
Legen Sie fest, wer oder was das System nutzen wird. Beginnen Sie mit Menschen, die das System nutzen wollen; für die
meisten Leute ist es einfacher, sich auf Konkretes statt auf Abstraktes zu konzentrieren. Während die Benutzer
identifiziert werden, identifizieren Sie ihre Rolle bei der Interaktion mit dem System. Dies ist meist eine gute
Beschreibung für einen Akteur.
Notieren Sie für jeden Akteur eine kurze Beschreibung. Normalerweise reicht eine nicht nummerierte Liste aus, um die
Rolle des Akteurs in Bezug auf das System und seine Zuständigkeiten zu erfassen. Diese Liste hilft später
festzustellen, was der Akteur tatsächlich vom System benötigt.
Wenn Sie Akteure definieren, vergessen Sie die Systeme nicht, mit denen das geplante System interagieren soll. Das
Symbol für Akteur ist hier missverständlich. Es scheint sich nur auf eine Person zu beziehen, aber der Begriff umfasst
auch Systeme. Konzentrieren Sie sich zunächst auf die "menschlichen" Akteure. Die meisten Gruppen arbeiten besser, wenn
sie sich zuerst auf das Bekannte konzentrieren können.
Beschäftigen Sie sich zum jetzigen Zeitpunkt nicht mit dem Anwendungsfallmodell oder den Beziehungen zwischen den Akteuren.
Listen Sie nur die Menschen oder Systeme auf, die das geplante System nutzen werden. Konzentrieren Sie sich auf die
Identifikation und akzeptieren Sie viele Akteure. Überlegen Sie nicht lange, wer bzw. was in die Liste aufgenommen
werden soll; dies erfolgt später mit der Identifizierung der Anwendungsfälle (siehe unten).
Stellen Sie sich folgende Frage: Welche Rollen in der Organisation werden das System verwenden? Zeichnen Sie für jede
vorgeschlagene Rolle ein Strichmännchen und schreiben Sie einen Namen darunter. Erstellen Sie auf der Weißwandtafel
zwei Listen mit Akteuren - jeweils eine links und eine rechts der bereits gezeichneten Wolke oder des Symbols. Manchmal
ist es besser, das Wort Rolle oder Benutzer und nicht das Wort Akteur zu verwenden.
Wichtige Fragen:
-
Wer wird das System verwenden?
-
An welche anderen Systeme soll dieses System Informationen senden?
-
Von welchen anderen Systeme soll dieses System Informationen erhalten?
-
Wer startet das System?
-
Wer pflegt die Benutzerdaten?
Sie werden evtl. Fragen hören wie: "Warum ist Tom nicht der Akteur? Tom macht das immer." Sie müssen dann weitere
Fragen stellen, um Toms Rolle zu verstehen. Der Name des Akteurs sollte die Rolle reflektieren.
-
Was ist Toms Rolle?
-
Wer kann diese Rolle sonst noch ausfüllen?
-
Warum hat Tom diese Rolle?
Viele Akteure können direkt über ihre normalen Positionen in der Organisation identifiziert werden. Jede Position in
der Organisation sollte mehr als einer Rolle im System entsprechen. Beispiel: Tom ist ein normaler Lagerarbeiter. Er
hat die zusätzliche Aufgabe, das Lager neu zu organisieren, um Platz für neue Produkte zu schaffen. Diese zwei
Zuständigkeitsbereiche sind evtl. zwei verschiedene Akteure im System.
Einige Leute wollen extrem generalisieren. Sie schlagen vielleicht den Benutzer als Akteur vor und sagen dann, dass
dies der einzige Akteur ist, der wirklich gebraucht wird. Korrekt - aber langweilig. Außerdem wird dadurch das System
nicht besser verständlich. Falls dieser Vorschlag gemacht wird, versuchen Sie, ihn nicht zu diskutieren. Schreiben Sie
den Akteur Benutzer auf die Tafel und gehen zum nächsten Akteur über.
-
Fragen Sie jeden Einzelnen, ob noch etwas fehlt.
-
Machen Sie ein paar schlechte Vorschläge. So kann das Team Sie korrigieren und Ihnen die genauen Rollen des Systems
erklären.
-
Akzeptieren Sie immer alle Vorschläge. Duplikate oder falsche Angaben können Sie später immer noch löschen. Wenn
Sie einen Vorschlag kritisieren, werden andere vielleicht gar nicht mehr gemacht.
Das Definieren von Akteuren dauert normalerweise 1 bis 4 Stunden. Auf der Tafel sind jetzt viele Akteure aufgelistet,
aber es sollte noch Platz für Anwendungsfälle sein. Wenn die Akteurgruppe vollständig zu sein scheint, ist es Zeit,
sich um die Anwendungsfälle zu kümmern.
Löschen Sie die Wolke oder das Symbol von der Tafel und starten Sie mit der Identifizierung der Anwendungsfälle. Konzentrieren Sie sich auf konkrete Anwendungsfälle
und vermeiden Sie die Diskussion über Include-
und Extend-Beziehungen. Zeichnen Sie eine Ellipse und schreiben Sie einen Namen für jeden
Vorschlag. Zeichnen Sie Pfeile zu den Akteuren.
Nutzen Sie die Tatsache, dass Sie nichts über die Anwendung wissen, als Stärke. Die Teilnehmer des Workshop müssen
Ihnen sagen, was das System tun soll. Stellen Sie viele Fragen zum System. Wenn die Teilnehmer Antworten geben, treten
Anwendungsfälle zu Tage.
Es gibt Leute, die das Konzept der Anwendungsfälle sofort verstehen, aber es gibt auch andere. Um dem Konzept eine
andere Perspektive zu geben, lassen Sie jemanden eine Systemansicht zeichnen. Eine Systemansicht ist die Abstraktion
des Systems. Beispiel: Ein Server mit einer Datenbank und mehreren Clients oder mehrere Platinen, die mit ihren
speziellen Aufgaben gekennzeichnet sind. Diese Ansicht kann normalerweise leicht angefertigt werden: einer der
Teilnehmer illustriert auf der Weißwandtafel die Funktion des Systems. Die Systemansicht hilft dabei, die
Anwendungsfälle von Systemgrenze zu Systemgrenze zu erweitern und deuten implizit verschiedene Systemstatus an. Stellen
Sie Fragen zu diesen Status. Dann ergeben weitere Anwendungsfälle. Prüfen Sie, was passiert, wenn Kommunikationswege
nicht funktionieren. Dadurch können Alternativflüsse in den Anwendungsfällen identifiziert werden.
Wenn Sie mit einem technischen System arbeiten, kennen alle oft die Systemansicht und können daher so die Akteure am
besten bestimmen. In einem solchen Fall sollten Sie die Systemansicht zeichnen lassen, bevor Sie nach den Akteuren
fragen.
Wenn Sie mit einem Verwaltungssystem arbeiten, ist die Systemansicht evtl. nicht so eindeutig. In diesem Fall kann eine
grafische Darstellung der Routinen hilfreich sein. Die Grafik kann darstellen, wie ein Geschäftsobjekt von einer Person
zu einer anderen bewegt wird und was die Personen damit tun sollen. Für die Visualisierung von Bestellung und
Auslieferung zeigt die Grafik evtl. eine schematische Ansicht des Kundenbüros, unseres Büro, eines Lager und des
Kundenlagers.
Stellen Sie sicher, dass das Anwendungsfallmodell und die Systemansicht bzw. das Geschäftsobjekt für alle klar
erkennbar sind. Hier wird der Einsatz von zwei Weißwandtafeln sinnvoll.
Die Anwendungsfälle dürfen lange Namen haben. Der Name eines gerade identifizierten Anwendungsfalls darf so lange wie
ein Satz sein. Er kann dann als Kurzbeschreibung verwendet werden, bevor der Name selbst abgekürzt wird.
Einige der angegebenen Anwendungsfälle werden immer Teile gemeinsam haben. Stellen Sie sicher, dass alle Teilnehmer
verstehen, dass dies momentan in Ordnung ist. Es ist nicht sinnvoll, jetzt schon mit der Strukturierung zu beginnen,
weil der Inhalt der Anwendungsfälle noch nicht genügend bekannt ist. Erst dann, wenn Ihnen der Ablauf erläutert wurde,
sollten Sie die Aufmerksamkeit auf Abhängigkeiten der Anwendungsfälle untereinander lenken.
Wenn die Gruppe einig ist, dass die Anwendungsfälle auf der Tafel die Funktionalität des gesamten Systems abdecken,
gehen Sie alle zum Mittagessen.
Danach prüfen Sie die Ergebnisse der Sitzung vom Vormittag:
-
Prüfen Sie jeden Akteur: Welche Aufgaben hat er oder sie in diesem System? Für
Leute, die mit der Anwendungsfallmodellierung nicht vertraut sind, ist der Begriff Aufgabe wahrscheinlich besser
verständlich.
-
Prüfen Sie die vorgeschlagenen Anwendungsfälle: Erkennen Sie den Wert, den der Benutzer durch
diesen Anwendungsfall bekommt? Hat der Anwendungsfall ein positives Ergebnis, ist der Benutzer eher bereit, ihn
durchzuführen.
-
Prüfen Sie jeden vorgeschlagenen Anwendungsfall: Ist er vollständig? Oder ist er nur ein kleiner Teil von etwas
Größerem?
Wichtige Fragen:
-
Jeder Akteur sollte mindestens einen Anwendungsfall haben. Ist das nicht der Fall, ist der Akteur vielleicht ein
Duplikat (ein anderer hat dieselbe Rolle) oder der Akteur ist nicht wirklich ein Direktbenutzer des Systems. Wenn
jetzt die Diskussion darüber, welche Vorteile dieser Akteur hat, keine Ergebnisse bringt, muss er entfernt werden.
Arbeiten Sie die Anwendungsfälle einzeln durch und erstellen Sie eine Flip-Chart für jeden. Zeichnen Sie oben auf der
Flip-Chart ein Ellipse und schreiben Sie den Namen des Anwendungsfalls hinein. Nehmen Sie einen Bleistift und bitten
Sie die Gruppe, Ihnen beim Erstellen der Kurzbeschreibung für den Anwendungsfall behilflich zu sein. Die
Kurzbeschreibung besteht aus 1 bis 3 Sätzen. Manchmal ist es sinnvoll, die Akteur zu zeichnen, die mit dem
Anwendungsfall verbunden sind. Die Hälfte des Papiers sollte für den nächsten Schritt frei bleiben.
Stellen Sie während dieser Phase fest, ob Dinge, die bisher allen klar schienen, jetzt nicht mehr klar sind. Beziehen
Sie sich auf die Anforderungen, die im Abschnitt Anforderungen und Features der Benutzer in Vision
beschrieben sind. Versuchen Sie festzustellen, ob es für diesen Anwendungsfall Anforderungen
gibt.
Neue Anwendungsfälle ergeben sich. Andere fallen weg. Hängen Sie die Blätter mit den Anwendungsfällen an die Wände.
Versuchen Sie, sie mit einer Spalte pro Funktionsbereich zu organisieren. (Verwenden Sie hier die Weißwandtafeln nicht,
sie werden für Systemansichten, Akteure und Anwendungsfälle gebraucht.) Wenn Sie eine Frage nicht sofort beantworten
können, schreiben Sie sie auf eine Haftnotiz und kleben Sie sie auf den entsprechenden Anwendungsfall. Verwenden Sie
für alle Fragen die gleiche Farbe.
Wenn alle Anwendungsfälle auf einer Flip-Chart stehen und eine Kurzbeschreibung haben, geht es weiter mit dem nächsten
Schritt. Häufig ist es sinnvoll, darüber zu diskutieren, ob wirklich alle Anwendungsfälle erforderlich sind.
Das so erstellte Modell kann in Rational
Rose oder Rational RequisitePro dokumentiert werden; dann kann ein
Übersichtsbericht für das Anwendungsfallmodell erstellt werden.
Bevor ein Anwendungsfall geschrieben wird, muss der Text strukturiert werden. Es ist nicht sinnvoll, die Struktur ohne
Unterstützung durch Input von anderen Stakeholdern zu erstellen.
Arbeiten Sie die Anwendungsfälle einzeln durch. Schreiben Sie die unterschiedlichen Aktionen in ihrer Reihenfolge auf.
Denken Sie nicht an die spätere Codestruktur, an Schleifen, For-while-Anweisungen, etc. Bearbeiten Sie nur den
grundlegenden Ereignisablauf, lassen Sie mögliche Alternativen außer Acht. Nummerieren Sie die Schritte 1, 2, 3, 4 etc.
Damit die Gruppe den erforderlichen Detaillierungsgrad kennt, können Sie z. B. sagen, der Basisfluss besteht aus fünf
bis zehn Schritten.
Nachdem Einigkeit über den Basisfluss besteht, sehen Sie ihn sich an und identifizieren Alternativschritte. Nennen Sie
die Alternativen im Fluss A1, A2, A3, A4.
Während dieser Diskussion werden Themen besprochen, von denen viele erst während der Analyse- & Designphase gelöst werden. Vergessen Sie nicht, alle
Themen und Voraussetzungen aufzuschreiben. Manche Probleme müssen schnell gelöst werden, damit der Anforderungsautor den Ereignisablauf detailliert und korrekt
beschreiben kann. Für andere Themen braucht erst direkt vor der Analyse- & Designphase eine Lösung gefunden werden.
Die Informationen auf den Flip-Chart sollten dem Anforderungsautor genügen, den Ereignisablauf des Anwendungsfalls
detailliert zu beschreiben.
Während dieser Sitzung kann es mehrere Anforderungen an
das System geben, die nicht sofort in einem Anwendungsfall erfasst werden können. Diese Anweisungen haben normalerweise
mit allgemeiner Funktionalität, Benutzerfreundlichkeit, Zuverlässigkeit, Leistung und Servicefreundlichkeit des Systems
zu tun. Für diese Informationen sollten Sie eine eigene Flip-Chart haben. Sie dienen als Basis der ergänzenden Spezifikationen.
Gehen Sie die wichtigsten Stakeholder-Anfrage und alle Features im Visionsdokument durch. Stellen Sie sicher, dass das
Anwendungsfallmodell sie abdeckt. Diskutieren Sie, welche Benutzeranforderungen zu welchen Anwendungsfällen gehören.
Lesen Sie im Visionsdokument das erste Feature.
Schreiben Sie seine Identität auf eine Haftnotiz (oder auf mehrere, falls erforderlich). Verwenden Sie eine andere
Farbe, um Anforderungen von Problemen zu unterscheiden. Platzieren Sie die Notiz auf die Anwendungsfälle, die diese
Anforderung erfüllen. Geben Sie die Traceabilities
(Rückverfolgbarkeiten) in Ihr RequisitePro-Repository ein.
Es gibt immer Anforderungen, die mit keinem Anwendungsfall verbunden werden können:
-
Es kann sich um spezifische Anforderungen handeln, die erst im Design zum Tragen kommen. Notieren Sie sich diese
Designanforderungen auf Papier.
-
Es kann sich um allgemeine Anforderungen handeln, die keinem Anwendungsfall zugeordnet werden können. Notieren Sie
sie in der Liste der ergänzenden Spezifikationen.
-
Es kann sich um Anforderungen handeln, die vergessen wurden und entweder neue Anwendungsfälle brauchen oder für die
bestehende Anwendungsfälle geändert werden müssen.
Nehmen Sie sich Zeit, um die Struktur des Raums zu prüfen: Gibt es Anwendungsfälle ohne Anforderungen? Warum? Ist
dieser Anwendungsfall nicht erforderlich? Oder wurde diese Funktionalität von der Person vergessen, die die
Anforderungspezifikation geschrieben hat? (Das ist der häufigste Fall.) Die Situation muss bereinigt werden. Weiß der
Kunde, dass er dieses Leistungsmerkmal benötigt? Ist er bereit, dafür zahlen?
|