Wie in der Schachtelung der Prozesse aus einem vorigen Post beschrieben, können Use Cases für die Beschreibung und das Testen eines Soll-Prozesses eingesetzt werden.
Wichtig ist zum einen, den Prozessablauf in einem visualisierten Ablaufdiagramm gemeinsam zu erarbeiten. Wie er dann angewendet werden kann, ist aber mindestens genauso wichtig.
Hier bietet sich der Use Case schon ganz zu Beginn des Projekts an. Am Beispiel eines Kundenkaufprozesses kann ein Kunde eine Anfrage für einen direkten Kauf stellen, aber auch ein Angebot, oder aber eine komplexe Anfrage stellen, die viele Zwischenschritte benötigt. Hier stellt sich zuerst die Frage, sind das unterschiedlich ausgeprägte Prozesse, oder sind es in einem Prozess mit vielen Abzweigungen die Anwendung des Prozesses?
Es kommt bei der Entscheidung, ob es eigene Prozesse sind darauf an, wie komplex ein Ablaufdiagramm ist, und wie verständlich es bei einer grösseren Komplexität für die Zielgruppe ist.
Grundsätzlich sollte aber selbst ein einfacher Prozess mit einem konkreten Beispiel beschrieben werden.
- Aufnahme Prozess: Der Startpunkt ist die Aufnahme des Prozesses. Idealerweise ist eine einfache Visualisierung mit wenigen Schritten für den Start schon vorbereitet.
- Anforderungen und Use Cases sind bekannt: Um einen Soll-Prozess beschreiben zu können, müssen die Anforderungen an den Soll-Prozess im Vorfeld klar sein, oder gemeinsam im Projektteam erarbeitet werden – die Unterscheidung muss allen klar sein, ob ein vorbereiteter Prozess diskutiert wird, oder ein Prozess gemeinsam erarbeitet wird. Der Entscheid hat Auswirkungen auf den Wissensstand der Teilnehmenden und auf die Zeit des oder der Termine. Eine gemeinsame Dokumentation eines vorbereiteten Prozesses ist natürlich schneller erledigt als die generelle Erstellung eines Prozesses mit der Diskussion aller Eventualitäten und Reihenfolge. Wichtig ist aber, dass nicht nur der Prozess und die Abläufe, sondern auch die Anwendungsfälle für den Prozess bekannt sein sollten oder gemeinsam erarbeitet werden.
- Aufteilung Prozesse: In der Regel wird mit einem Prozess begonnen und in dem Prozess die Anwendungsfälle diskutiert, was zu unterschiedlichen Wegen in einem Prozess (Abzweigungen) führen kann. Hier muss eine Entscheidung getroffen werden, ob mit einer Prozessvisualisierung gearbeitet werden kann, oder die Visualisierung in mehrere Diagramme aufgeteilt werden sollte.
- Eine Prozess-Visualisierung mit allen Möglichkeiten: Eine Prozess-Visualisierung mit allen Möglichkeiten macht Sinn, wenn es ein einfacher Ablauf ist und wenige Abzweigungen hat, also einfach lesbar, verständlich und anwendbar ist. Oder auch wenn ein komplexer Ablauf mit allen Abhängigkeiten notwendig ist, in einer Visualisierung darzustellen, anstelle zwischen den Visualisierungen hin- und her zu springen.
- Mehrere Prozess-Visualisierungen pro Möglichkeit: Es ist hilfreich, wenn die Darstellung aus Komplexitäts- oder Verständnis-Gründen zu umfangreich ist. Auch macht es Sinn die Visualisierung aufzuteilen, wenn unterschiedliche Bereiche den gleichen Prozess anwenden, nur mit ihrer eigenen Herangehensweise und eigenen Zwischenschritten.
- Detaillierte Dokumentation Use Case zu Test Case: Ob in einem oder mehreren Ablaufdiagrammen, muss die Anwendung mit einem oder mehreren Beispielen dokumentiert werden. Prozesse werden durch Anwendungsfälle formuliert und diese Anwendungsfälle müssen mit einem Beispiel aufgeschrieben werden. Dies hat den grossen Vorteil, dass wenn ein Anwendungsfall niedergeschrieben ist, dieser das Ablaufdiagramm bestätigt und erklärt und schon zu Beginn der Prozessaufnahme die Anforderungen an das oder die Systeme, die Verantwortlichkeiten an die Rollen und die konkrete Anforderung an das zu erstellendes oder anzupassendes System formuliert ist und später nach der Umsetzung genauso getestet werden kann. Use Cases können, wenn sehr komplex auch auf Phasen eines Prozesses aufgeteilt werden.
- Erstellung User Stories: Es ist immer schwierig zu Beginn aus den Prozessabläufen konkrete funktionale Anforderungen zu formulieren. Aus einem Beispiel für ein Prozess, ist das viel einfacher. So können die Voraussetzungen an Daten und Berechtigungen klar abgeleitet werden und die genaue funktionale Anforderung von Prozess-/Phasen-Beginn bis Prozess-/Phasen-Ende mit allen ihren funktionalen Abhängigkeiten ganz konkret und pro Schritt abgeleitet werden.
- Definition ist abgeschlossen: Diese erstellten User Stories pro Test Case und Use Case, sowie pro Prozess sind eine erste Liste von Anforderungen, mit denen in der Umsetzungsphase begonnen werden und sehr schnell auch im System getestet werden kann.