Anforderungen an Softwareprodukte klar definieren

Requirements Engineering für Projektleiter

Teil 2: Mit Use Cases den Funktionsumfang beschreiben
Mit der in Teil 1 erstellten Systemdefinition sind die Merkmale der neuen Software festgelegt. Um konkrete Anforderungen für die Entwickler abzuleiten, muss diese allerdings noch verfeinert werden. Im nächsten Schritt geht es deshalb darum, sogenannte Use Cases zu modellieren, die den Funktionsumfang der Software genauer beschreiben. Wie Ihnen das auch als Nicht-ITler gelingt, zeigen Bettina Zastrow und Elisabeth Wagner in diesem zweiten Teil der dreiteiligen Artikelfolge.

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

Anzeige
Der vollständige Artikel ist für Abonnenten frei zugänglich.
Artikel kaufen (4,50 €)
  • 9 Seiten Praxiswissen
  • PDF-Download
Kostenlos weiterlesen!
  • Diesen Beitrag kostenlos lesen
  • 4 Wochen Online-Zugriff auf alle Artikel, Methoden und das Glossar
Tech Link