Verbindung von Geschäftsprozessen mit Softwareanforderungen: Ein Visual-Paradigm-Fallstudie zur Übergangsphase von BPMN zu Use-Case-Modellen

Einführung

In der heutigen rasch sich entwickelnden digitalen Landschaft stehen Organisationen vor einer anhaltenden Herausforderung: sicherzustellen, dass Entwicklungsarbeiten im Bereich Software eng mit den tatsächlichen Geschäftsabläufen verknüpft bleiben. Zu oft erfolgt die Anforderungserhebung getrennt von der Modellierung von Geschäftsprozessen, was dazu führt, dass Systeme nicht in der Lage sind, reale Arbeitsabläufe zu berücksichtigen oder den Endnutzern den erwarteten Nutzen zu bieten. Diese Fallstudie untersucht eine bewährte Methode, diese Lücke zu schließen, indem von BPMN-Diagrammen zu UML-Use-Case-Modellen übergegangen wird, wobei die integrierte Modellierumgebung von Visual Paradigm genutzt wird.

Anhand eines praktischen Beispiels mit einem Unternehmen für die Lieferung von destilliertem Wasser zeigen wir, wie Business Analysten und Systemdesigner gemeinsam sinnvolle Softwareanforderungen direkt aus validierten Geschäftsprozessen ableiten können. Der Ansatz nutzt die Model-Transitor-Funktion von Visual Paradigm, um Rückverfolgbarkeitsverbindungen zwischen Geschäftsaktivitäten und System-Use-Cases herzustellen, wodurch sichergestellt wird, dass jede Softwarefunktion einem dokumentierten Geschäftsziel dient. Unabhängig davon, ob Sie als Business Analyst Anforderungen effektiver kommunizieren oder als Systemarchitekt Lösungen entwickeln möchten, die wirklich den operativen Anforderungen entsprechen, liefert diese Fallstudie praktische Erkenntnisse zur Ausrichtung der Modellierung von Geschäftsprozessen an die Softwareanforderungsingenieurwissenschaft.

Verständnis der Grundlage: BPMN und Use-Case-Diagramme

Was sind BPMN und BPD?

BPMN bietet Business Analysten eine Reihe grafischer Notationen zur Modellierung von Geschäftsprozessen. Sie wurde ursprünglich entwickelt von der Business-Process-Management-Initiative (BPMI) und wird derzeit von der Object Management Group (OMG). Eine der Motivationen für die Entwicklung von BPMN ist es, eine gemeinsame grafische Sprache für Personen in unterschiedlichen Rollen, aus verschiedenen Ländern und/oder mit unterschiedlichen Muttersprachen zu schaffen, damit sie denselben Geschäftsprozess ohne Barrieren verstehen können.

BPD, Abkürzung für Geschäftsprozess-Diagramm, ist die Darstellung eines Geschäftsprozesses mithilfe von BPMN. Es handelt sich um ein flussdiagrammähnliches Diagramm, das den Ablauf des Prozesses, die beteiligten Akteure und den Nachrichtenaustausch zwischen ihnen darstellt. Business Analysten zeichnen BPD(s), um darzustellen, wie verschiedene Akteure zusammenarbeiten, um ein Geschäftsziel zu erreichen. Nach der Validierung des fertigen Geschäftsmodells gegenüber den Endnutzern kann ein Systemanalyst dann mit der Planung des Systems beginnen.

Im Folgenden sehen Sie ein einfaches BPD eines Registrierungsprozesses für eine Organisation. Es umfasst die meisten typischen Modellierungsnotationen, die Sie finden werden. Schauen wir uns das an.

Notation	Beschreibung
	Pool – Stellt einen Akteur innerhalb eines Prozesses dar. In BPMN werden sowohl Pools als auch Lanes verwendet, um Akteure darzustellen. Eine Lane ist innerhalb eines Pools enthalten, um eine Unterteilung des übergeordneten Pools zu modellieren.
	Start-Ereignis – Der Beginn eines Prozesses. Trigger können definiert werden, um dem Leser mitzuteilen, in welcher Situation der Prozess ausgelöst wird. Zum Beispiel, wenn eine E-Mail empfangen wird, wenn es Montagmorgen ist oder wenn ein Fehler aufgetreten ist.
	Aufgabe – Eine atomare Aktivität, die bestimmte Akteure (durch Pool/Lane modelliert) ausführen könnten. Aufgaben und andere Flussobjekte werden miteinander verbunden, um einen vollständigen Geschäftsablauf zu bilden.
	Ende-Ereignis – Das Ende eines Prozesses. Ein Ergebnis kann definiert werden, um dem Leser mitzuteilen, was passiert, wenn der Prozess endet. Zum Beispiel, ein Signal auszugeben oder einen Fehler zu erzeugen.

Was ist ein Use-Case-Diagramm?

Die Use-Case-Modellierung bezieht sich auf die Technik, hochrangige Benutzeranforderungen mithilfe eines UML-Use-Case-Diagramms. Ein Use-Case-Modell ist für Software- oder Systemdesigner konzipiert, nicht für Geschäftsleute.

Es gibt drei Hauptelemente in einem Use-Case-Diagramm.

Notation	Beschreibung
	Use-Case – Jedes Use-Case stellt ein Benutzerziel dar, also ein Ziel, das der Benutzer des Systems erreichen möchte. Beachten Sie, dass Use-Cases nur dazu dienen, zu zeigen, was der Benutzer tun möchte, und nicht, was der Entwickler entwickeln muss, obwohl dies in einigen Fällen identisch sein kann. Wenn Sie die beteiligten Funktionen eines Use-Cases dokumentieren oder modellieren möchten, können Sie das Werkzeug für den Ablauf der Ereignisse verwenden oder ein Use-Case mit einem Sequenzdiagramm/Aktivitätsdiagramm. Behalten Sie bitte im Hinterkopf, dass die Use-Case-Modellierung darauf abzielt, das zu modellieren, was der Benutzer erreichen möchte.
	Aktor – Ein Benutzer des Systems. Das Wort „Benutzer“ bezieht sich hier nicht nur auf Menschen. Es kann auch ein System sein, das mit unserem System interagiert, um ein bestimmtes geschäftliches Ziel zu erreichen.
	Kommunikationsverbindung/Assoziation – Verbindet einen Akteur mit einem Use Case, um den Zugriff des Akteurs auf das System anzugeben. Jede Kommunikationsverbindung impliziert eine Folge von Transaktionen zwischen dem Akteur und dem System.

Übergang von der Geschäftsprozessmodellierung zu Systemanforderungen

Die strategische Verbindung

Obwohl BPDs und Use-Case-Diagramme nicht unbedingt aufeinander angewiesen sein müssen, können sie komplementär zueinander stehen. In der Regel entwickeln wir Software, um bestimmte Abläufe von Geschäftsprozessen zu automatisieren oder zu optimieren. Mit einem BPD können Sie verstehen, wie die Beteiligten zusammenarbeiten und wer für was verantwortlich ist, was uns hilft, herauszufinden, welche Funktionen das System unterstützen muss. Diejenigen Systemfunktionen (Workflow oder Geschäftsprozess), die ein Benutzer benötigt, können mit Use Cases modelliert und anschließend vom Team entwickelt werden. Infolgedessen können wir sagen, dass ein BPD Ihnen hilft, Use Cases für ein sich entwickelndes System zu identifizieren.

Visual Paradigm ist ein visuelles Modellierungstool, das den Übergang von der Geschäftsprozessmodellierung zur Use-Case-Modellierung (von Geschäftsanforderungen zu Anwendungsanforderungen) unterstützt, indem es durch die Modell-Transitor-Funktion Spurbarkeitsverbindungen zwischen den beiden Modellen herstellt. Wir benötigen diese Spurbarkeit aus folgenden Gründen:

Wir können sicherstellen, dass das System im realen Einsatz funktioniert, indem wir den Teil des Prozessablaufs untersuchen, den ein Use Case betrifft.
Um Fragen wie „Warum brauchen wir diese (System-)Funktion?“ zu beantworten, indem wir den Teil des Prozesses nachverfolgen, aus dem ein Use Case stammt.
Um Fragen wie „Ist eine bestimmte Operation bereits implementiert?“ zu beantworten, indem wir vom BPD zum Use-Case-Diagramm zurückverfolgen.

Wichtige Unterschiede: BPD im Vergleich zu Use-Case-Diagramm

Einige Menschen könnten meinen, dass ein Use-Case-Diagramm einem BPD ähnlich sei, doch sie unterscheiden sich deutlich in Notation und Zweck. Denken Sie daran, dass BPMN für Geschäftsleute konzipiert ist, während ein Use-Case-Diagramm für Systemanalysten oder Systementwickler gedacht ist. Sie dienen unterschiedlichen Zwecken und betrachten ein Geschäft aus zwei unterschiedlichen Perspektiven. Deshalb fasste ich im vorherigen Abschnitt die Beziehung zwischen einem BPD und einem Use-Case-Diagramm zusammen mit der Aussage: „Ein BPD hilft Ihnen, Use Cases zu identifizieren.“ Ein BPD kann Ihnen lediglich Hinweise geben, wenn Sie Use Cases identifizieren. Es gibt keine Regel, die besagt, dass jede Aufgabe, die in einem BPD existiert, einem Use Case entspricht. Allerdings können wir einen Geschäftsprozess durch einen Use Case erweitern, um die Automatisierung einer Funktion durch das Zielsystem zu ermöglichen.

Fallstudie: Die True Aqua gereinigtes-Wasser-Gesellschaft

Geschäftscontext und Prozessbeschreibung

Die True Aqua gereinigtes-Wasser-Gesellschaft ist ein junges Unternehmen für gereinigtes Wasser in der Stadt. Sie verkaufen gereinigtes Wasser für gewerbliche und private Zwecke. Im Folgenden finden Sie eine textuelle Beschreibung ihres Wasserlieferungsprozesses.

Um gereinigtes Wasser zu bestellen, rufen Kunden entweder die Bestellhotline an oder senden uns eine E-Mail. Derzeit stammen 90 % der Bestellungen aus Telefonanrufen, während 10 % per E-Mail platziert werden. Der Kundenservice-Mitarbeiter, der die Bestellung erhält, prüft, ob es sich um einen bestehenden Kunden oder einen neuen handelt. Wenn der Kunde noch nie bestellt hat, erstellt der Kundenservice-Mitarbeiter ein Kundenkonto, bevor der Wasserlieferung weitergegangen wird.
Die Lieferung von gereinigtem Wasser erfolgt wöchentlich am Mittwoch. Deshalb leitet der Kundenservice-Mitarbeiter am Mittwochmorgen die Bestellungen an die Logistikabteilung zur Lieferung weiter. Sobald der Leiter der Logistikabteilung die Bestellungen erhalten hat, ordnet er die Lieferung durch Zuweisung von Mitarbeitern zu verschiedenen Bestellungen, Druck und Veröffentlichung des Zeitplans an. Die Mitarbeiter erhalten die Anrufe und liefern das Wasser entsprechend an den Kunden.

Ein Geschäftsprozessmodell wurde auf Basis der Beschreibung erstellt. Jetzt werden Sie gebeten, ein Computersystem zu entwickeln, um den gesamten Prozess zu optimieren. Das Erste, was Sie tun müssen, ist ein Use-Case-Modell zu entwickeln. Unterstützt durch das BPD versuchen Sie, ein Use-Case-Diagramm zu erstellen.

Schritt-für-Schritt-Übergangsprozess

HerunterladenDistilliertes-Wasser-Lieferung.vpp. Sie können diese Datei auch am Ende dieses Tutorials finden.
Öffnen Sie die heruntergeladene .vpp-Datei in Visual Paradigm. Um ein Projekt zu öffnen, wählen SieProjekt > Öffnenaus der Anwendungstoolleiste.
Öffnen Sie das BPDProzess zur Bestellung von gereinigtem Wasser. Studieren Sie den Prozessablauf sorgfältig.
Der Prozess beginnt, wenn ein Kunde eine Bestellung aufgibt. Hier können wir einen Use Case betrachten – Bestellung aufgeben. Der Use Case wird helfen, den Prozess zu automatisieren, indem er eine Schnittstelle für den Kunden bereitstellt, um eine Bestellung ohne die Unterstützung eines Kundenservice-Mitarbeiters aufzugeben, die Identität des Kunden zu überprüfen und ein Konto zu erstellen, falls der Kunde noch nicht existiert. Klicken Sie mit der rechten Maustaste aufBestellung aufgeben und wählen Sie Verwandte Elemente > In neuen Use Case überführen… aus dem Kontextmenü.
Dies ruft das Fenster Modell-Element überführen auf, in dem Sie das Modell auswählen können, in dem der Use Case und der Akteur platziert werden sollen, sowie deren Umbenennung vornehmen können. In diesem Fall sind wir mit den Namen des Use Cases und des Akteurs zufrieden. Lassen Sie sie unverändert. Klicken Sie auf OK.

Dies bildet ein neues Use Case-Diagramm in UeXceler.
Zurück zum BPD.
Betrachten wir die Aufgabe Kundenkonto erstellen. Im Geschäftsprozess muss der Kundenservice-Mitarbeiter ein Konto für jeden neuen Kunden erstellen. Im neuen System kann dies entweder Teil des Bestellung aufgeben Use Case sein oder ein separater Use Case sein, der manuell vom Kundenservice-Mitarbeiter ausgelöst wird. In einer realen Situation sollten Sie diese Art von Zweifel mit dem Stakeholder klären, da ein falsches Use Case-Modell zur Entwicklung von Funktionen führen würde, die den Erwartungen der Benutzer nicht entsprechen. In diesem Beispiel nehmen wir an, dass der Benutzer möchte, dass die Aufgabe Kundenkonto erstellen vom Kundenservice-Mitarbeiter ausgeführt wird. Lassen Sie uns einen Use Case daraus erstellen. Klicken Sie mit der rechten Maustaste auf Kundenkonto erstellen und wählen Sie Verwandte Elemente > In neuen Use Case überführen… aus dem Kontextmenü.
Nochmals sind wir mit dem Namen des Use Cases und des Akteurs zufrieden. Lassen Sie alles im Fenster Modell-Element überführen unverändert. Klicken Sie auf OK. Das Use Case-Diagramm wird mit einem neuen Use Case und Akteur aktualisiert. Schauen wir uns das an.
Zurück zum BPD. Gehen wir zum Unterverfahren Lieferung organisieren. Der Leiter der Logistikabteilung kann das System nutzen, um die Terminplanung vorzunehmen und die Arbeiter über die Lieferung von Wasser zu informieren. Daher ist dies ebenfalls ein Use Case des Systems. Klicken Sie mit der rechten Maustaste auf das Unterverfahren Lieferung anordnen und wählen Sie Verwandte Elemente > Wechsel zu neuem Use Case… aus dem Popup-Menü.
Aktivieren Sie den Akteur „Manager“ in der Transit-Modell-Element Fenster. Wenn wir den Namen des Akteurs als Manager, ist dies im Use-Case-Modell mehrdeutig, da es im Unternehmen möglicherweise viele Abteilungen mit vielen unterschiedlichen Managern geben kann. Benennen Sie den Akteur daher in Leiter Logistikabteilung.
Klicken Sie auf OK. Das Use-Case-Diagramm wird aktualisiert.
Gehen Sie zurück zum BPD. Die letzte Aufgabe Wasser liefern ist eine Aufgabe, die nur von einem Menschen erledigt werden kann und nichts mit der Interaktion des Systems zu tun hat. Daher müssen wir dafür kein Use Case erstellen.
Angenommen, der Regionalmanager möchte, dass das System eine neue Funktion unterstützt, die einen Bericht erstellen kann, um Statistiken zu Bestellungen anzuzeigen. Diese Funktion kann ihm helfen, die Marketingstrategie zu überprüfen und zu verfeinern. Obwohl diese Funktion im Geschäftsprozessmodell nicht modelliert wurde, können wir sie direkt im Use-Case-Diagramm zeichnen. Öffnen Sie das Use-Case-Diagramm. Zeichnen Sie einen Akteur Regionalmanager. Erstellen Sie einen Use Case Statistischen Bericht generieren daraus mit einer Assoziation dazwischen.
Angenommen, der Kunde möchte dem Kunden erlauben, Rechnungsstellungen einzusehen und Bestellungen zu stornieren. Außerdem möchte der Kunde dem Leiter der Logistikabteilung erlauben, einen Logistikbericht auszudrucken. Zeichnen Sie die Use Cases entsprechend.
Räumen Sie das Diagramm auf.
Die Übergangsbeziehung ermöglicht es Ihnen, das Geschäftsprozessmodell vom Use-Case-Modell (und umgekehrt) nachzuverfolgen. Versuchen wir es. Platzieren Sie den Mauszeiger über dem Bestellung aufgeben Use Case.
Klicken Sie auf die Modell-Übergang Ressource in der rechten unteren Ecke der Form. Wählen Sie Übergang von > Bestellprozess für destilliertes Wasser<.Bestellung aufgeben aus dem Popup-Menü.

Dies öffnet die BPD mit der Aufgabe Bestellung aufgeben ausgewählt.

Fazit

Diese Fallstudie zeigt, dass der Übergang von BPMN-Geschäftsprozessmodellen zu UML-Nutzenfall-Diagrammen nicht lediglich eine technische Übung ist – es ist eine strategische Herangehensweise, um sicherzustellen, dass Softwarelösungen echten geschäftlichen Wert liefern. Durch die Verwendung der Model Transitor-Funktion von Visual Paradigm können Teams eine klare Rückverfolgbarkeit zwischen geschäftlichen Aktivitäten und Systemanforderungen herstellen und so ein gemeinsames Verständnis zwischen Geschäftssachverständigen und Entwicklerteams schaffen.

Das Beispiel der True Aqua Destilliertes-Wasser-Gesellschaft veranschaulicht mehrere entscheidende Prinzipien: Nicht jede geschäftliche Aufgabe erfordert einen entsprechenden Nutzenfall; die Klärung der Stakeholder ist entscheidend, wenn Prozesse in Systemfunktionen übertragen werden; und neue Anforderungen können direkt in Nutzenfallmodelle eingefügt werden, auch wenn sie ursprünglich nicht im Geschäftsprozess enthalten waren. Vor allem ermöglicht die bidirektionale Rückverfolgbarkeit, die durch das Werkzeug bereitgestellt wird, Teams, grundlegende Fragen zur Begründung von Anforderungen und zum Implementierungsstatus während des gesamten Projektzyklus zu beantworten.

Organisationen, die diese Methodik übernehmen, können eine reduzierte Mehrdeutigkeit von Anforderungen, eine verbesserte Ausrichtung der Stakeholder und Software-Systeme erwarten, die die operativen Realitäten genauer widerspiegeln. Da Geschäftsprozesse weiterentwickelt werden, gewährleistet die Aufrechterhaltung dieser Rückverfolgbarkeit, dass Systemverbesserungen auf validierten geschäftlichen Bedürfnissen basieren und nicht auf spekulativen Feature-Anfragen. Die Integration von künstlicher Intelligenz in moderne Modellierungswerkzeuge beschleunigt diesen Übergang weiterhin und ermöglicht es Teams, sich auf strategische Analysen zu konzentrieren, anstatt manuelle Diagrammarbeiten auszuführen.

Referenzen

Wie KI-gestützte NLP die Text-zu-BPMN-Generierung für die Unternehmensprozessmodellierung revolutioniert: Erörtert, wie die natürliche Sprachverarbeitung textbasierte Geschäftsbeschreibungen in konforme BPMN-Modelle für die Dokumentation unternehmensweiter Workflows umwandelt.
Beherrschen der Geschäftsprozessmodellierung mit BPMN 2.0 mit KI-gestützten Werkzeugen von Visual Paradigm: Umfassende Übersicht über KI-verbesserte BPMN-Modellierungsfunktionen zur Erstellung ausführbarer Geschäftsprozessspezifikationen.
Funktion: Nutzenfall zu Aktivitätsdiagramm: Erläutert den automatisierten Workflow zur Erweiterung von hochleveligen Nutzenfällen zu detaillierten Aktivitätsdiagrammen zur Planung der Implementierung.
Aktualisierung des KI-BPMN-Geschäftsprozess-Diagramm-Generators: Versionshinweise zu erweiterten KI-Funktionen zur Umwandlung narrativer Prozessbeschreibungen in strukturierte BPMN-Diagramme.
Funktion: BPMN-Diagramm und Werkzeuge: Offizielle Dokumentation der BPMN 2.0-Modellierungswerkzeuge, Notationssupport und Zusammenarbeitsfunktionen innerhalb von Visual Paradigm.
Demo zur konversationellen Prozessreengineering: Video-Demonstration zur Verwendung von KI-Chatbot-Befehlen zur dynamischen Änderung von BPMN-Diagrammen über natürliche Spracheingaben.
Veröffentlichung des KI-gestützten Werkzeugs zur Verbesserung von Geschäftsprozessen: Ankündigung intelligenter Analysefunktionen für Workflows, die Optimierungsmöglichkeiten auf Basis von Prozessmetriken vorschlagen.
Funktion: BPMN-Diagramm und Werkzeuge: Referenzhandbuch für erweiterte BPMN-Funktionen, einschließlich der Unterverfahrensdiskussion und der Generierung ausführbarer Modelle.
KI-gestütztes Werkzeug zur Verbesserung von Nutzenfall-Diagrammen: Webbasiertes KI-Werkzeug zur automatischen Verbesserung grundlegender Nutzenfallmodelle durch korrekte include/extend-Beziehungen und Ausnahmehandhabung.
Umfassender Leitfaden zur Nutzenfallmodellierung mit dem KI-Ökosystem von Visual Paradigm: Drittanbieter-Analyse von KI-unterstützten Techniken zur Anforderungserhebung und Nutzenfall-Spezifikation.
Von Geschäftsprozessen zu Anwendungsfällen – Tutorial (PDF): Herunterladbarer Schritt-für-Schritt-Leitfaden zur Umstellung von BPMN-Modellen auf UML-Anwendungsfalldiagramme mit Nachverfolgbarkeit.
Demo zur automatischen Erzeugung von Grenzen: Video-Tutorial, das die künstliche Intelligenz-gestützte Erstellung von Systemgrenzen, Akteuren und zentralen Anwendungsfällen aus Projektumfangsangaben zeigt.
Demo zur intelligenten Verbesserung von Beziehungen: Demonstration der KI-Analyse, die Beziehungen zwischen Anwendungsfällen erkennt und geeignete include/extend-Beziehungen vorschlägt.
Feature des KI-gestützten Werkzeugs zur Verbesserung von Anwendungsfalldiagrammen: Produktseite mit detaillierten Informationen zur automatischen Analyse und Verbesserung von Anwendungsfallbeziehungen.
Demo zur Generierung nachgeschalteter Workflows: Video, das die automatische Generierung von Aktivitäts- und Ablaufdiagrammen aus validierten Anwendungsfallspezifikationen zeigt.
Visual Paradigm auf TheirStack: Technologietyp und Einblicke in die Nutzung von Visual Paradigm-Modellierungstools in Unternehmensumgebungen.
Feature des KI-gestützten Berichtsgenerators für Anwendungsfalldiagramme: Werkzeug zur Umwandlung von PlantUML-Skripten und Anwendungsfallmodellen in professionelle Dokumentation für Stakeholder.
Dokumentation zum Erweiterungspunkt für Ablauf der Ereignisse: Technische Referenz zur Dokumentation detaillierter Anwendungsfallszenarien mit Voraussetzungen, Nachbedingungen und alternativen Abläufen.
Veröffentlichung des KI-gestützten Modellierungsstudioprodukts für Anwendungsfälle: Ankündigung der Veröffentlichung integrierter KI-Funktionen für die Anwendungsfalldiagramm-Modellierung, einschließlich der Analyse von Anforderungen in natürlicher Sprache.