Wie beschreibt man eigentlich Anforderungen? Einige sagen, dass eine Satzschablone (eine Anforderung pro Satz) sinnvoll ist. Wie passt aber eine komplexe Anforderung in einen Satz? Und was ist mit Use Cases, mit denen kann man doch auch Anforderungen beschreiben? Und was ist überhaupt ein Use Case? Und wie passt das zum Begriff Geschäftsprozess?
Fragen über Fragen.
Dieser Artikel soll ein bisschen Licht ins Dunkel bringen und einen praktikablen Ansatz aufzeigen.
Definition Anforderung
Leider kann man mit den gängigen Definitionen über eine Anforderung nicht viel anfangen, da sie alle zu grob sind und in der Praxis zu wenig aussagen. Nimmt man z.B. eine gängige Definition aus IEEE bzw. von IREB, die sich durchaus etabliert haben, stellt man fest, dass das alles und nichts ist.
Definition nach IEEE (Auszug)
Eine Anforderung ist eine Bedingung oder eine Fähigkeit, die ein Benutzer benötigt, um ein Problem zu lösen oder um ein Ziel zu erreichen.
Definition nach IREB aus CPRE Glossar
Eine Anforderung ist:
- Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
- Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.
- Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäß 1. oder 2.
Damit wäre eine Anforderung etwas Einfaches, wie Anforderung eine UserId zu verwenden, die aus 8 Zeichen etc. bestehen soll, oder was komlexeres, wie Geld abheben oder die Zulassung eines KFZs auf dem Straßenverkehrsamt. Alle drei Beispiele sind per Definition Anforderungen.
Anhand der Beispiele kann man erkennen, dass man Anforderung sehr wohl unterscheiden muss. Einen komplexen Ablauf kann man nicht mit einer einfachen Beschreibung wie z.B. mit einer Satz Schablone beschreiben. Da braucht es schon eine geeignete Beschreibungssprache, wie zum Beispiel die UMLUML steht für Unified Modelling Language More mit den Use Cases oder auch die BPMN.
Wie geht man vor?
Eine praktische Vorgehensweise wäre es, sich die Anforderung anzusehen und als erstes fest zu stellen, ob sie einen Ablauf beinhaltet oder nicht. Beinhaltet sie keinen Ablauf, wie z.B. die Anforderung an eine UserID, kann man diese mit gewohnten Standard-Mitteln (Text, textuell) beschreiben. Beinhaltet sie einen einfachen Ablauf, der sich vielleicht mit ein oder zwei einfachen Sätzen beschreiben lässt, dann kann man eine solche Anforderung sicherlich auch mit einer Satzschablone beschreiben.
Beispiel: Das herein- und hinauszoomen in einem PDF Reader. Das ist sicher ein ganz einfacher Ablauf, der mit einer Satzschablone einfach zu beschreiben wäre.
„Das System muss dem Benutzer die Möglichkeit bieten, rein- und raus zu zoomen.“
Hierfür ist diese Schablone sicherlich gut geeignet.
Aber was ist, wenn der Ablauf komplizierter ist?
Dann wäre der nächste Test, ob es ein Geschäftsprozess oder einen Geschäftsvorfall ist. Falls es ein Geschäftsvorfall ist, kann man den mit der gängigen Use Case Modellierung umsetzen. Ist es ein Geschäftsprozess kann man diesen mit der BPMN Modellierung umsetzen. Die folgende Grafik zeigt das Ganze im Überblick:
Somit kann man sehr praktikabel jede einzelne Anforderung überprüfen und darüber entscheiden, wie man sie tatsächlich modelliert.
Der praktische Ansatz:
Einfache Anforderung ohne Ablauf oder mit einem sehr einfachen Ablauf kann man mit natürlich-sprachlichen Mitteln (Prosa, Satzschablone) sehr gut dokumentieren. Ist die Anforderung ein Ablauf mit mehren Schritten und der Ablauf ist ein Use Case, nutzt man am besten die Use Case Modellierung. Ist es ein Geschäftsprozess eignet sich die Geschäftsprozeß-Modellierung mit BPMN am besten.
Beispiele und Gegenbeispiele
Die Anforderung in einem online Shop sich den Warenkorb anzeigen zu lassen, würden viele als Use Case modellieren, da die Katalogsuche, die Bestellung der Ware etc. alles Use Cases sind. Das könnte man so machen, aber mit dem Satz: „Falls der Benutzer angemeldet ist, muss das System dem Benutzer die Möglichkeit bieten, sich den Warenkorb anzeigen zu lassen“.
Damit ist alles gesagt! Wozu dafür einen Use Case anlegen, eine Use Case Schablone ausfüllen oder gar ein Aktivitäts-Diagramm zu erzeugen? Denn was würde in der Ablaufbeschreibung des Use Cases drin stehen:
1. Kunde wählt Warenkorb anzeigen beim online Shop
2. Online Shop zeigt Warenkorb dem Kunden.
Das war es! Dafür einen Use Case anlegen, macht wenig Sinn!
Anders herum wäre aber das Ausleihen eines Buches viel sinnvoller als Use Case zu modellieren, als mit einer Satzschablone bzw. natürlich zu beschreiben.
Wenn man den kompletten Ablauf sieht, dann hat man da bestimmt mehr als 5 Bedingungen und viele Ausnahmen. Selbst wenn man die Satzschablone verwendet und einen Satz formuliert wie: „Falls der der Benutzer angemeldet ist, muss das System den Benutzer die Möglichkeit bieten ein Buch auszuleihen“
Was ist mit Randbedingungen und Ausnahmen? Da wäre die Use Case Modellierung mit eine Schablone oder einem Aktivitäts-Diagramm sinnvoller.
Zusammenfassung
Nutzen Sie die gesamten Möglichkeiten, die im Requirements-Engineering existieren und nicht den Golden Hammer! Um eine sinnvolle Beschreibung haben zu wollen, muss man das richtige Mittel einsetzen!