Richtlinie: Geschäftsanwendungsfallmodell
Ein Geschäftsanwendungsfallmodell beschreibt, wie das Geschäft von seinen Kunden, Partnern und anderen externen Trägern verwendet wird. Diese Richtlinie ist eine Einführung in die Geschäftsanwendungsfallmodellierung.
Beziehungen
Hauptbeschreibung

Erläuterung

Durch die Modellierung von Geschäftsanwendungsfällen und Akteuren soll in erste Linie beschrieben werden, wie das Geschäft von externen Stellen und insbesondere von seinen Kunden und Partnern verwendet wird. Es können Aufgaben, die sich direkt auf den Kunden oder Partner beziehen, sowie unterstützende oder verwaltungsorientierte Aufgaben dargestellt werden, die nur indirekt mit der externen Partei zu tun haben.

Das Modell beschreibt das Geschäft mit Hilfe von Geschäftsanwendungsfällen, die dem entsprechen, was gemeinhin als "Prozesse" bezeichnet wird.

Im Begleittext beschriebenes Diagramm

Akteure und Anwendungsfälle am Check-in-Schalter.

Kategorien von Geschäftsanwendungsfällen

Wenn Sie sich die Aufgaben in einem Geschäft ansehen, können Sie mindestens drei Kategorien von Arbeit ausmachen, die den drei Kategorien von Geschäftsanwendungsfällen entsprechen:

  • Kern - Hierbei handelt sich um extern orientierte Geschäftsanwendungsfälle, die die Wertschöpfungskette darstellen, z. B. Produkt kaufen.
  • Management - Hierbei handelt es sich um die internen Geschäftsanwendungsfälle, die die Wertschöpfungskette koordinieren, z. B. strategische Planung.
  • Unterstützung - Hierbei handelt es sich um interne Geschäftsanwendungsfälle, die die Wertschöpfungskette unterstützen, z. B. Rohmaterial produzieren.

Wir gehen später auf die Bedeutung und Darstellung der internen Geschäftsanwendungsfälle näher ein.

Gewöhnlich beschreibt ein Geschäftsanwendungsfall vom Typ Management die Beziehungen zwischen dem Vorstandsvorsitzenden und den Personen, die in den Geschäftsanwendungsfällen arbeiten. Er beschreibt auch, wie Geschäftsanwendungsfälle entwickelt und instanziert (gestartet) werden.

Im Begleittext beschriebenes Diagramm

In dieser Abbildung in einem Restaurant sind die Kerngeschäftsanwendungsfälle "Marketing" und "Abendessen servieren", und der unterstützende Geschäftsanwendungsfall ist "Lebensmittel einkaufen".

Beachten Sie, dass ein von Ihnen als Kerngeschäftsanwendungsfall eingestufter Geschäftsanwendungsfall in einem anderen Geschäft durchaus ein unterstützender Geschäftsanwendungsfall sein kann. Die Softwareentwicklung ist in einem Softwareentwicklungsunternehmen beispielsweise ein Kerngeschäftsanwendungsfall, würde aber in einer Bank oder in einer Versicherungsgesellschaft als unterstützender Geschäftsanwendungsfall klassifiziert werden. Viele detaillierte Geschäftsanwendungsfälle, die bei der Modellierung eines Softwareentwicklungsgeschäfts modelliert werden, gehören für eine Bank, die ihre eigene Software entwickelt, nicht zu den vorrangigen Geschäftsanwendungsfällen, nicht einmal zu den unterstützenden Geschäftsanwendungsfällen. Sie können als untergeordnete Anwendungsfälle erscheinen (siehe Konzept: Große Organisationen modellieren). Auf Bankebene würde man nur unterstützende Anwendungsfälle erwarten, die die Strategie und Ziele der Bank widerspiegeln. Einer davon könnte heißen 'Geschäftseinheit für Softwareentwicklung betreiben".

Ein Geschäft hat viele Geschäftsanwendungsfälle

Instanzen mehrerer unterschiedlicher Geschäftsanwendungsfälle sowie mehrere Instanzen eines einzelnen Geschäftsanwendungsfalls werden normalerweise parallel ausgeführt. Es kann eine nahezu unbegrenzte Anzahl von Pfaden geben, denen eine Anwendungsfallinstanz folgen kann. Diese unterschiedlichen Pfade stellen die Optionen dar, die der Anwendungsfallinstanz in der Workflowbeschreibung offen stehen. Eine Anwendungsfallinstanz kann ja nach Ereignissen oder Fakten einen von mehreren möglichen Pfaden verfolgen und dabei von folgenden Faktoren gesteuert werden:

  • Eingabe eines Akteurs
  • einer Geschäftsregel

Bei der Modellierung von Geschäftsanwendungsfällen können Sie davon ausgehen, dass Anwendungsfallinstanzen ohne Konflikte parallel ausgeführt werden können. In diesem Stadium der Geschäftsentwicklung sollten Sie sich darauf konzentrieren, was das Geschäft tun soll. Lösen Sie potenzielle Ressourcenkonflikte später, wenn Sie die Geschäftsanwendungsfallrealisierungen modellieren und dabei versuchen zu verstehen, wie Dinge im Geschäft funktionieren sollten. Sie können diese Probleme auch während der Implementierung der neuen Organisation lösen, z. B. durch Erhöhung der Anzahl von Mitarbeitern, die die kritische Aufgabe ausführen können.

Stehen Geschäftsanwendungsfälle immer mit Geschäftsakteuren in Beziehung?

Jeder Kerngeschäftsanwendungsfall muss eine gerichtete Kommunikationsbeziehung zu oder von einem Geschäftsakteur haben. Diese Regel setzt das Ziel um, dass Geschäfte um die Services herum aufgebaut werden, die die Benutzer fordern. Wenn Ihr Geschäftsanwendungsfallmodell Kerngeschäftsanwendungsfälle hat, die niemand anfordert, sollte dies eine Warnung für Sie sein, dass mit dem Modell etwas nicht stimmt.

Geschäftsanwendungsfälle können in regelmäßigen Abständen ausgelöst oder über einen längeren Zeitraum hinweg ausgeführt werden. Ein Beispiel für den letzteren Fall ist eine Überwachungsfunktion. Selbst die Geschäftsanwendungsfälle haben Geschäftsakteure, die sie einleiten und unterschiedliche Services von ihnen erwarten. Andernfalls wären sie nicht Teil des Geschäfts. Andere Geschäftsanwendungsfälle produzieren Ergebnisse für einen Geschäftsakteur, obwohl sie nicht explizit vom Geschäftsakteur eingeleitet werden. Die Entwicklung eines weit verbreiteten Produkts beispielsweise wird selten von einem identifizierbaren Kunden eingeleitet. Der Bedarf nach einem neuen Produkt ergibt sich vielmehr aus Marktstudien und den kumulierten Anforderungen vieler Benutzer.

Interne Geschäftsanwendungsfälle

Management- und unterstützende Geschäftsanwendungsfälle (die wir zuvor als interne Geschäftsanwendungsfälle beschrieben haben) müssen nicht unbedingt mit einem Geschäftsakteur verbunden sein, obwohl auch sie gewöhnlich eine Art von externem Kontakt haben. Ein Geschäftsanwendungsfall vom Typ Management kann beispielsweise die Geschäftseigentümer oder den Vorstand als Geschäftsakteur haben.

Ein Geschäftsanwendungsfall ohne einen Akteur scheint in Anbetracht der Tatsache, dass ein 'Anwendungsfall' die Interaktion von jemandem bzw. etwas mit dem Geschäft repräsentieren und einen Wert darstellen sollte, etwas sonderbar, aber Sie können diese Klasse von Geschäftsanwendungsfall als (theoretische) Erweiterung von Geschäftsanwendungsfällen betrachten, die Geschäftsakteure haben. Wir erläutern die Verwendung expliziter Erweiterungen auf der Seite Richtlinie: Erweiterungsbeziehung im Geschäftsanwendungsfallmodell, aber hier ist der (erweiterte) Basisgeschäftsanwendungsfall möglicherweise nur konzeptionell und muss deshalb nicht modelliert werden. Die Management- und unterstützenden Geschäftsanwendungsfälle sind in diesem Fall Erweiterungen des konzeptionellen Basisanwendungsfalls, die durch durch Bedingungen ausgelöst werden (und in Geschäftsereignissen resultieren), die sich aus der Führung des Geschäfts ergeben. Diese Denkweise verhindert, dass künstliche Geschäftsakteure eingeführt werden, zwingt Sie aber dazu, darüber nachzudenken, welchen Mehrwert die Management- und unterstützenden Geschäftsanwendungsfälle bringen.

Abstrakte Geschäftsanwendungsfälle benötigen keinen Geschäftsakteur, weil sie nicht eigenständig instanziert (gestartet) werden.

Geschäftsanwendungsfälle müssen Geschäftsziele unterstützen

Geschäftsprozesse sind das Mittel, mit dem das Geschäft Dinge tut. Da eine direkte Übersetzung der Geschäftsstrategie in Aktionen sehr schwierig ist, wird etwas anderes benötigt. Dieses Etwas sind die Geschäftsziele, die sicherstellen, dass Geschäftsprozesse die Geschäftsstrategie umsetzen, indem Aktionen auf allen Ebenen der Organisation in die Richtung des ultimativen Geschäftsziels - der Geschäftsidee - gelenkt werden.

Aus diesem Grund sollte jeder Geschäftsanwendungsfall mindestens ein Geschäftsziel unterstützen. Die Übersetzung der Strategie in Ziele auf verschiedenen Ebenen ergibt konkrete, messbare Zielsetzungen, die von Geschäftsprozessen direkt unterstützt werden können. Durch die Definition von unterstützenden Beziehungen zwischen Zielen und Prozessen wird gewährleistet, dass die Geschäftsprozesse auf die Geschäftsstrategie ausgerichtet sind. Dies hilft auch, die richtige Stufe von Geschäftsanwendungsfällen zu finden, die sich häufig nur schwer bestimmen lässt. Ein Geschäftsanwendungsfall (z. B. Gewinn erwirtschaften) allein, der die strategischen Ziele des Unternehmens direkt unterstützt, wäre zu komplex und ließe sich nur schlecht als Abfolge von Aufgaben modellieren. Für jede einzelne Aufgabe in der Organisation (z. B. Telefonanruf weiterleiten oder Konferenzraum buchen) einen gesonderten Geschäftsanwendungsfall zu modellieren, würde zu zu vielen Geschäftsanwendungsfällen führen und das Verständnis beeinträchtigen. Die Definition der Geschäftsziele, die von einem Geschäftsanwendungsfall unterstützt werden, weist darauf hin, ob der Geschäftsanwendungsfall "zu hoch" oder "zu niedrig" ist.  

Wenn ein Geschäftsanwendungsfall ein oder mehrere Geschäftsziele direkt unterstützt, wird es einfacher, den Wert des Geschäftsanwendungsfalls zu quantifizieren. Der Beitrag, den das Ergebnis des Geschäftsanwendungsfalls in Bezug auf das Ziel darstellt, kann gemessen werden. Die Ausführung des Geschäftsanwendungsfalls kann zur Unterstützung eines objektiven Vergleichs von Nutzen und Kosten überwacht werden.

Das Vorhandensein dieser Beziehungen hilft, Prioritäten für die Geschäftsanwendungsfälle zu vergeben. Geschäftsanwendungsfälle, die viele oder wichtige und risikoreiche Geschäftsziele unterstützen, sind wahrscheinlich als architektonisch relevant einzustufen. Viele Ziele können auch auf eine unnötige Komplexität hinweisen. Wenn ein Geschäftsanwendungsfall viele unterschiedliche Ziele unterstützt, ist das Auftreten von Konflikten geradezu vorhersehbar. In diesen Fällen ist es möglicherweise nicht klar, welche Ziele die höhere Priorität haben sollten, und dies führt zu ineffizienten Aktionen.

Die Kategorie des Geschäftsanwendungsfalls (Kern, unterstützend oder Management) bestimmt nicht direkt die Arten der unterstützten Geschäftsziele. Die Kategorie dient zwar als Richtlinie, aber die Geschäftsstrategie bestimmt letztendlich, welche Geschäftszeile ein bestimmter Geschäftsanwendungsfall unterstützt. Ein Geschäftsanwendungsfall "Produkt vertreiben und verkaufen" kann beispielsweise das Geschäftsziel "Wettbewerbsfähige Preise" für ein Geschäft mit einer aggressiven Wachstumsstrategie unterstützen. Jahre später möchte dasselbe Geschäft unter Umständen seine Investitionen in diese Produkte und Märkte erhöhen, indem es auf Kundenzufriedenheit und Kundenbindung abzielt. Der Geschäftsanwendungsfall "Produkt vertreiben und verkaufen" muss dann unter Umständen das (sehr unterschiedliche) Geschäftsziel "Höhere Qualität" unterstützen. Weitere Informationen zur Modellierung von Geschäftszielen finden Sie auf der Seite Richtlinie: Geschäftsziel.

Stellen Sie sich beispielsweise das große Möbelgeschäft vor, das als Beispiel auf der Seite Richtlinie: Geschäftsziel verwendet wird. Ein Geschäftsanwendungsfallmodell für eine solche Möbelkette könnte wie folgt aussehen:

Diagramm, das ein Geschäftsanwendungsfallmodell für Möbelgeschäfte zeigt

Der Kunde kann Produkte auswählen, sie in dem an die Verkaufsräume angrenzenden Warenlager abholen und dann bezahlen. Mangelhafte Produkte können zurückgegeben werden. "Kundenanforderungen identifizieren" ist der Geschäftsanwendungsfall, der häufig auch als "Marktanalyse" bezeichnet wird. Sobald ein geeignetes Produkt gefunden ist, wird es auf den Markt gebracht, und der Anbieter wird zum Lieferanten. Der Produktvertrieb muss überwacht werden, obwohl darüber diskutiert werden kann, ob dies ein separater Geschäftsanwendungsfall (wie in der Abbildung oben) oder Teil der Marktforschung ist. Wenn wir die beschriebenen Geschäftsanwendungsfälle den auf der Seite Richtlinie: Geschäftsziel beschriebenen Geschäftszielen zuordnen sollte, könnte sich Folgendes ergeben:

Im Begleittext beschriebenes Diagramm

Der Geschäftsanwendungsfall "Geeignetes Produkt finden" unterstützt Geschäftsziele, die ein wenig miteinander in Konflikt stehen. Es muss klar gemacht werden, wie Kompromisse zwischen Preis und Qualität getroffen werden, um sicherzustellen, dass beide Geschäftsziele erfüllt werden. Wenn die Produktqualität anhand der Anzahl (oder eines Prozentsatzes) zurückgegebener mangelhafter Produkte gemessen wird, muss die Mängelursache bestimmt werden, um sie zum Lieferanten zurückverfolgen zu können. Es könnte beispielsweise sein, dass viele ausgelieferte Produkte vom Kunden zurückgegeben werden, weil sie durch das Auslieferungsteam beschädigt wurden. Wenn jedoch nur die Anzahl der Lieferungen gemessen wird, bleibt die Qualität der Lieferungen verborgen.

Der Geschäftsanwendungsfall "Produkt bezahlen" kann "Zahlungsmethode", aber nicht "Niedrige Preise" unterstützen, weil die Preise im (separaten) Geschäftsanwendungsfall "Geeignetes Produkt finden" bestimmt wird.

In einigen Unternehmen unterstützen einige Geschäftsanwendungsfälle keine Geschäftsziele. Dies kann ein Grund sein, z. B. "Umsatz überwachen" mit "Kundenanforderungen identifizieren" zusammenzuführen, weil "Umsatz überwachen" direkt keine Geschäftsziele unterstützt. Eine solche Zusammenführung sollte jedoch nicht zu hastig vorgenommen werden, weil die fehlende Unterstützung von Geschäftszielen auch ein Hinweis darauf sein kann, dass die Geschäftsziele konkreter formuliert werden müssen. Im schlimmsten Fall dient "Umsatz überwachen" als Eingabe für "Kundenanforderungen identifizieren".

Der Geschäftsanwendungsfall "Produkt liefern" unterstützt das Geschäftsziel "Lieferzeit". Kunden sollten nicht zu lange auf die Lieferung der von ihnen gekauften Produkte warten müssen. Die Überlegung, wie dieses Ziel erreicht werden könnte, kann radikale neue Ideen hervorbringen. Eine Untergrundbahn könnte das Warenlager mit Häusern in der Stadt verbinden, und die Produkte könnten mit 100 Km/h durch die Tunnel verschickt werden, so dass sie bereits vor dem Kunden zu Hause ankommen! Obwohl dies unrealistisch ist, entstehen bei dieser Art von Gedankenaustausch häufig viele Ideen für die Verbesserung des Geschäfts.

Im Folgenden wird anhand eines Beispiels beschrieben, wie beim Nachdenken über Geschäftsziele die Bedeutung von scheinbar trivialen Geschäftsanwendungsfällen aufgedeckt wird. Angenommen, der Eindruck entsteht, dass viele Kunden zu Essenszeiten einkaufen gehen. Da eines der Geschäftsziele die Verbesserung der Qualität von Einrichtungen und ein anderes das Werben von Kunden ist, könnten wir uns dazu entschließen, ein Restaurant einzurichten, in dem Kunden vor oder nach dem Einkauf einen Snack einnehmen können. Der Geschäftsanwendungsfall "Mahlzeit einnehmen", der dieses Ziel unterstützt, wird im Folgenden gezeigt. Es kann sich herausstellen, dass das Restaurant eine der Hauptattraktionen des Geschäfts wird!

Im Begleittext beschriebenes Diagramm

In dem obigen Diagramm sehen wir auch, wie sich die Anpassung der Grenzen des Geschäfts auswirkt. Es wurde ein neuer Geschäftsakteur "Versender" eingeführt, ein Partner, der für die Entnahme der Produkte aus dem Warenlager und die Auslieferung an die Kunden verantwortlich ist. Mit diesem Ansatz könnten wir unter Umständen die Lieferzeit verringern und damit eines unserer Geschäftsziele erreichen.

Geschäftsanwendungsfallmodell strukturieren

Es gibt drei Hauptgründe für die Strukturierung des Geschäftsanwendungsfallmodells:

  • Geschäftsanwendungsfälle verständlicher machen
  • Teile von Workflows wiederverwenden, die von mehreren Geschäftsanwendungsfällen genutzt werden
  • Verwaltung des Geschäftsanwendungsfallmodells vereinfachen

Für die Strukturierung der Geschäftsanwendungsfälle stehen drei Arten von Beziehungen zur Verfügung. Sie verwenden diese Beziehungen, um die Teile von Geschäftsanwendungsfällen herauszufiltern, die in anderen Geschäftsanwendungsfällen wiederverwendet werden können oder die Spezialisierungen oder Optionen des Geschäftsanwendungsfalls sind. Der Geschäftsanwendungsfall, der die Änderung darstellt, ist ein so genannter Additionsanwendungsfall. Der Geschäftsanwendungsfall, der geändert wird, ist der Basisanwendungsfall.

  • Wenn ein Teil eines Basisanwendungsfalls eine Funktion darstellt, deren Ergebnis allein für den Geschäftsanwendungsfall von Bedeutung ist und nicht die Methode für die Ergebnisherleitung, können Sie diesen Teil in einen Additionsanwendungsfall extrahieren. Die Addition wird über die Einschlussbeziehung explizit in den Basisanwendungsfall eingeschlossen. Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Einschlussbeziehung im Geschäftsanwendungsfallmodell.
  • Wenn ein Teil eines Basisanwendungsfalls optional ist oder nicht erforderlich ist, um den primären Zweck des Anwendungsfalls verstehen zu können, können Sie diesen Teil in einen Additionsanwendungsfall auslagern, um die Struktur des Basisanwendungsfalls zu vereinfachen. Die Addition wird implizit über die Erweiterungsbeziehung in den Basisanwendungsfall eingeschlossen. Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Erweiterungsbeziehung im Geschäftsanwendungsfallmodell.
  • Wenn es Geschäftsanwendungsfälle gibt, die Gemeinsamkeiten in Verhalten und Struktur sowie Ähnlichkeiten im Zweck aufweisen, können diese gemeinsamen Teile in einen Basisanwendungsfall (übergeordnet) ausgelagert werden, der von Additionsanwendungsfällen (untergeordnet) geerbt wird. Die untergeordneten Anwendungsfälle können in der Struktur, die sie vom übergeordneten Anwendungsfall erben, neues Verhalten einfügen und vorhandenes Verhalten ändern. Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Anwendungsfallgeneralisierung im Geschäftsanwendungsfallmodell.

Im Begleittext beschriebenes Diagramm

Die vorherige Abbildung zeigt Akteure und Geschäftsanwendungsfälle und den Check-in-Schalter. Außerdem werden der Einschlussanwendungsfall "Gepäckabfertigung" und Erweiterungsanwendungsfall "Check-In bis Reiseziel" gezeigt.

Mit Akteurgeneralisierung können Sie zeigen, dass Akteure spezialisierte Versionen eines anderen sein können. Weitere Informationen hierzu finden Sie auf der Seite Richtlinie: Akteurgeneralisierung im Geschäftsanwendungsfallmodell.

Lesen Sie auch die Beschreibung zur Strukturierung von Systemanwendungsfällen auf der Seite Richtlinie: Anwendungsfallmodell.

Modellierungsaufwand begrenzen

Wenn Geschäftsmodelle nur entwickelt werden, um ein Software-Engineering-Projekt in Gang zu bringen, müssen Sie den Aufwand für die Geschäftsmodellierung besonders sorgfältig begrenzen. In diesem Fall lohnt es sich selten, die gesamte Organisation abzudecken, selbst wenn Sie nur einen Teil der Geschäftsteile modellieren. Um das Ziel nicht aus den Augen zu verlieren und Ergebnisse mit dem erwarteten Wert zu produzieren, sollten Sie einen Teil des gesamten Unternehmens als "Geschäftssystem" betrachten. Der ausgewählte Teil sollte der Teil sein, der das zu erstellende System direkt verwendet. Die Teile der Organisation, die Sie als extern für das Modell einstufen, können als Geschäftsakteure dargestellt werden.

Beispiel:

Das Unternehmen hat entschieden, eine neue Anwendung für die Vertriebs- und Auftragsbearbeitung zu erstellen. Um die Anforderungen der Organisation zu untersuchen und die Art und Weise auszurichten, in der das Geschäft in der Organisation ausgeführt wird, muss zuerst eine Reihe von Geschäftsmodellen erstellt werden. Die Abteilungen des Unternehmens, die die neue Auftragsanwendung nicht aktiv verwenden, werden als extern für das Modell eingestuft und durch Geschäftsakteure dargestellt.

Im Begleittext beschriebenes Diagramm

Die vorherige Abbildung zeigt Geschäftsakteure und Geschäftsanwendungsfälle in einem Geschäftsanwendungsfallmodell einer Auftragsbearbeitungsorganisation. Diese Organisation verkauft komplexe Lösungen, angepasst für jeden Kunden.

Die Geschäftsanwendungsfälle werden im Folgenden kurz beschrieben:

Auftragsprozess - Dieser Prozess beschreibt, wie das Unternehmen die entsprechenden Aktionen ausführt, um einem Kunden eine Lösung bereitzustellen, die den definierten Kundenanforderungen entspricht. Der Prozess beginnt, wenn die Geschäftsentscheidung getroffen wird, mit einer abgenommenen Lösung fortzufahren. Häufig erhält das Unternehmen hierbei eine Bestellung vom Kunden. Der Prozess endet, wenn der Kunde mit der Installation und Inbetriebnahme der Lösung zufrieden ist und die Zahlung geleistet hat. Die Zielsetzung ist, die Kundenanforderungen auf gewinnbringende Weise zu erfüllen.

Angebotsprozess - In diesem Prozess werden Angebote als Reaktion auf Kundenanforderungen generiert. Der Prozess wird durch eine Anfrage vom Kunden ausgelöst und endet, wenn der Kunde die Preise im Angebot akzeptiert (oder ablehnt). Die Zielsetzung ist, eine Preisvereinbarung zu erzielen, die für den Kunden und das Unternehmen akzeptabel ist.

Preisgestaltungsprozess - Der Preisgestaltungsprozess ist ein abstrakter Geschäftsanwendungsfall, der in den Angebotsprozess und den Auftragsprozess eingeschlossen ist. Der Prozess beginnt, wenn Kundenanforderungen vorliegen, für die ein Preis erzeugt werden muss. Die Zielsetzung des Preisgestaltungsprozesses ist, eine Lösung zu erstellen, die den Kundenanforderungen entspricht, und einen Preis dafür zu nennen.

Übersichtsbeschreibung

Eine Übersichtsbeschreibung des Geschäftsanwendungsfallmodells muss

  • den Zweck der Organisation zusammenfassen,
  • die Abgrenzungen des Modells aufzeigen, d. h. Dinge, die nicht eingeschlossen sind und warum,
  • die primären Geschäftsanwendungsfälle spezifizieren.

Beispiel:

Dieses Geschäftsanwendungsfallmodell deckt den Teil unseres Unternehmens ab, der Aufträge von unseren Kunden verwaltet, da nur dieser Teil für das Software-Engineering-Projekt von Interesse ist, das die Ergebnisse der Geschäftsmodellierung als Eingabe verwendet. Aus diesem Grund schließen wir die Teile des Unternehmens nicht ein, die sich mit der Rechnungsstellung, der Fertigung, dem Produktmanagement und der Produktentwicklung beschäftigen. Sie werden als extern eingestuft und deshalb als Geschäftsakteure dargestellt.

In dieser Organisation umfasst ein Verkauf nicht nur die Einigung über eine Lösung, sondern auch die tatsächliche Erstellung der Lösung. Um einen Preis für eine Lösung zu definieren, müssen Sie die Lösung bis zu einer gewissen Detaillierungsebene entwickeln und erstellen. Dies geschieht im Angebotsprozess. Sobald eine Einigung mit dem Kunden erzielt wurde, wird die Lösung in allen Details entwickelt und beim Kunden installiert. Dies wird im Auftragsprozess beschrieben. Angebotsprozess und Auftragsprozess schließen den abstrakten Geschäftsanwendungsfall Preisgestaltungsprozess ein.

Merkmale eines tauglichen Geschäftsanwendungsfallmodells

  • Geschäftsanwendungsfälle sind an der Geschäftsstrategie ausgerichtet, die durch konkrete Geschäftsziele beschrieben ist.
  • Anwendungsfälle entsprechen dem Geschäft, das sie beschreiben.
  • Es wurden alle Anwendungsfälle gefunden. Alle Anwendungsfälle zusammen führen die Aufgaben innerhalb des Geschäfts aus.
  • Jede Aufgabe innerhalb des Geschäfts müssen in mindestens einem Anwendungsfall eingeschlossen sein.
  • Die Anzahl und die Größe der Geschäftsanwendungsfälle ist ausgewogen.
  • Weniger Anwendungsfälle machen das Modell verständlicher.
  • Viele Anwendungsfälle können die Verständlichkeit des Modells beeinträchtigen.
  • Große Anwendungsfälle können komplex und schwer zu verstehen sein.
  • Kleine Anwendungsfälle sind häufig einfach zu verstehen. Stellen Sie jedoch sicher, dass der Anwendungsfall einen vollständigen Workflow beschreibt, der etwas von Wert für einen Kunden produziert.
  • Jeder Anwendungsfall muss eindeutig sein. Wenn der Workflow identisch mit einem anderen Anwendungsfall ist oder Ähnlichkeiten aufweist, ist es schwierig, sie später zu synchronisieren. Überlegen Sie, ob sie die beiden Workflows zu einem Anwendungsfall zusammenführen können.
  • Die Übersichtsbeschreibung des Geschäftsanwendungsfallmodells sollte ein aussagefähiges und umfassendes Bild der Organisation liefern.