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:

1. 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.
2. 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.
3. 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 UML 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!

 

 

Es ist ganz interessant, dass viele Leute auch seit Jahren den Unterscheid zwischen einem Geschäftsvorfall und Geschäftsprozess nicht kennen bzw. anhand der Namensgleichheit (Ähnlichkeit) nie Gedanken darüber gemacht haben, dass da ein gravierender Unterscheid besteht. Das kann man den Leuten sogar nicht verübeln, da die UML selbst keine enge Definition eines Use Cases kennt.

 

Dieser Artikel klärt das Ganze mal auf.

Am besten verstehen kann man das Ganze, wenn man sich erst mal eine Standard-Definition für einen Use Case ansieht. Wobei man hier schon auf ein Begriffsproblem stößt: Use Case und Anwendungsfall, sowie Geschäftsvorfall ist das gleiche, Geschäftsprozeß ist was anderes.

Wieso ist eine Definition eines Use Case so schwierig?

Das liegt daran, dass die UML selbst eine Notation ist. Deswegen ist die Definition im UML Standard auch sehr grob. Die UML ist ja auch keine Vorgehensweise. Erst eine Vorgehensweise definiert Elemente detailliert. Sieht man sich die Definition in der UML an:

„Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system, that is, what a system is supposed to do.“ siehe UML Superstructure

So kann man mit dem Use Case jede Art von System modellieren. Die Vorgehensweisen, die UML nutzen, waren da detaillierter und schränken das Ganze ein.

Deshalb ist es meiner Meinung nach sehr wichtig erst mal eine saubere Use Case Definition zu haben. Sonst passieren merkwürdige Dinge bei der Use Case Modellierung. Da modellieren die einen Partysysteme mit Cocktail mixen als Use Case, die anderen modellieren Gartensysteme mit Blumen gießen als Use Case. Das eigentliche Ziel sind aber doch EDV Systeme. Warum also diese Definition nicht auf ein vernünftiges Maß reduzieren bzw. bringen? Hier eine praktikable Definition für einen Use Case, die gleichzeitig eine Abgrenzung zum Geschäftsprozess liefert.

Definition für eine Use Case/Anwendungsfall/ Geschäftsvorfall an (Ich verwende ab jetzt Use Case, die anderen Begriffe passen aber auch).

Definition Use Case:

„Ein Use Case ist ein software-gestützter Ablauf, der nach relativ kurzer Zeit ein Ergebnis für einen primären Akteur erzeugt.“

Diese Definition hat sich 1000fach bewährt. Man kann allerdings vielleicht nur etwas damit anfangen, wenn man ein Beispiel dazu nutzt. Das Standard-Bespiel der Weltliteratur ist schon seit über 25 Jahren der Use Case: Geld abheben am Geldautomat.

Ein klassischer Use Case. Man macht kurz was, Karte einschieben etc. und man erhält nach kurzer Zeit das Geld (Ergebnis).

Dazu kann man sich beliebige Bespiele überlegen bzw. im Internet finden. Anmelden auf einer Webseite, Personedaten ändern, etwas Bestellen, im Internetbanking überweisen, Kontostand abfragen, Umsätze einsehen etc..

Übrigens gabs tatsächlich bei der Sparkasse Geldautomaten auf denen neben der Abbruch Taste „Geschäftsvorfall abbrechen“ stand.

Ist der Ablauf ein Use Case?

Als Prüfung gilt:

• Ist der Ablauf Computer (Software) gestützt?
• Ist der Ablauf kurz (vertretbare Wartezeit)
• Erzeugt er ein Ergebnis für den primären Akteur?
• Findet kein Akteurwechsel statt?

Sind diese Fragen mit Ja zu beantworten, ist die Wahrscheinlichkeit sehr hoch, dass es sich um einen Use Case handelt.

So weit, so gut, aber was passiert jetzt bei der KFZ Zulassung oder besser aufgedrückt beim Ablauf „Zulassen eines PKWs“.

Jeder, der schon mal ein Auto zugelassen hat, weiß, dass das schon etwas länger dauern kann. Ferner sind verschiedene Personen (Akteure) beteiligt Außerdem gibt es manuelle Tätigkeiten, wie das Kleben der Plaketten und das Anschrauben der Schilder. Es gibt sogar maschinelle Tätigkeiten, wie das Prägen der Schilder.

Man sieht recht schnell, dass die Use Case Definition hier nicht passt. Somit kann man prüfen, ob eher ein Geschäftsprozess vorliegt.

Ist der Ablauf ein Geschäftsprozess?

Als Prüfung gilt:

• Wechselt der Akteur?
• Gibt es Wartezeiten im Ablauf?
• Gibt es im Ablauf manuelle Tätigkeiten?
• Gibt es im Ablauf maschinelle Tätigkeiten?

Sind diese Fragen mit Ja zu beantworten, ist die Wahrscheinlichkeit sehr hoch, dass es sich um einen Geschäftsprozess handelt.

Wieso ist nur die Wahrscheinlichkeit hoch?

In beiden Fällen habe ich geschrieben, dass die Wahrscheinlichkeit hoch ist, wenn man die jeweiligen Fragen mit Ja beantwortet, es sich um einen Use Case bzw. einen Geschäftsprozess handelt.

Es gibt keine ganz klare Grenze. Meist allerdings eher bei den Geschäftsprozessen. Es kann sein, dass es sich, obwohl keine manuellen und oder maschinellen Tätigkeiten im Ablauf vorhanden sind, es sich trotzdem um einen Geschäftsprozess handelt.

Ferner waren bestimmte Abläufe, die früher ein Geschäftsprozess waren und heute ein Use Case bzw. Anwendungsfall ist. Bespiel: Das Anlegen eines Girokontos. Früher musste man zur Bank, einen Antrag ausfüllen, dann wurde der bearbeitet etc., also ein klassischer Geschäftsprozess. Heute kann man ein Girokonto innerhalb kurzer Zeit samt allen Prüfungen übers Internet anlegen und sofort verwenden, somit heute ein Use Case.

Der Zusammenhang zwischen Geschäftsprozess und Use Case

Wenn die Abgrenzung nun grob klar ist, stellt sich die Frage, ob es einen Zusammenhang zwischen Use Case und Geschäftsprozess gibt.

Den gibt es natürlich. Im Geschäftsprozess „KFZ zulassen“ gibt es einen einzelnen Schritt (Aktivität), der das Bezahlen der Zulassung darstellen wird. Im Geschäftsprozess-Modell interessiert mich aber nur, das ein Bezahlbetrag in die Aktivität hinein geht und eine Quittung hinausgeht. Ferner noch die Art, wie ich bezahlen will, z.B. Kreditkarte oder EC-Karte.

Das würde völlig ausreichen, um den Geschäftsprozess zu verstehen. Aus diesem Schritt wird dann ein Use Case, den ich dann im Use Case Modell weiter detailliert herunterbrechen kann.

Gegenüberstellung

Geschäftsprozess	Geschäftsvorfall/Use Case
Kompletter Geschäftsmäßiger Ablauf z.B. in der KFZ Zulassung	Abschnitt eines Geschäfts­prozesses oder eigenständig z.B. Bezahlen Zulassung, Geld abheben am Geldautomat
Akteurwechsel	Kein Akteurwechsel (primärer Akteur bleibt gleich)
Manuelle Tätigkeiten möglich	Keine Manuellen Tätigkeiten
Maschinelle Tätigkeiten möglich	Keine Maschinellen Tätigkeiten
Erzeugt ein geschäftsmäßiges Ergebnis	Erzeugt ein (Teil) Ergebnis, das weiter verwendet werden kann, entweder direkt oder als Ergebnis eines Schritts im Geschäftsprozeß

Zusammenfassung:

Sie sehen, es gibt schon einen gravierenden Unterschied zwischen Geschäftsprozess und Use Case. Ferner werden normalerweise Geschäftsprozesse und Use Cases mit unterschiedlichen Notationen modelliert. So gibt es für die Use Cases die UML, während es für die Geschäftsprozesse die BPMN gibt.

Allerdings gibt es auch die Möglichkeit Geschäftsprozesse mit UML Use Cases zu modellieren (Später mehr dazu).