Richtlinie: Anwendungsfall-Workshops
Diese Richtlinie beschreibt, wie Sie ein Anwendungsfall-Workshop vorbereiten und durchführen.
Beziehungen
Hauptbeschreibung

Workshop organisieren

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.

Tools

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.

Akteure definieren

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).

Ein Verwaltungssystem

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?

Im Begleittext beschriebenes Diagramm.

Instanz oder Klasse?

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.

Tricks und Tipps

  • 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.

Im Begleittext beschriebenes Diagramm.

Anwendungsfälle definieren

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.

Kurzbeschreibung für Anwendungsfall erstellen

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.

Im Begleittext beschriebenes Diagramm.

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.

Schrittweise Beschreibung des Ereignisablaufs für jeden Anwendungsfall

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.

Im Begleittext beschriebenes Diagramm.

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.

Ergänzende Spezifikationen erfassen

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.

Anwendungsfälle den Anforderungen zuordnen

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.

Im Begleittext beschriebenes Diagramm.

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?