Im ersten Teil haben Sie erfahren, wie Sie eine eindeutige und vollständige Definition einer Software erstellen. Sie legen damit fest, was das Produkt können soll und beschreiben, was der Auftraggeber damit erreichen möchte, welche Einflussfaktoren und Rahmenbedingungen gelten und wer die Stakeholder sind. Dieser zweite Teil zeigt, wie es Ihnen auch als Nicht-ITler gelingt, sogenannte Use Cases bzw. Anwendungsfälle zu erstellen, mit denen Sie den Funktionsumfang eines Systems aus Anwenderperspektive konkreter erfassen.

Beim Erstellen der Use Cases stehen vor allem die zukünftigen Nutzer im Mittelpunkt: Was erwarten diese vom System, welche Aufgaben möchten sie erledigen und wie gehen sie dabei vor? Für jede Nutzerrolle, die im Rahmen der Produktdefinition bestimmt wurde, muss der Projektleiter die zugehörigen Aktivitäten ermitteln – in der Regel gehören dazu die Rollen "Kunde", "Einsteller" (im Beispielprojekt „Jingleshop“ aus Teil 1 sind das die Komponisten) und "Nutzer der kaufmännischen und organisatorischen Verwaltungsfunktionen" (z.B. Buchhaltung, Produktpflege). Es kann hilfreich sein, sich den gesamten Ablauf ohne das System zu vergegenwärtigen: Wie würde z.B. ein Verkauf in einem Ladengeschäft aussehen, welche Personen wären im Gesamtablauf beteiligt?

Use Cases und User Stories

Use Cases sind nicht mit den User Stories im agilen Entwicklungsprozess zu verwechseln, haben aber Berührungspunkte. Denn aus den Use Cases können meist mehrere User Stories (Anforderungen) abgeleitet werden, sofern Auftraggeber und Projekt sich darauf geeinigt haben, auf Basis einer solchen Spezifikation zu arbeiten. Weitere Erläuterungen dazu enthalten die Artikel "Agile Softwareentwicklung mit Scrum und User Stories" (Projekt Magazin 2/2010) sowie "So vermeiden Sie Stolpersteine bei User Stories" (Projekt Magazin 17/2012).

Eine Liste mit Nutzeraktivitäten erstellen

Es ist sinnvoll, zunächst eine formlose Liste von Aktivitäten für jede Nutzerrolle zu erstellen. Handelt es sich bei den Nutzern um "Normalverbraucher", ist es von Vorteil, deren Blickwinkel einzunehmen und sich das fertige System vorzustellen. Welche Aufgaben möchte dieser mit Hilfe des Systems erledigen? Sind spezielle Branchenkenntnisse gefragt, ist der Business Analyst des Unternehmens ein passender Ansprechpartner.

Use Cases werden im Format <Rolle> <Aktivität> <Objekt> beschrieben. Beispiele: "Kunde registriert sich am System", "Kunde sucht Produkt", "Kunde kauft Produkt".

Mit einer systematischen Herangehensweise kann der Projektleiter schnell feststellen, ob die Liste vollständig ist. Dazu gehört erstens die Überprüfung auf komplementäre Aktivitäten: Gibt es z.B. "Nutzer meldet sich am System an", gehört auch "Nutzer meldet sich vom System ab" dazu. Eine zweite Vollständigkeitsprüfung sollte die Vorgänge Erstellen, Lesen, Ändern und Löschen umfassen, die im Englischen mit CRUD bezeichnet werden (Create, Read, Update, Delete). Diese lassen sich unter anderem auf Produkte (im Beispiel: Jingles) anwenden. Drittens gibt es Prozessfunktionen, die sich aus der Natur des Verkaufs ergeben: "Kunde kauft Produkt", "Kunde bezahlt Produkt", "Kunde gibt Produkt zurück" usw.

Es entsteht zunächst ein Entwurf, in dem für jede Nutzerrolle eine Sammlung von Aktivitäten beschrieben ist. Ob dies in Textform oder mit Hilfe einer Mindmap geschieht, bleibt dem Projektleiter überlassen. Der Aufwand bewegt sich im Bereich von mehreren Stunden, bei sehr komplexen Systemen ggf. von mehreren Tagen.

Beispiel Jingleshop: Use-Case-Liste

Oft wird versäumt, die Nutzerperspektive einzunehmen. Dies führt zu Use Cases, bei denen die Information fehlt, woraus die Aktion besteht und wer sie ausführt – wie z.B. bei der Formulierung "Merkzettel anlegen". Dieser kann präziser mit Hilfe von zwei Use Cases ausgedrückt werden: "Kunde fügt Artikel dem Merkzettel hinzu" und "Kunde löscht Artikel vom Merkzettel".

In jeden Fall ist es hilfreich, sich ähnliche Systeme genauer anzusehen, im Beispiel des Jingleshops z.B. einen Onlineshop für CDs. Im Zweifelsfall hilft ein potenzieller Nutzer weiter: Im Unternehmen der designierte Key User, ein Mitglied des Testteams, der Business Analyst oder ein Kundenbetreuer, je nachdem, für welchen Nutzerkreis das System entwickelt wird. Handelt es sich um das Nachfolgeprodukt eines bestehenden Systems, ist es sehr aufschlussreich, einen Nutzer einen oder zwei Tage bei seiner Arbeit mit dem abzulösenden System zu beobachten. Ein idealer Key User wäre im Beispiel des Jingleshops ein Mitarbeiter, der Erfahrung in der Beschaffung von Aufzugsmusik oder Warteschleifenjingles hat oder sich zumindest mit Onlineshops gut auskennt.

Schnittstellen zu angrenzenden Systemen berücksichtigen

Nicht nur die Nutzer, sondern auch die Schnittstellen zu angrenzenden Systemen sind Bestandteil der Use-Case-Modellierung. Mit diesen Use Cases ergänzt der Projektleiter die Liste entsprechend. Beispiel: "Abrechnungssystem übernimmt die Bestellung für die Rechnungserstellung".

Use Cases grafisch darstellen