# Anwendungsfalldiagramm erklärt: Use Cases

> Ein Anwendungsfalldiagramm (Use-Case-Diagramm) ist ein UML-Diagramm, das aus Nutzersicht zeigt, wer ein System wofür nutzt. Akteure (Rollen) stehen außerhalb der Systemgrenze, Anwendungsfälle (Ellipsen) innerhalb. Mit «include» wird ein Teilablauf immer eingebunden, mit «extend» nur unter einer Bedingung ergänzt.

**Autor:** Mr. Benjamin · **Beruf:** IT-Grundlagen
**Veröffentlicht:** 2026-10-28 · **Aktualisiert:** 2026-10-28
**Quelle:** https://yellowbluetech.de/blog/anwendungsfalldiagramm-erklaert

---

Bevor jemand eine Zeile Code schreibt, muss klar sein, was das System überhaupt können soll – und für wen. Genau dafür gibt es das Anwendungsfalldiagramm: eine einzige Zeichnung, die Kunde und Entwickler gleichermaßen verstehen.

## Was ist ein Anwendungsfalldiagramm?

Das Anwendungsfalldiagramm, englisch **Use-Case-Diagramm**, gehört zur Modellierungssprache [UML](/blog/uml-diagramme-grundlagen). Es zeigt **aus Sicht der Nutzer**, welche Funktionen ein System bietet und wer sie nutzt – ohne ein Wort über Technik, Datenbanken oder Programmiersprachen.

Deshalb steht es am Anfang eines Projekts: Es hilft, mit dem Kunden die Anforderungen zu klären, die später im [Lastenheft und Pflichtenheft](/blog/lastenheft-pflichtenheft) festgehalten werden.

## Die Bausteine

| Baustein | Darstellung | Bedeutung |
| --- | --- | --- |
| **Systemgrenze** | Rechteck mit Systemname | Was gehört zum System, was nicht? |
| **Akteur** | Strichmännchen | Rolle, die mit dem System arbeitet |
| **Anwendungsfall** | Ellipse | eine Funktion, die dem Akteur etwas nützt |
| **Assoziation** | einfache Linie | Akteur nutzt Anwendungsfall |

> **Merksatz**
>
> **Akteure stehen außerhalb** der Systemgrenze, **Anwendungsfälle innerhalb**. Ein Akteur ist eine **Rolle**, keine Person: Dieselbe Frau kann am Montag „Mitarbeiterin" und am Dienstag „Administratorin" sein. Auch ein anderes System, etwa ein Zahlungsdienst, kann ein Akteur sein.

## Beispiel: Ticketsystem im IT-Support

Ein Unternehmen führt ein [Ticketsystem](/blog/ticketsystem-support-level) ein. Mitarbeiter melden Störungen und sehen den Bearbeitungsstand, der Support bearbeitet die Tickets:

```text
              ┌──────────── Ticketsystem ────────────┐
              │                                      │
Mitarbeiter ──┼── ( Störung melden )                 │
              │                                      │
Mitarbeiter ──┼── ( Ticketstatus ansehen )           │
              │                                      │
Support ──────┼── ( Ticket bearbeiten )              │
              │                                      │
              └──────────────────────────────────────┘
```

Wichtig: Die Namen der Anwendungsfälle bestehen aus **Verb und Objekt** („Ticket bearbeiten"). Das Diagramm sagt nur, **dass** der Support Tickets bearbeitet, nicht in welcher Reihenfolge und mit welchen Schritten.

## include und extend

Wenn mehrere Anwendungsfälle dieselben Schritte brauchen oder ein Fall nur manchmal dazukommt, helfen zwei Beziehungen. Beide werden als **gestrichelter Pfeil** mit Beschriftung gezeichnet:

```text
( Ticket bearbeiten ) - - «include» - - ▶ ( Anmelden )
( Ticket eskalieren ) - - «extend»  - - ▶ ( Ticket bearbeiten )
```

| | «include» | «extend» |
| --- | --- | --- |
| **Bedeutung** | Der eingebundene Fall wird **immer** ausgeführt | Der erweiternde Fall kommt **nur unter einer Bedingung** dazu |
| **Beispiel** | Ticket bearbeiten erfordert immer das Anmelden | Ticket eskalieren nur, wenn die Frist droht, überschritten zu werden |
| **Pfeil zeigt** | vom Basisfall zum eingebundenen Fall | vom erweiternden Fall zum Basisfall |

> **Prüfungstipp**
>
> Die Prüfung fragt gern nach der Abgrenzung: **include = immer dabei** (Pflichtbestandteil), **extend = kann dazukommen** (optional, an eine Bedingung geknüpft). Achte auf die **Pfeilrichtung**: Bei «include» zeigt der Pfeil weg vom Basisfall, bei «extend» hin zum Basisfall. Ein weiterer Klassiker: Akteure außerhalb der Systemgrenze, Anwendungsfälle innerhalb.

## So zeichnest du ein Anwendungsfalldiagramm

1. **System abgrenzen:** Was gehört dazu, was nicht? Das Rechteck zeichnen und benennen.
2. **Akteure sammeln:** Wer arbeitet mit dem System? Rollen statt Namen aufschreiben.
3. **Anwendungsfälle formulieren:** Was will jeder Akteur erreichen? Als Verb plus Objekt benennen.
4. **Verbinden:** Jeden Akteur mit seinen Anwendungsfällen durch eine Linie verbinden.
5. **include und extend sparsam einsetzen:** Nur, wenn ein Teilablauf wirklich mehrfach vorkommt oder optional ist.

> **Hinweis**
>
> Häufige Fehler: Ein **konkreter Name** statt einer Rolle als Akteur, **zu feine Anwendungsfälle** wie „Button klicken" und der Versuch, einen **Ablauf** darzustellen. Das Anwendungsfalldiagramm zeigt Funktionen, keine Reihenfolge. Für Abläufe gibt es andere Diagramme oder eine textuelle Beschreibung des Anwendungsfalls.

## Selbstkontrolle

**Frage:** Beim Bearbeiten eines Tickets kann der Support bei Bedarf eskalieren. Welche Beziehung passt zwischen „Ticket eskalieren“ und „Ticket bearbeiten“?

- [ ] «include», weil die Eskalation immer stattfindet.
- [x] «extend», weil die Eskalation nur bei Bedarf dazukommt.
- [ ] Keine Beziehung, beide sind unabhängig.
- [ ] Eine Vererbung zwischen den beiden Fällen.

**Erklärung:** Die Eskalation ist optional und nur unter einer Bedingung nötig, sie ergänzt also den Basisfall. Das ist eine «extend»-Beziehung. Bei «include» wäre der eingebundene Fall bei jeder Ausführung des Basisfalls Pflicht.

## Häufige Fragen

### Was ist der Unterschied zwischen Anwendungsfalldiagramm und Klassendiagramm?

Das Anwendungsfalldiagramm ist fachlich und zeigt aus Nutzersicht, was das System leistet und wer es nutzt. Das Klassendiagramm ist technisch und zeigt den inneren Aufbau aus Klassen, Attributen und Beziehungen. Grob gesagt: erst das fachliche Was, dann das technische Wie.

### Wann benutze ich include und wann extend?

Mit include bindest du einen Teilablauf ein, der bei jeder Ausführung des Basisfalls dazugehört, etwa das Anmelden. Mit extend beschreibst du eine optionale Ergänzung, die nur unter einer Bedingung ausgelöst wird, etwa das Eskalieren eines Tickets. Im Zweifel hilft die Frage: Passiert das immer oder nur manchmal?

### Zeigt ein Anwendungsfalldiagramm die Reihenfolge der Schritte?

Nein. Es zeigt nur, welche Funktionen es gibt und wer sie nutzt. Den genauen Ablauf eines Anwendungsfalls beschreibt man getrennt, zum Beispiel als Text mit Vorbedingung, Schritten und Ergebnis, oder mit einem anderen UML-Diagramm.

### Kann ein anderes System ein Akteur sein?

Ja. Ein Akteur ist alles, was von außen mit dem System interagiert: Menschen in einer Rolle, aber auch andere Systeme, etwa ein externer Zahlungsdienst oder ein Zeiterfassungsterminal. Entscheidend ist, dass der Akteur außerhalb der Systemgrenze steht.

**Weiterlesen:** [UML-Grundlagen: Klassendiagramm und Use Cases](/blog/uml-diagramme-grundlagen) · [Lastenheft und Pflichtenheft: der Unterschied](/blog/lastenheft-pflichtenheft) · [Softwaretests: von Unit-Test bis Abnahme](/blog/softwaretests-grundlagen)

## Das Wichtigste in Kürze

- Das **Anwendungsfalldiagramm** zeigt aus **Nutzersicht**, wer welche Funktion eines Systems nutzt.
- **Akteure** (Rollen, Strichmännchen) stehen **außerhalb**, **Anwendungsfälle** (Ellipsen) **innerhalb** der Systemgrenze.
- Anwendungsfälle heißen **Verb plus Objekt**, etwa „Ticket bearbeiten".
- **«include»** = immer dabei, **«extend»** = optional unter einer Bedingung.
- Es zeigt **Funktionen, keine Abläufe**.