Was ist ein Anwendungsfall? Wie man einen schreibt, Beispiele und eine Vorlage

Die Gestaltung eines Produkts umfasst mehr als ein einfaches Auflisten von Funktionen und Zielen. Wie hättest du jemandem die Interaktion von Benutzer*innen mit dem Smartphone beschrieben, bevor es auf den Markt kam? Es ein Mobiltelefon zu nennen, mit dem man im Internet surfen kann, ist ein guter Anfang, aber das erklärt nicht die Komplexität seiner Systeme. Um die Interaktionen von Benutzer*innen mit einem System, Tool oder Produkt abzubilden, brauchst du einen Anwendungsfall.

Anwendungsfälle sind Beschreibungen der Art und Weise, wie Benutzer*innen mit Systemen interagieren, um Aufgaben zu erledigen oder Ziele zu erreichen. Die Abbildung dieser Interaktionen kann die frühzeitige Planung verbessern und einen reibungslosen Entwicklungszyklus gewährleisten. Um dir bei der Integration in die Projektplanung zu helfen, definieren wir einen Anwendungsfall, erklären, wie man einen schreibt, und geben Beispiele.

Was ist ein Anwendungsfall?

Ein Anwendungsfall erklärt, wie Benutzer*innen mit einem Produkt oder System interagieren. Er umreißt den Ablauf von Benutzereingaben und zeigt erfolgreiche und fehlgeschlagene Wege zum Erreichen von Zielen auf. So können Produktteams besser verstehen, was ein System tut, wie es funktioniert und warum Fehler auftreten. Du kannst einen Anwendungsfall aufschreiben oder ein Modell für visuelle Denker grafisch darstellen.

Die Anwendungsfälle sind je nach Zielgruppe oder System unterschiedlich komplex. Aber insgesamt sollte dein Anwendungsfall einige Schlüsselkomponenten identifizieren. Zu den wichtigsten gehören:

• Akteur: alles, was ein Verhalten zeigt, das mit einem System interagiert, z. B. ein einzelner Benutzer, ein Team oder eine andere Software
• System: das Produkt oder die Dienstleistung mit definierter Funktionalität
• Ziel: der Zweck oder das Ziel, das Benutzer*innen mit den Funktionen eines Systems erreichen

Akteure, Systeme und Ziele bilden die Grundlage für einen Anwendungsfall. Wenn du anfängst, die Interaktionen des Systems zu verfolgen, kommen ein paar neue Elemente ins Spiel:

• Stakeholder: Personen, die ein Interesse an der Leistung eines Systems haben
• Primärer Akteur:der Akteur, der die Funktion eines Systems initiiert, um ein Ziel zu erreichen
• Voraussetzungen:Grundlegende Faktoren, die erforderlich sind, damit der Anwendungsfall eintreten kann
• Auslöser: Ereignisse, die einen Anwendungsfall beginnen
• Grundlegende Flüsse: Anwendungsfälle, in denen Systeme wie vorgesehen funktionieren, um ein Ziel zu erreichen
• Alternative Flüsse: unterschiedliche Ergebnisse, je nachdem, wann und wie ein System vom Kurs abweicht

Anwendungsfalltypen

Anwendungsfälle gibt es in zwei Formen: geschäftlich und systemisch. Ein Systemanwendungsfall ist eine detaillierte Betrachtung dessen, wie Benutzer*innen mit jedem Teil eines Systems interagieren. Er zeigt, wie individuelle Eingaben und Kontexte dazu führen, dass das System zu unterschiedlichen Ergebnissen kommt. Dieser Detaillierungsgrad verdeutlicht, wie die einzelnen Funktionen eines Systems in einem Szenario arbeiten.

Geschäftliche Anwendungsfälle vermitteln ein allgemeineres Bild davon, wie Benutzer*innen mit deinem Unternehmen interagieren könnte, um ihre Ziele zu erreichen. Anstatt sich auf technische Details zu konzentrieren, handelt es sich um eine Beschreibung von Ursache und Wirkung der verschiedenen Eingaben. Wenn du zum Beispiel eine Plattform für Code-Debugging betreibst, erklärt dein geschäftlicher Anwendungsfall, wie Benutzer*innen ihren Code eingeben und Fehlermeldungen erhalten.

Einige Teams schreiben gerne einen Geschäftsanwendungsfall, um die Prozesse eines Systems vor der Entwicklung zu skizzieren. Wenn die Entwickler*innen mit ihrer Arbeit beginnen, wird ein*e Manager*in weitere technische Systemanwendungsfälle umreißen.

Anwendungsszenario vs. Anwendungsfall

Anwendungsfälle zeigen alle Möglichkeiten, wie ein System funktioniert, wenn es darum geht, Ziele zu erreichen, während ein Szenario nur ein Beispiel darstellt. In einem Szenario kann das System erfolgreich sein oder scheitern, die Ziele der Benutzer*innen zu erreichen. Einfach ausgedrückt: Mehrere Nutzungsszenarien ergeben zusammen einen Anwendungsfall.

Anwendungsfall vs. User Story

Anwendungsfälle zeigen, wie Benutzer*innen mit einem System interagieren, und User Storys beschreiben Funktionen aus der Sicht der Benutzer*innen. Infolgedessen sind User Storys viel kürzer als Anwendungsfälle und bestehen in der Regel aus kurzen Beschreibungen, die ihr als Ausgangspunkt für die Entwicklung verwendet. Darüber hinaus können Anwendungsfälle mehrere Teams in einer Organisation unterstützen, während User Storys Produktteams bei der Entwicklung ihrer Tools unterstützen.

Anwendungsfall vs. Testfall

Während ein Anwendungsfall beschreibt, wie Benutzer*innen und Systemfunktionen zusammenarbeiten, um Ziele zu erreichen, überprüfen Testfälle, ob eine einzelne Funktion korrekt funktioniert. Im Gegensatz zu Anwendungsfällen betrachten Testfälle die Funktionalität isoliert.

Ein Testfall könnte beispielsweise die Validierung der Login-Funktionalität auf einer E-Mail-Plattform beinhalten, um sicherzustellen, dass sich ein*e Benutzer*in nach der Erstellung eines Kontos jederzeit in jedem Browser anmelden kann.

Wie man einen Anwendungsfall schreibt

Einen Anwendungsfall zu schreiben klingt kompliziert, erfordert aber nur das Verständnis deines Systems und seiner Benutzer*innen. Du kannst einen Anwendungsfall schreiben, indem du diese sechs Schritte befolgst:

1. Beschreibe dein System

Beginne damit, dein System oder das Produkt oder die Dienstleistung zu beschreiben, die du und dein Team entwickeln werden. Konzentriere deine Beschreibung darauf, was dein System für die Benutzer*innen leistet. In einem Geschäftsanwendungsfall kannst du diesen Hintergrund allgemein halten und erklären, was er bewirkt. Für einen Systemanwendungsfall gib eine detaillierte Beschreibung der Funktionsweise deines Produkts an.

Definiere dein System, indem du fragst:

• Welche Form hat es: Produkt, Dienstleistung oder Software?
• Welche Funktionen bietet es?
• Welche Ziele kannst du damit erreichen?
• Wie werden diese Ziele erreicht?
• Was kannst du aus anderen Dokumenten wie Projektaufträgen über das System lernen?

2. Identifiziere die Akteure

Mit Akteuren sind in der Regel Benutzer*innen und Kund*innen gemeint. Der Begriff kann sich aber auch auf jede externe Kraft beziehen, die mit deinem System interagiert. Dein Akteur benötigt klar definierte Verhaltensweisen, die erklären, wie und warum Akteure dein System verwenden.

Identifiziere Akteure, indem du fragst:

• Handelt es sich dabei um Einzelpersonen, Teams, Hardware oder ein anderes System?
• Werden primäre und sekundäre Akteure dasselbe Verhalten zeigen?
• Werden Stakeholder in deinem Anwendungsfall die Rolle von Akteuren übernehmen?

3. Definiere die Ziele deiner Akteure

Anwendungsfälle zeigen, welche Ergebnisse die Akteure von einem System erwarten. Denke daran, dich auf die Wünsche deiner Akteure und nicht auf die Fähigkeiten des Systems zu konzentrieren, um zu verstehen, warum Benutzer*innen dein System nutzen. In manchen Fällen wollen Kunden die Systeme für mehr als ein Ziel nutzen. Durch die Auflistung aller dieser Ziele entsteht ein robusterer Anwendungsfall.

4. Erstelle ein Szenario

In einem Anwendungsfall sind Szenarien die Abfolge von Aktionen, die Kunden beim Verwenden eines Systems durchführen, und der Fluss der Effekte dieser Interaktionen. Deine grundlegenden Flüsse decken Szenarien ab, in denen ein System wie vorgesehen funktioniert. Ein*e Benutzer*in geht auf das System zu, gibt die richtigen Eingaben ein, und dein System hilft, die gewünschten Ziele zu erreichen.

Beginne mit diesen erfolgreichen, grundlegenden Flüssen, um eine Basis zu schaffen. Du kannst die Techniken der Prozessabbildung nutzen, um mögliche Probleme in den nächsten Flüssen zu identifizieren.

5. Erwäge alternative Flüsse

Nachdem du ein erfolgreiches Szenario geschrieben hast, schreibe alternative Flüsse, die zu anderen Ergebnissen führen. In der Regel handelt es sich bei alternativen Flüssen um den Missbrauch eines Systems, der die Akteure daran hindert, ihre Ziele zu erreichen. Du kannst dabei jedoch auch interne Fehler feststellen, die zum Ausfall eines Systems führen, oder unbeabsichtigte Wege, auf denen Systeme Ziele erreichen können.

Alternative Flüsse zeigen, wie verschiedene Akteure ein System nutzen und erfolgreich sind oder scheitern. Sie geben einen differenzierten Überblick über alles, was dein System tun kann, um dich bei der Fehlersuche zu unterstützen.

6. Wiederhole die Schritte 2 bis 5, um deinen Anwendungsfall zusammenzustellen

Mit genügend Variationen von Akteuren, Zielen und Szenarien kannst du zeigen, wie dein System funktioniert. Wenn du diese Flüsse zusammenstellst, erhältst du einen Anwendungsfall, der die Entwicklung verbessern und in andere Dokumente wie Projektstatusberichte einfließen kann.

Bei einfachen Systemen genügt es, einige Elemente zu ändern, um jedes mögliche Ergebnis zu sehen. Komplexe Systeme haben jedoch eventuell zu viele Elemente, um jedes Ergebnis zu sehen. In solchen Fällen kannst du dich darauf konzentrieren, die häufigsten Interaktionen zu testen. Du kannst auch Designsysteme entwerfen, die ungetestete Kombinationen verhindern.

Probiere die Figma Anwendungsfallvorlage aus

Bereit, mit dem Brainstorming zu Anwendungsfällen zu beginnen? Probiere die Figma Anwendungsfallvorlage aus, um deine Systeme aufzuschlüsseln und neue Lösungen zu finden.

Anwendungsfallbeispiel

Angenommen, du bist ein*e Produktmanager*in und entwickelst eine mobile Banking-App für dein Unternehmen. Deine Plattform soll die Benutzerregistrierung und die Einrichtung von Konten vereinfachen. Hier ist ein Beispiel für ein Anwendungsfallformat basierend auf dieser App:

Hintergrundinformationen:

• System: eine Mobile-Banking-App
• Primärer Akteur: Kund*innen, die ein Konto eröffnen möchten
• Sekundärer Akteur: Versicherer und automatisierte Tools, die Zinssätze und maximale Kapitalsalden berechnen
• Ziele: Zeitersparnis bei der Kontoregistrierung und beim Onboarding
• Stakeholder: der CEO und der Produkt-VP deines Unternehmens
• Voraussetzungen: Benutzer*innen laden die App herunter und erfüllen die Kontoanforderungen
• Auslöser: Der/die Benutzer*in entscheidet sich, ein neues Konto in der App zu erstellen

Szenarien:

• Grundlegender Fluss: Benutzer*innen laden deine App herunter und entscheiden sich, ein neues Konto zu erstellen. Die Anwendung sammelt Informationen über ihre oder seine anderen Konten und die Kreditwürdigkeit. Anschließend teilt sie automatisch die Konten, für die sich die Person qualifiziert, und deren Zinssätze mit. Der/die Benutzer*in sucht sich ein passendes Konto aus und registriert sich.
• Alternativer Fluss 1: Die Benutzer*innen geben ihre Finanzdaten ein und die App generiert schnell Kontooptionen. Jedes Konto verwendet jedoch standardmäßig den höchsten Zinssatz, den der finanzielle Hintergrund zulässt. Daher verlassen Benutzer*innen die App, um einen niedrigeren Zinssatz zu finden.
• Alternativer Fluss 2: Der Onboarding-Prozess funktioniert wie vorgesehen, aber die App hat mit Compliance-Problemen wie den Anforderungen für Know Your Customer (KYC) zu kämpfen. Während die App Kontooptionen bieten kann, verlangsamen zusätzliche Compliance-Schritte den Prozess.
• Alternativer Fluss 3: Da die App nur andere Konten und Kreditscores betrachtet, kann sie nicht die gesamte Bandbreite an Kontooptionen anbieten. Beispielsweise kann sie nur Kreditkarten und Kreditlinien anbieten. Kunden, die nach Hypotheken suchen, müssen also woanders hingehen.

Vorteile von Anwendungsfällen

In der Planungsphase definieren Anwendungsfälle den Projektumfang, die Anforderungen und die Roadmap. Teams können auch die besten Ergebnisse für die Benutzer*innen besprechen und einen Weg dorthin entwerfen. Mit alternativen Abläufen kannst du auch Risiken vorhersehen, bevor sie das Benutzererlebnis beeinträchtigen. Wenn das noch kein ausreichender Grund ist, einen Anwendungsfall zu verfassen, hier einige weitere Vorteile:

• Sie erklären den Wert: Anwendungsfälle erklären die Funktionen eines Systems in einfachen Worten. Wenn du also deine Pläne den Stakeholdern vorstellst, macht ein Anwendungsfall dein System leichter verständlich.
• Sie sagen Kosten voraus: Ein Anwendungsfall umreißt die Komplexität eines Systems. Mehr Komplexität kann mit zusätzlichen Funktionen oder Schutzmaßnahmen einhergehen. Wenn du weißt, wie komplex dein System ist, kannst du die Entwicklungskosten abschätzen.
• Sie verbessern die Planung: Ohne einen Anwendungsfall konzentrieren sich Designer und Entwickler darauf, was ein System tut, nicht, wie es das tut. Anwendungsfälle helfen den Teams jedoch dabei, alle Möglichkeiten zur Implementierung von Funktionen und Schutzmaßnahmen zu berücksichtigen.
• Sie informieren über alternative Nutzungen: Nicht alle alternativen Flüsse in einem System führen zu Misserfolgen. Das Entwerfen verschiedener Szenarien findet neue Lösungen für alte Probleme oder erweitert dein Verständnis dafür, was ein System leisten kann.

Perfektioniere deine Anwendungsfälle mit FigJam

Anwendungsfälle gehen über die Beschreibung der Möglichkeiten deines Produkts hinaus. Sie geben Stakeholdern und Teams ein klares Bild zu Benutzerinteraktionen und erfolgreichen Ergebnissen. Ob es das Hinzufügen einer neuen Funktion, Rapid Prototyping oder die Neugestaltung eines Systems ist, deine Planung sollte mit dem Schreiben eines Anwendungsfalls beginnen.

Je mehr Insights in Akteure, Interaktionen und Ergebnisse, desto besser – deshalb ist es wichtig, mit deinem Team und deinen Stakeholdern an Anwendungsfällen zusammenzuarbeiten. Ein gemeinsam genutztes Online-Whiteboard wie FigJam optimiert die Zusammenarbeit zwischen Remote-Teams und unterstützt dich beim Erstellen umfassender Anwendungsfälle. Unsere Galerie mit über 300 Vorlagen kann Teams in jeder Entwicklungsphase zusammenbringen.