![\"Use-Case](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/06\/img_6a30ffb2ce97d.png\")
<\/p>\n
Diese Fallstudie untersucht, wie Use-Case 2.0 die Anforderungserhebung, das Design und die Entwicklung ver\u00e4ndert. Indem wir ihre Kernprinzipien, praktische Anwendung und Synergie mit neu entstehenden KI-gest\u00fctzten Entwicklungstools analysieren, zeigen wir, wie diese Methode es Teams erm\u00f6glicht, das\u00a0richtige<\/em>\u00a0System effizient zu bauen, wodurch Wertlieferung bei jedem Schritt gew\u00e4hrleistet wird.<\/p>\n Fast drei\u00dfig Jahre lang haben Use-Cases als Eckpfeiler der Anforderungsanalyse gedient und Teams dabei unterst\u00fctzt, zu verstehen, wie Nutzer mit Systemen interagieren, um ihre Ziele zu erreichen. Sie haben viele moderne Techniken inspiriert, darunter Nutzerstories. Doch in den letzten Jahren ist etwas Erstaunliches geschehen \u2013 die Inspiration flie\u00dft nun in die andere Richtung.<\/p>\n Use-Case 2.0<\/strong>\u00a0ist die neue Generation der use-case-getriebenen Entwicklung \u2013 leicht, agil und schlank \u2013 inspiriert von Nutzerstories und agilen Methoden wie Scrum und Kanban. Sie stellt eine bedeutende Weiterentwicklung der traditionellen Use-Case-Praktiken dar und verbindet die Einfachheit und Fokussierung von Nutzerstories mit der umfassenden Struktur und Skalierbarkeit, die Use-Cases stets geboten haben.<\/p>\n \u201eUse-Case 2.0 vereint alle beliebten Werte der Vergangenheit \u2013 nicht nur die Unterst\u00fctzung von Anforderungen, sondern auch Architektur, Design, Test und Benutzererfahrung \u2013 und ist entscheidend f\u00fcr die Gesch\u00e4ftsmodellierung und Software-Wiederverwendung.\u201c<\/p>\n<\/blockquote>\n Die traditionelle Use-Case-Methode bestand darin, detaillierte Use-Case-Dokumente zu erstellen, die das Systemverhalten erfassen, einschlie\u00dflich kurzer Beschreibungen, Voraussetzungen, Nachbedingungen und Interaktionen zwischen Akteuren. Obwohl dies effektiv war, wurde dieser Ansatz oft zu dokumentationsintensiv und hatte Schwierigkeiten, sich an die schnelle Iteration agiler Entwicklung anzupassen.<\/p>\n Use-Case 2.0 baut auf dieser Grundlage auf und f\u00fchrt mehrere Innovationen ein:<\/p>\n Agile Ausrichtung<\/strong>: Nahtlose Integration mit agilen Methoden, die es Entwicklerteams erleichtert, mit Stakeholdern zusammenzuarbeiten, Anforderungen zu zerlegen und schnell zu iterieren<\/p>\n<\/li>\n Integration von Nutzerstories<\/strong>: Einbindung von Nutzerstories als leichtgewichtige Methode zur Erfassung von Nutzerbed\u00fcrfnissen und Aufbau gemeinsamen Verst\u00e4ndnisses<\/p>\n<\/li>\n Use-Case-Slices<\/strong>: Aufteilung komplexer Use-Cases in kleinere, handhabbare Einheiten, die unabh\u00e4ngig implementiert und getestet werden k\u00f6nnen<\/p>\n<\/li>\n Visuelle Modelle<\/strong>: Fokus auf Flussdiagramme, Aktivit\u00e4tsdiagramme und Sequenzdiagramme zur umfassenden Systemverst\u00e4ndnis<\/p>\n<\/li>\n Iterative Entwicklung<\/strong>: Testen jedes Komponenten, sobald es erstellt ist, was eine fr\u00fchzeitige Problemerkennung erm\u00f6glicht<\/p>\n<\/li>\n<\/ul>\n Im Kern f\u00fchrt Use-Case 2.0 ein entscheidendes neues Konzept ein:\u00a0den Use-Case-Slice<\/strong>. Ein Slice ist ein sorgf\u00e4ltig ausgew\u00e4hlter Teil eines Use-Cases, der unabh\u00e4ngig bearbeitet werden kann \u2013 er durchschneidet nicht nur Anforderungen, sondern auch Design, Implementierung, Testf\u00e4lle und Testergebnisse.<\/p>\n Abbildung 1: Visuelle Darstellung der Use-Case-2.0-Struktur, die die Beziehung zwischen Akteuren, Use-Cases und Slices zeigt.<\/em><\/p>\n Ivar Jacobson, Ian Spence und Kurt Bittner identifizierten sechs grundlegende Prinzipien, die die Grundlage f\u00fcr den erfolgreichen Einsatz von Use-Cases bilden:<\/p>\n Geschichten erz\u00e4hlen ist die einfachste und effektivste Art, zu kommunizieren, was ein System tun soll. Use-Cases erfassen die Ziele des Systems, w\u00e4hrend Geschichten beschreiben, wie diese Ziele erreicht werden und wie Probleme entlang des Weges bew\u00e4ltigt werden. Dadurch k\u00f6nnen Anforderungen leicht erfasst, geteilt und verstanden werden.<\/p>\n Unabh\u00e4ngig davon, ob Ihr System gro\u00df oder klein ist, ist das Verst\u00e4ndnis des Gesamtbildes unerl\u00e4sslich. Ohne diese \u00dcbersicht k\u00f6nnen Teams keine richtigen Entscheidungen bez\u00fcglich Umfang, Kosten oder Wert treffen. Ein Use-Case-Diagramm bietet eine einfache M\u00f6glichkeit, eine \u00dcbersicht \u00fcber die Anforderungen eines Systems darzustellen \u2013 es zeigt alle M\u00f6glichkeiten, wie das System genutzt werden kann, wer die Interaktion startet, und alle anderen beteiligten Parteien.<\/p>\n Abbildung 2: Ein Beispiel f\u00fcr ein Use-Case-Diagramm, das Akteure und ihre Interaktionen mit dem System veranschaulicht.<\/em><\/p>\n Wert entsteht erst, wenn ein System tats\u00e4chlich genutzt wird. Anstatt sich auf lange Listen von Funktionen oder Features zu konzentrieren, legen Use-Cases den Fokus darauf, wie das System genutzt wird, um spezifische Ziele f\u00fcr bestimmte Benutzer zu erreichen. Der Hauptablauf beschreibt die einfachste Art, das Ziel zu erreichen, w\u00e4hrend alternative Abl\u00e4ufe Optionen und Fehlerbehandlung hinzuf\u00fcgen. Teams k\u00f6nnen den Hauptablauf zuerst bereitstellen und sp\u00e4ter Alternativen hinzuf\u00fcgen \u2013 dies ist bewusst additiv gestaltet.<\/p>\n Die meisten Systeme erfordern umfangreiche Arbeit, bevor sie nutzbar sind. Es ist ein Fehler, versuchen zu wollen, ein solches System auf einen Schlag zu bauen. Stattdessen sollten Systeme in Scheiben aufgebaut werden, wobei jede Scheibe klaren Nutzen f\u00fcr die Benutzer liefert.<\/p>\n Das Rezept ist einfach:<\/p>\n Identifiziere die n\u00fctzlichste Funktion, die das System erf\u00fcllen muss<\/p>\n<\/li>\n Teile es in d\u00fcnnere, handhabbare Scheiben<\/p>\n<\/li>\n Definiere Testf\u00e4lle, die die Akzeptanz dieser Scheiben repr\u00e4sentieren<\/p>\n<\/li>\n W\u00e4hle die zentralste Scheibe, die das gesamte Konzept durchzieht<\/p>\n<\/li>\n Sch\u00e4tze es gemeinsam als Team ein und fange an zu bauen<\/p>\n<\/li>\n<\/ol>\n Software-Systeme entwickeln sich \u00fcber mehrere Generationen und Releases hinweg. Jeder Schritt sollte eine nachweisbare oder nutzbare Version des Systems liefern. Use-Case 2.0 unterst\u00fctzt dies, indem Use-Cases in Arbeitsaufgaben aufgeteilt werden, die zu Schritten zusammengestellt und schlie\u00dflich zu Releases zusammengef\u00fcgt werden k\u00f6nnen.<\/p>\n In der Softwareentwicklung gibt es keine allgemein g\u00fcltige L\u00f6sung. Unterschiedliche Teams und Situationen erfordern unterschiedliche Stile und unterschiedliche Detailgrade. Use-Case 2.0 kann so leicht sein, wie gew\u00fcnscht \u2013 kleine, kooperative Teams k\u00f6nnen leichtgewichtige Use-Case-Geschichten auf einfachen Indexkarten verwenden, w\u00e4hrend gro\u00dfe, verteilte Teams detailliertere Dokumente nutzen k\u00f6nnen.<\/p>\n Drei zentrale Konzepte definieren, wie Use-Case 2.0 in der Praxis funktioniert:<\/p>\n Use-Case-Scheiben<\/strong>sind kleinere, besser handhabbare Komponenten eines Use-Cases. Anstatt einen gesamten Use-Case in einem Dokument zu definieren, teilt Use-Case 2.0 ihn in Scheiben auf, die einfacher zu entwerfen, zu entwickeln und zu testen sind. Jede Scheibe stellt eine spezifische Funktionalit\u00e4t dar, die das System erf\u00fcllen muss, um eine bestimmte Benutzer-Aufgabe oder ein Ziel zu unterst\u00fctzen.<\/p>\n Szenarien<\/strong>stellen die verschiedenen Wege dar, die Benutzer innerhalb einer Scheibe nehmen k\u00f6nnten, um Aufgaben zu erledigen:<\/p>\n Normaler Pfad<\/strong>: Die erwartete oder Standardfolge von Operationen (der \u201egl\u00fcckliche Pfad\u201c)<\/p>\n<\/li>\n Alternative Pfade<\/strong>: Variationen oder verschiedene Wege, um dasselbe Ziel zu erreichen<\/p>\n<\/li>\n Ausnahmepfade<\/strong>: Fehler oder ungew\u00f6hnliche Situationen, die auftreten k\u00f6nnen<\/p>\n<\/li>\n<\/ul>\n Aufgaben<\/strong>sind die spezifischen Aktionen, die Benutzer innerhalb einer Szenario ausf\u00fchren m\u00fcssen, um ein Ziel zu erreichen. Sie stellen die einzelnen Schritte dar, aus denen eine Szenario besteht.<\/p>\n Zum Beispiel in einem Use-Case-Slice \u201eProdukte durchsuchen\u201c einer E-Commerce-Plattform:<\/p>\n Normalpfad<\/strong>: Benutzer sucht, sieht Ergebnisse an, w\u00e4hlt Produkt aus, f\u00fcgt es in den Warenkorb hinzu und geht zur Kasse<\/p>\n<\/li>\n Alternativer Pfad<\/strong>: Benutzer w\u00e4hlt eine andere Zahlungsmethode (PayPal statt Kreditkarte)<\/p>\n<\/li>\n Ausnahmepfad<\/strong>: Zahlung wird abgelehnt, weil nicht ausreichend Mittel vorhanden sind oder die Rechnungsadresse falsch ist<\/p>\n<\/li>\n<\/ul>\n \u00a0<\/p>\n Abbildung 3: Detaillierte Aufschl\u00fcsselung eines Use-Case-Slices, der Normalpfad, alternativer Pfad und Ausnahmepfad zeigt.<\/em><\/p>\n Genau hier bietet Use-Case 2.0 eine \u00fcberzeugende L\u00f6sung f\u00fcr eine h\u00e4ufige Agile-Herausforderung.<\/p>\n Eine User-Story ist ein eigenst\u00e4ndiges Element \u2013 sie hat keine eingebaute Beziehung zu anderen Stories. Ein Product-Backlog mit 200 User-Stories wird ohne zus\u00e4tzliche Gruppierungsmechanismen wie Epics oder Themen schwer zu navigieren. Stories k\u00f6nnen ihren Kontext verlieren, und Teams verfassen Akzeptanztests oft zu sp\u00e4t.<\/p>\n Ein Use-Case ist anders. Er gruppiert alle verwandten Stories unter einem Ziel, mit:<\/p>\n Ein klares Ziel (der Use-Case selbst)<\/p>\n<\/li>\n Ein schrittweiser Ablauf (der Grundablauf)<\/p>\n<\/li>\n Definierte Variationen (alternative Abl\u00e4ufe)<\/p>\n<\/li>\n Akzeptanzkriterien (Testf\u00e4lle)<\/p>\n<\/li>\n<\/ul>\n Wenn Sie einen Use-Case betrachten, sehen Sie das vollst\u00e4ndige Bild davon, wie ein Benutzer ein bestimmtes Ziel erreicht, nicht nur ein einzelnes Fragment.<\/p>\n Use-Case 2.0 bietet Struktur f\u00fcr agile Teams, die mit h\u00e4ufigen Herausforderungen konfrontiert sind:<\/p>\n E-Commerce-Plattform<\/strong>: Use-Cases f\u00fcr ein Online-Einkaufssystem umfassen Produkte durchsuchen, Produkte suchen, in Warenkorb hinzuf\u00fcgen, zur Kasse gehen und Bezahlen. Das fr\u00fche Use-Case-Diagramm zeigt fehlende Abl\u00e4ufe auf \u2013 wie beispielsweise \u201eGast-Kasse\u201c \u2013, die vor der Sprint-Zusage hinzugef\u00fcgt werden k\u00f6nnen, um Abbr\u00fcche im Warenkorb in der Produktion zu verhindern.<\/p>\n Mobile-Banking-App<\/strong>: Die Dokumentation alternativer Abl\u00e4ufe wie \u201eung\u00fcltige Anmeldeinformationen \u2192 mehrfaktoriger Fallback\u201c erfasst Sicherheitsl\u00fccken fr\u00fchzeitig, vermeidet kostspielige Patches nach der Markteinf\u00fchrung und st\u00e4rkt das Vertrauen der Benutzer.<\/p>\n Dienst f\u00fcr Fahrgemeinschaften<\/strong>: Use-Case-Slices treiben die Entwicklung des Minimum Viable Products (MVP) voran \u2013 beginnen Sie mit Anfrage, Annahme und Bezahlung; f\u00fcgen Sie sp\u00e4ter Bewertungen und Beschwerden hinzu. Dies erm\u00f6glicht eine schnelle Wertlieferung mit klarer Priorisierung.<\/p>\n Plattform f\u00fcr Gesundheitsterminen<\/strong>: Die \u00dcberpr\u00fcfung der Use-Case-Fl\u00fcsse durch Stakeholder bringt Anforderungen im Bereich \u201eNichterscheinen\u201c ans Licht. Eine automatisierte Umr\u00e4umung kann hinzugef\u00fcgt werden und k\u00f6nnte verpasste Termine potenziell reduzieren.<\/p>\n Abbildung 5: Beispiel f\u00fcr ein agiles Team, das Use-Case-Slices nutzt, um Sprints zu planen.<\/em><\/p>\n Use-Case 2.0 wurde urspr\u00fcnglich 2011 entwickelt, lange bevor KI-Coding-Assistenten existierten. Doch seine Prinzipien erweisen sich als perfekte Passung f\u00fcr die KI-unterst\u00fctzte Entwicklung.<\/p>\n KI-Coding-Assistenten arbeiten am besten mit klaren, strukturierten Spezifikationen. Ein Use-Case bietet:<\/p>\n Ein klares Ziel, das die KI verstehen kann<\/p>\n<\/li>\n Eine schrittweise Abfolge, die die KI umsetzen kann<\/p>\n<\/li>\n Definierte Abweichungen, die die KI handhaben kann<\/p>\n<\/li>\n Akzeptanzkriterien, die die KI erf\u00fcllen muss<\/p>\n<\/li>\n<\/ul>\n Die vier Phasen der KI-unterst\u00fctzten Entwicklung passen naturgem\u00e4\u00df zu den Prinzipien von Use-Case 2.0:<\/p>\n Entstehung<\/strong>\u00a0\u2192 \u201eDas gro\u00dfe Ganze verstehen\u201c \u2013 erstellen Sie Gesch\u00e4ftsanforderungen und erste Use-Case-Diagramme<\/p>\n<\/li>\n Ausarbeitung<\/strong>\u00a0\u2192 \u201eAuf Wert fokussieren\u201c \u2013 erstellen Sie Spezifikationen mit Grund- und Alternativabl\u00e4ufen<\/p>\n<\/li>\n Aufbau<\/strong>\u00a0\u2192 \u201eDas System in Scheiben aufbauen\u201c \u2013 mit KI kann die Arbeitseinheit die gesamte Use-Case-Spezifikation sein, nicht nur eine Scheibe<\/p>\n<\/li>\n \u00dcbergang<\/strong>\u00a0\u2192 \u201eDas System in Schritten liefern\u201c \u2013 die Benutzerakzeptanzpr\u00fcfung best\u00e4tigt, dass Use-Cases die Bed\u00fcrfnisse der Stakeholder erf\u00fcllen<\/p>\n<\/li>\n<\/ul>\n Abbildung 6: Darstellung, wie KI-Assistenten in Use-Case-2.0-Workflows integriert werden.<\/em><\/p>\n Sie m\u00fcssen die gesamte Use-Case-2.0-Praxis nicht sofort \u00fcbernehmen. Beginnen Sie mit drei Dingen:<\/p>\n Zeichnen Sie ein Use-Case-Diagramm<\/strong>\u00a0\u2014 Identifizieren Sie die Akteure und Use-Cases f\u00fcr Ihr System. Das dauert 30 Minuten und gibt Ihnen das gro\u00dfe Ganze.<\/p>\n<\/li>\n Schreiben Sie eine Use-Case-Erz\u00e4hlung<\/strong>\u00a0\u2014 W\u00e4hlen Sie den wichtigsten Use-Case aus. Schreiben Sie den Grundablauf als Aufz\u00e4hlung. Listen Sie die Alternativabl\u00e4ufe zun\u00e4chst nur als Namen auf.<\/p>\n<\/li>\n Implementieren Sie Ihren ersten Use-Case<\/strong>\u00a0\u2014 Ob Sie manuelle Entwicklung oder KI-Unterst\u00fctzung nutzen, lassen Sie den Use-Case Ihre Implementierung leiten.<\/p>\n<\/li>\n<\/ol>\n Sie k\u00f6nnen Anwendungsf\u00e4lle in einer einfachen Tabellenkalkulation oder auf Post-it-Notizen verfolgen. Keine speziellen Werkzeuge sind erforderlich, um mit Use-Case 2.0 zu beginnen.<\/p>\n Use-Case 2.0 ist keine Alternative zu Nutzergeschichten \u2013 es ist eine Erg\u00e4nzung. Anwendungsf\u00e4lle geben Ihnen das gro\u00dfe Ganze und die Struktur. Testf\u00e4lle liefern Ihnen eine klare Definition des Abschlusses. Bei manueller Entwicklung liefern Slices die passend dimensionierten Arbeitspakete.<\/p>\n Der entscheidende Erkenntnis ist, dass Anwendungsf\u00e4lle die Techniken der Nutzergeschichten enthalten, gleichzeitig aber erheblich mehr f\u00fcr gr\u00f6\u00dfere Systeme, gr\u00f6\u00dfere Teams und komplexere Entwicklungen bieten. Sie sind so leichtgewichtig wie Nutzergeschichten, k\u00f6nnen sich aber nahtlos und strukturiert skalieren, um so viel Detail aufzunehmen, wie erforderlich ist. Vor allem treiben und verbinden sie viele andere Aspekte der Softwareentwicklung.<\/p>\n In einer \u00c4ra, in der KI die Art und Weise ver\u00e4ndert, wie wir Software entwickeln, bietet Use-Case 2.0 die strukturierte, nutzerzentrierte Grundlage, die sicherstellt, dass wir das\u00a0richtige<\/em>\u00a0System bauen \u2013 nicht nur ein System, das funktioniert. Durch die Annahme dieser entwickelten Methodik k\u00f6nnen Teams mehr Klarheit, Effizienz und Wertlieferung in ihren Agile-Reisen erreichen.<\/p>\n Use-Case 2.0: Die agile Evolution der Anforderungsingenieurwesen<\/strong><\/a>: Umfassender \u00dcberblick \u00fcber die Prinzipien und Praktiken von Use-Case 2.0.<\/p>\n<\/li>\n Integration von Anwendungsf\u00e4llen mit agilen Methoden<\/strong><\/a>: Leitfaden zur Kombination von Anwendungsf\u00e4llen mit Scrum und Kanban.<\/p>\n<\/li>\n Die Kraft von Use-Case-Slices<\/strong><\/a>: Detaillierte Erkl\u00e4rung der Slicing-Techniken in Use-Case 2.0.<\/p>\n<\/li>\n
\nDie Entwicklung der Anforderungsanalyse<\/h2>\n
\n
Was macht Use-Case 2.0 anders?<\/h3>\n
\n
![\"Visual](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/06\/img_6a30fe21b8b6d.png\")
<\/p>\n
\nDie Sechs Prinzipien von Use-Case 2.0<\/h2>\n
1. Halte es einfach, indem du Geschichten erz\u00e4hlst<\/h3>\n
2. Verstehe das gro\u00dfe Ganze<\/h3>\n
![\"A](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/06\/img_6a30fe458f737.png\")
<\/p>\n3. Konzentriere dich auf Wert<\/h3>\n
4. Baue das System in Scheiben<\/h3>\n
\n
5. Liefere das System in Schritten<\/h3>\n
6. Passe dich an die Bed\u00fcrfnisse des Teams an<\/h3>\n
\nDie Anatomie von Use-Case 2.0: Scheiben, Szenarien und Aufgaben<\/h2>\n
\n
\n
![\"Detailed](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/06\/img_6a30fe7b50e23.png\")
<\/p>\n
\nUse-Cases im Vergleich zu User-Stories: Warum beide wichtig sind<\/h2>\n
\n
![\"User](\"https:\/\/example.com\/user-stories-vs-use-cases.jpg\"\/)
\nAbbildung 4: Vergleichsdiagramm, das die Unterschiede und die erg\u00e4nzende Natur von User-Stories und Use-Cases hervorhebt.<\/em><\/p>\n
\nUse-Case 2.0 in der agilen Praxis: Praxisbeispiele<\/h2>\n
![\"Example](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/06\/img_6a30fea62f79d.png\")
<\/p>\n
\nDie Verbindung mit KI: Use-Case 2.0 trifft auf KI-unterst\u00fctzte Entwicklung<\/h2>\n
\n
\n
![\"Illustration](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/06\/img_6a30feca490da.png\")
<\/p>\n
\nEinstieg in Use-Case 2.0<\/h2>\n
\n
\nFazit<\/h2>\n
![\"The](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/06\/img_6a30ff182e2a4.png\")
<\/p>\n
\nQuellen<\/h2>\n
\n