Requirements Engineering in agilen Projekten ist kein Widerspruch

Klassische Anforderungen agil erfasst

Manfred Steyer

Agile Methoden versuchen den Erfolg von Softwareprojekten durch eine schlanke und flexible Vorgehensweise sicherzustellen. Dies scheint auf den ersten Blick im Wiederspruch zum klassischen Requirements Engineering, das zahlreiche Techniken für den Umgang mit Anforderungen vorsieht, zu stehen. Dieser Artikel zeigt, wie sich diese Sichtweisen vereinen lassen.

Um zu zeigen, wie sich ein agiles Vorgehen mit Requirements Engineering verbinden lässt, werden zunächst zwei agile Muster [1], die zur Handhabung von Anforderungen verwendet werden, vorgestellt: Use Cases und User Stories. Anschließend werden diese beiden Muster mit den Disziplinen des Requirements Engineerings verglichen.

Use Cases

Use Cases sind ein bewährtes Mittel zur Analyse und Erfassung von funktionalen Anforderungen und stammen eigentlich aus der „pre-agile-Area“. Ein Use Case repräsentiert einen Dienst, den ein System bestimmten Benutzergruppen, den so genannten Akteuren, anbietet. Dazu beschreiben sie die Interaktion zwischen Akteuren und dem sich in Planung befindlichen System. Eine beliebte Technik zur Beschreibung dieser Interaktionen stellen Szenarien dar [2]. Dazu wird zunächst das so genannte „Happy-Day-Szenario“ beschrieben. Dabei handelt es sich um ein Szenario, das die erfolgreiche Abarbeitung eines Use Cases beschreibt. Der Kasten: „Beispiel 1: Happy-Day-Szenarios“ veranschaulicht dies. Nach der Beschreibung des Happy-Day-Szenarios besteht die Aufgabe darin, mögliche Fälle, in denen vom Happy-Day-Szenario abgewichen wird, zu finden. Diese so genannten Alternativen werden anschließend separat beschrieben. Der Kasten: „Beispiel 2: Mögliche Alternativen“ demonstriert zwei Alternativen für das soeben betrachtete Happy-Day-Szenario. Der erste Satz einer Alternative soll deren Auslöser darstellen. Durch die Ausgliederung von Alternativen in separate Blöcke werden „Wenn-Dann-Sonst-Konstrukte“, die zwar für Entwickler verständlich, jedoch für Kunden häufig verwirrend sind, vermieden. Darüber hinaus werden die unterschiedlichen Abläufe übersichtlich dargestellt und können somit einfach gewartet sowie im Zuge des Testens wiederverwendet werden.

Beispiel 1: Happy-Day-Szenarios

1. Der Manager öffnet eine Anforderung

2. Das System zeigt den Namen, Telefonnummer und E-Mail-Adresse des Mitarbeiters sowie die angeforderten Produkte

3. Der Manager genehmigt die Anforderung

4. Das System benachrichtigt den Mitarbeiter

5. Das System erstellt eine Bestellung und versendet diese an den Lieferanten via E-Mail

Beispiel 2: Mögliche Alternativen

2a. Die Bestellung würde das vorhandene Budget überschreiten

2a.1 Das System informiert den Manager über das aktuelle Budget sowie über das Ausmaß der Überschreitung.

2a.2 Weiter mit Punkt 2 im Hauptszenario

3a. Der Manager lehnt die Anforderung ab

3a.1 Der Manager erfasst eine Begründung

3a.2 Das System benachrichtigt den Mitarbeiter

3b. Der Manager gibt an, alle vergangenen Anforderungen des Mitarbeiters einsehen zu wollen

3b.1 Siehe Use Case 0815: Vergangene Anforderungen einsehen

3b.2 Weiter mit Punkt 2 im Hauptszenario

Geschrieben von
Manfred Steyer
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.