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.

 

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

Tabelle 1: Auszug aus einer Use-Case-Liste im Beispiel "Jingleshop".
Nutzerrolle Use Case
Kunde ... registriert sich am System
Kunde … hebt die Registrierung auf
Kunde … sucht Produkt
Kunde … zeigt Produkt an

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

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
3 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 8
Kommentare 3

Fortsetzungen des Fachartikels

Teil 1:
Leistungsumfang und Rahmenbedingungen festlegen
Viele Projektleiter müssen im Rahmen Ihrer Tätigkeit Software beauftragen – z.B. weil diese Bestandteil einer Prozessoptimierung ist.
Teil 3:
Anforderungen für die Software-Entwicklung ableiten
Die Merkmale der neuen Software sind festgelegt, der Funktionsumfang ist in Form von Use Cases modelliert.

Alle Kommentare (3)

Hans-Heinz
Maier
Hallo, diese use cases sind natürlich sehr schön und ein guter Ansatz, um von einer normalen Leistungsbeschreibung wegzukommen. Nur darf man eines nicht übersehen: Das geht bei kleinen Projekten, bei denen man alle Funktion gleich überschauen kann, das ist aber selten. Bei mittleren und größeren Projekten muss man doch erstmal klären, was wollen wir denn überhaupt? Was will der Auftraggeber genau? Man hat genug damit zu tun, abzugrenzen, was kommt hinein und was nicht, Beispiel dazu: Wir hatten Monate alleine damit zu tun, zu klären bzw. zu entscheiden, ob ein anderer Bereich das Projektergebnis ebenfalls nutzen will. Zuerst sollte er dabei sein und integrierte sich ins Projekt, kaum kannte er sich aus, verabschiedete er sich und machte wieder sein eigenes Ding. Dann schaffte er es nicht und kam wieder an und musste integriert werden. Da nutzt kein use case, um damit klar zu kommen. mfg Maier

 

Hans-Heinz
Maier
Hallo, ein weiteres Problem ist folgendes: Wenn man zu Projektbeginn schon alles sehr genau mit use cases beschreibt, findet man evtl. keinen mehr, der das unterschreibt, denn jeder sagt. "ob alle das so wollen, kann ich nicht entscheiden". Zudem hat man Probleme bei Änderungen: Wenn an sich früh so genau festlegt und es gibt Änderungen, muss man viel zu viel an Dokumentation nachziehen. Beispiel: In einer größeren Behörde haben wir zu Beginn alles genau beschrieben, zwar nicht mit use case, aber so ähnlich, das waren 1000 Seiten (das Projekt lief 15 Jahre). Dann kam das böse Erwachen, niemand wollte das unterschreiben bzw. freigeben. Es blieb nichts anderes übrig, als alles auf die eigene Kappe zu nehmen, ohne Freigabe. Es ist also besser, erstmal einen RQ-Katalog mit 3 bis 15 Seiten zu erstellen, den kann auch ein Obermanager noch überblicken und absegnen. Danach schaut der nicht mehr hin und man kann in den Details machen -in Grenzen natürlich- was man will bzw. die Abteilungsfürsten können dann ihren Bereich beackern. mfg Maier

 

Michael
Schenkel
Schöner Artikel, gefällt mir gut. Eine Beschreibung von Use Case 2.0 - gerade beim Bezug von Requirements Engineering für Projektleiter - hätte vermutlich noch stärker die Verzahnung von RE und PM ausgedrückt. Unter http://www.microtool.de/wie-funktioniert-use-case-2-0/ gibt es eine kurze Beschreibung ... Viele Grüße und weiterhin schöne Artikel Michael Schenkel