1.4 Prozessbeschreibung
Im Bereich der Prozessbeschreibungen sollten Sie alle geplanten Funktionen der Anwendung so genau wie möglich definieren. Am einfachsten beginnen Sie dazu mit der Definition von User Stories, in denen Sie die fachlichen Anforderungen zusammentragen. Aufbauend auf die User Stories und die verwendeten Objekte in der Anwendung können Use Cases erstellt werden. Mithilfe der Use Cases können die grundlegende Anwendungsstruktur, benötigte Trigger im UI und die Rollenzugehörigkeiten zum Auslösen der Trigger grafisch dargestellt werden.
Als letzten Schritt können Sie anhand der Use Cases die benötigten Programmablaufpläne erstellen.
Mit diesem Vorgehen hangeln Sie sich von einer sehr fachlichen und unscharfen Sicht auf die Anwendung in den User Stories über eine Funktions- und Rollenübersicht in den Use Cases hin zu einem hohen technischen Detailgrad in den Programmablaufplänen. Durch diese schrittweise Verfeinerung des Detailgrads nehmen Sie den Kunden von Anfang an mit, können ihm die fachlichen Wünsche entlocken und die technischen Anforderungen für die Umsetzung verdeutlichen. In keinem dieser Schritte ist technisches Know-how des Kunden erforderlich, und dennoch erhalten Sie im Anschluss ein Dokument, anhand dessen Ihnen jeder Entwickler ohne weitere Fragen die fertige Anwendung bauen kann.
Das Kapitel »Prozessbeschreibung« enthält alle fachlichen Anforderungen an die zu erstellende Anwendung und erläutert alle relevanten Objekte, wo diese im späteren UI zu finden sind und welche Rollenzugehörigkeit zum Aufrufen der jeweiligen Funktion erforderlich ist.
Dabei werden die fachlichen Anforderungen als User Stories definiert. Die entstandenen User Stories werden anhand von Use Cases mit den Objekten der Anwendung verknüpft, woraus grobe Vorgaben an das UI-Modell entstehen. Das bedeutet, dass an dieser Stelle definiert wird, welche Schaltflächen zum Aufrufen von Funktionen an welcher Stelle der Anwendung zur Verfügung stehen müssen. Zusätzlich werden die Berechtigungen der Benutzergruppen an die jeweiligen Use Cases geknüpft. Aufbauend auf die Use Cases werden die detaillierten Abläufe der Anwendung in Programmablaufplänen dargestellt.
1.4.1 User Stories
Um die fachlichen Anforderungen an eine Anwendung darzustellen, sind User Stories ein sehr gutes Hilfsmittel. Ohne die Notwendigkeit technischer Details schildert der Fachanwender die einzelnen Funktionen, die aus seiner Sicht für die Arbeit mit einer Anwendung notwendig sind. Dazu sollte jede Anforderung in einem oder zwei einfachen und möglichst präzisen Sätzen erläutert werden. Die technische Umsetzung ist dabei nicht von Belang. Es gilt lediglich, die Anforderung des Anwenders in Worte zu fassen. Aus jeder dieser User Stories ergibt sich im weiteren Verlauf das technische Design der Anwendung. Jede User Story wird auf technischer Ebene in eine oder mehrere Funktionen gekapselt und kann als einzelner Baustein in der Anwendung implementiert werden. Einzelne User Stories stellen somit in sich geschlossene, logische Arbeitspakete dar, nach deren Abarbeitung die Anwendung alle fachlichen Anforderungen des Benutzers erfüllen sollte.
Neben der Planung einer fachlich kompletten Anwendung stellen die einzelnen User Stories einen guten Grundstein für Anwendungstests im Bereich der Qualitätssicherung dar. Wird einer Person, der die fachlichen Anforderungen an die Anwendung nicht bekannt sind, die Liste der User Stories übergeben, kann sie trotzdem testen, ob die Anwendung alle an sie gestellten Anforderungen erfüllt. Die Summe der User Stories kann somit als Basis für einen Testkatalog betrachtet werden.
Achten Sie bei der Erstellung der User Stories darauf, dass der Anwender sich auf die Schilderung seiner Anforderung konzentriert und sich nicht von dem Versuch, technisch zu werden, ablenken lässt. Dem Aspekt der technischen Umsetzung wird im weiteren Verlauf Genüge getan, er würde in diesem Stadium lediglich von den fachlichen Anforderungen ablenken.
Nachfolgend werden die fachlichen Anforderungen an die Anwendung in den sogenannten User Stories zusammengefasst. Die Gesamtheit dieser User Stories stellt die zu erstellende Anwendung dar. Als User Story gelten Anforderungen an eine Softwareanwendung, die in einem, maximal zwei Sätzen beschrieben werden.
Priorität erstellen
Als Administrator oder Supportleiter möchte ich jederzeit neue Prioritäten für Tickets anlegen können.
Priorität anzeigen
Als Administrator oder Supportleiter möchte ich alle Prioritäten ansehen können.
Priorität ändern
Als Administrator oder Supportleiter möchte ich eine Priorität ändern können.
Priorität löschen
Als Administrator oder Supportleiter möchte ich eine bestehende Priorität löschen können.
Ticketstatus erstellen
Als Administrator oder Supportleiter möchte ich jederzeit neue Ticketstatus für Tickets anlegen können.
Ticketstatus anzeigen
Als Administrator oder Supportleiter möchte ich mir alle Ticketstatus ansehen können.
Ticketstatus ändern
Als Administrator oder Supportleiter möchte ich einen Ticketstatus ändern können.
Ticketstatus löschen
Als Administrator oder Supportleiter möchte ich einen bestehenden Ticketstatus löschen können.
Ticket erstellen
Als Kunde oder Supporter möchte ich ein neues Ticket in der Ticketliste erstellen können. Dabei muss ich den Betreff und eine Problembeschreibung angeben.
Benachrichtigung neuer Tickets
Als Supporter möchte ich automatisch über neue Tickets per E‐Mail informiert werden.
Ticket anzeigen
Als Kunde möchte ich jederzeit meine Tickets einsehen können.
Als Supporter möchte ich jederzeit alle für mich relevanten Tickets einsehen können.
Ticket bearbeiten
Als Administrator oder Supportleiter möchte ich bestehende Tickets bearbeiten können.
Ticket löschen
Als Administrator oder Supportleiter möchte ich bestehende Tickets löschen können.
Ticket übernehmen
Als Supporter möchte ich jederzeit ein nicht abgeschlossenes Ticket zur Bearbeitung übernehmen können.
Ticket weiterleiten
Als Supporter möchte ich jederzeit ein Ticket, das ich bearbeitet habe, an einen anderen Supporter weiterleiten können.
Kommentar erstellen
Als Supporter oder Kunde möchte ich jederzeit einen Kommentar zu einem bestehenden Ticket hinzufügen können.
Wenn Bearbeitungszeiten angefallen sind, möchte ich diese gemeinsam mit einem Bearbeitungskommentar dem Ticket hinzufügen können.
Kommentar bearbeiten
Als Administrator oder Supportleiter möchte ich bestehende Kommentare zu Tickets bearbeiten können.
Kommentar löschen
Als Administrator oder Supportleiter möchte ich in der Lage sein, einen bestehenden Kommentar aus einem Ticket zu entfernen.
Anhang hochladen
Als Supporter oder Kunde möchte ich jederzeit einen Anhang zu einem bestehenden Ticket hochladen können.
Alle hochgeladenen Anhänge zu einem Ticket sollen in diesem angezeigt werden.
Ticket abschließen
Als Supporter möchte ich die Möglichkeit haben, ein Ticket, das ich derzeit bearbeite, als abgeschlossen zu markieren.
Benachrichtigung Ticketänderung
Als Supporter oder Kunde möchte ich die Möglichkeit haben, über Änderungen an für mich relevanten Tickets per E‐Mail informiert zu werden.
Ticketerinnerung
Als Supporter möchte ich per E‐Mail an nicht bearbeitete Tickets erinnert werden.
Ticket eskalieren
Als Supportleiter möchte ich über die drohende Eskalation eines Tickets per E‐Mail informiert werden.
