Use Case: OptiSoft abgeschlossen

✅ Sehr gute Lösung: Alle Anforderungen sind abgedeckt und die include-Beziehungen zeigen in die richtige Richtung. Achte künftig darauf, die offenen Pfeilspitzen an den «include»-Linien deutlich zu zeichnen, damit kein Prüfer Punkte abzieht.

Geschätzt in der Prüfung: fast alle Punkte

✅ Korrekt

• Alle drei Akteure (Kunde, Mitarbeiter IT-Abteilung, Serviceteam) sind benannt und stehen außerhalb der Systemgrenze.
• Die Systemgrenze ist vorhanden und mit „Störungsmeldungen“ beschriftet.
• Alle geforderten Use Cases sind als Ellipsen innerhalb der Systemgrenze vorhanden: Störungsmeldung senden, Störungsmeldung erfassen, Arbeitsplanung erstellen, Priorisieren, Arbeitsaufträge bearbeiten, Rückmeldung geben.
• Die Assoziationen sind als einfache Linien den richtigen Akteuren zugeordnet: Kunde zu senden, IT-Abteilung zu erfassen und Arbeitsplanung, Serviceteam zu bearbeiten.
• Die Formulierung „immer“ ist richtig als «include» umgesetzt: gestrichelt, vom Basis-Use-Case (Arbeitsplanung erstellen bzw. Arbeitsaufträge bearbeiten) zum eingebundenen Use Case (Priorisieren bzw. Rückmeldung geben).
• Kein Use Case ist ohne Verbindung.

⚠️ Vorhanden, aber falsch

• Die Pfeilspitzen an den «include»-Linien sind kaum bzw. beim Pfeil zu „Priorisieren“ nicht eindeutig erkennbar. Am eingebundenen Use Case muss jeweils eine deutliche offene Pfeilspitze stehen.
• Kleinigkeit: Der Name „Priorisieren der Arbeitsaufträge“ folgt nicht dem Muster Objekt + Verb. Besser wäre „Arbeitsaufträge priorisieren“.

✅ Sehr gute Lösung: Alle Anforderungen sind abgebildet, und die «include»-Beziehungen sind korrekt gerichtet. Achte als Nächstes darauf, keine Akteur-Generalisierungen zu modellieren, die die Aufgabe nicht hergibt, und Assoziationen als einfache Linien ohne Pfeil zu zeichnen.

Geschätzt in der Prüfung: fast alle Punkte

✅ Korrekt

• Systemgrenze als Rechteck mit Bezeichnung „Störungsmanagement“ vorhanden
• Akteure Kunde, IT-Abteilung und Serviceteam benannt und außerhalb der Systemgrenze platziert
• Use Cases als Ellipsen, sinnvoll nach Objekt + Verb benannt (z. B. „Störungsmeldung senden“, „Arbeitsplanung erstellen“)
• Kunde mit „Störungsmeldung senden“ verbunden
• IT-Abteilung mit „Störungsmeldungen erfassen“ und „Arbeitsplanung erstellen“ verbunden
• «include» von „Arbeitsplanung erstellen“ zu „Aufgaben priorisieren“: gestrichelt, richtige Pfeilrichtung, passend zu „beinhaltet immer“
• Serviceteam mit „Arbeitsaufträge bearbeiten“ verbunden
• «include» von „Arbeitsaufträge bearbeiten“ zu „Rückmeldung senden“: gestrichelt, richtige Pfeilrichtung
• Kein Use Case ohne Verbindung

❌ Fehlt

• Der Zeitpunkt „freitags, für die kommende Woche“ ist nicht dargestellt; optional als Notiz an „Arbeitsplanung erstellen“ möglich, in Use-Case-Diagrammen aber nicht zwingend

⚠️ Vorhanden, aber falsch

• Generalisierung Serviceteam → IT-Abteilung ist durch die Aufgabe nicht gedeckt. Sie bedeutet, dass das Serviceteam auch Störungsmeldungen erfasst und die Arbeitsplanung erstellt. Besser: Generalisierung weglassen und das Serviceteam als eigenständigen Akteur modellieren.
• Verbindung „Rückmeldung senden“ – Kunde ist mit Pfeilspitze gezeichnet. Assoziationen zwischen Akteur und Use Case sollten als einfache Linie ohne Pfeil dargestellt werden.

🟡 Inhaltlich hast du alle Anforderungen erfasst, und die «include»-Beziehungen sind korrekt gesetzt – gute Arbeit! Achte als Nächstes darauf, Akteure und Use Cases nur mit einfachen Linien ohne Pfeilspitzen zu verbinden und keine prozessartigen Fluss-Linien einzuzeichnen.

Geschätzt in der Prüfung: etwa drei Viertel der Punkte

✅ Korrekt

• Alle drei Akteure (Kunde, IT-Abteilungs-Mitarbeiter, Service-Team-Mitarbeiter) sind benannt und außerhalb der Systemgrenze platziert
• Systemgrenze ist vorhanden und mit „Serviceprogramm“ beschriftet
• Alle geforderten Use Cases sind vorhanden: Störungsmeldung senden, Störungsmeldung erfassen, Arbeitsplan erstellen, Aufträge priorisieren, Aufträge bearbeiten, Rückmeldung schicken
• Die Use Cases sind als Ellipsen gezeichnet und nach dem Muster Objekt + Verb benannt
• Die Akteure sind fachlich richtig zugeordnet: Kunde zu Senden, IT zu Erfassen und Arbeitsplan, Serviceteam zu Bearbeiten
• «include» von „Arbeitsplan erstellen“ zu „Aufträge priorisieren“ ist gestrichelt und hat die richtige Richtung
• «include» von „Aufträge bearbeiten“ zu „Rückmeldung schicken“ ist gestrichelt und hat die richtige Richtung

⚠️ Vorhanden, aber falsch

• Die Assoziationen zwischen Akteuren und Use Cases haben Pfeilspitzen. Richtig wäre eine einfache Linie ohne Pfeil.
• Von „Störungsmeldung senden“ führt eine Linie mit Pfeil aus der Systemgrenze hinaus in Richtung IT-Mitarbeiter. Das wirkt wie ein Datenfluss und ist keine Use-Case-Notation; diese Linie sollte entfallen.
• Die Linie von „Rückmeldung schicken“ endet ohne Akteur an der Systemgrenze. Entweder wird sie sauber mit dem Kunden verbunden (falls er die Rückmeldung erhält) oder sie entfällt.

✅ Sehr saubere Lösung: Alle Anforderungen sind abgedeckt und die «include»-Notation stimmt. Achte als Nächstes darauf, eingebundene Use Cases nicht zusätzlich direkt mit dem Akteur zu verbinden.

Geschätzt in der Prüfung: fast alle Punkte

✅ Korrekt

• Systemgrenze als Rechteck gezeichnet und mit „OptiSoft“ beschriftet
• Alle drei Akteure (Kunde, IT-Abteilung, Serviceteam) benannt und außerhalb der Systemgrenze platziert
• Alle geforderten Use Cases als Ellipsen vorhanden und nach dem Muster Objekt + Verb benannt: Störungsmeldung senden, Störungsmeldung erfassen, Arbeitsplanung erstellen, Priorisierung vornehmen, Arbeitsaufträge bearbeiten, Rückmeldung geben
• Assoziationen als einfache Linien und fachlich richtig zugeordnet: Kunde – Störungsmeldung senden, IT-Abteilung – Störungsmeldung erfassen und Arbeitsplanung erstellen, Serviceteam – Arbeitsaufträge bearbeiten
• „Beinhaltet immer“ korrekt als «include» umgesetzt: gestrichelt, mit offener Pfeilspitze und richtig gerichtet vom Basis-Use-Case zum eingebundenen Use Case (Arbeitsplanung erstellen → Priorisierung vornehmen, Arbeitsaufträge bearbeiten → Rückmeldung geben)
• Kein Use Case ohne Verbindung

⚠️ Vorhanden, aber falsch

• Zusätzliche direkte Assoziation Serviceteam – Rückmeldung geben ist überflüssig, da „Rückmeldung geben“ bereits per «include» in „Arbeitsaufträge bearbeiten“ eingebunden ist. Diese Linie besser weglassen, damit der Use Case nicht als eigenständig auslösbar erscheint.

❌ Die Akteure und die groben Anwendungsfälle hast du richtig erkannt, aber das Diagramm liest sich eher wie ein Ablauf als wie ein Use-Case-Diagramm. Übe als Nächstes die Systemgrenze, ungerichtete Assoziationen und vor allem «include»-Beziehungen für Schritte, die „immer“ stattfinden.

Geschätzt in der Prüfung: etwa ein Viertel der Punkte

✅ Korrekt

• Alle drei Akteure (Kunde, IT-Abteilung, Service Team) sind vorhanden, benannt und als Strichmännchen dargestellt.
• Use Cases sind als Ellipsen gezeichnet.
• Die Anwendungsfälle zum Senden der Störung, zur Arbeitsplanung, zur Bearbeitung der Arbeitsaufträge und zur Rückmeldung sind inhaltlich erkannt.
• Die Use Cases sind überwiegend den passenden Akteuren zugeordnet (Kunde → Störung senden, IT-Abteilung → Arbeitsplan, Service Team → Aufträge bearbeiten).

❌ Fehlt

• Systemgrenze als beschriftetes Rechteck (z. B. „Störungsmanagement OptiSoft-XXL“), die Akteure stehen außerhalb davon.
• Use Case „Störungsmeldung erfassen“ für die IT-Abteilung fehlt.
• «include»-Beziehung von „Arbeitsplanung erstellen“ zu „Aufträge priorisieren“ fehlt, obwohl die Priorisierung laut Aufgabe immer stattfindet.
• «include»-Beziehung von „Arbeitsauftrag bearbeiten“ zu „Rückmeldung geben“ fehlt, obwohl die Rückmeldung laut Aufgabe immer dazugehört.
• Der zeitliche Auslöser „freitags“ ist nicht berücksichtigt, z. B. als Notiz oder Zeit-Akteur.

⚠️ Vorhanden, aber falsch

• Die Assoziationen zwischen Akteur und Use Case sind als Pfeile mit Pfeilspitze bzw. als Ablaufpfeile gezeichnet (z. B. „sendet Störung“ → IT-Abteilung). Richtig sind einfache, ungerichtete Linien; ein Use-Case-Diagramm zeigt keinen Ablauf oder Datenfluss.
• „erstellt Arbeitsplan und priorisiert“ fasst zwei Anwendungsfälle in einer Ellipse zusammen. Richtig sind zwei getrennte Use Cases, die über «include» verbunden sind (gestrichelt, offene Pfeilspitze, vom Basis-Use-Case zum eingebundenen).
• „gibt Rückmeldung“ ist direkt mit dem Service Team assoziiert und mit einem Pfeil zum Kunden verbunden. Richtig ist ein eigener Use Case, der per «include» von „Arbeitsauftrag bearbeiten“ eingebunden wird.
• Die Benennung erfolgt als Satz in der 3. Person (z. B. „sendet Störung“). Üblich ist Objekt + Verb im Infinitiv, z. B. „Störungsmeldung senden“, „Arbeitsauftrag bearbeiten“.

🟡 Die Struktur des Diagramms passt gut zur Aufgabe, und die include-Beziehung zur Priorisierung ist sauber gezeichnet. Achte als Nächstes darauf, jede gestrichelte Beziehung mit ihrem Stereotyp zu beschriften, die Systemgrenze zu benennen und alle Use Cases konsequent nach dem Muster Objekt + Verb zu formulieren.

Geschätzt in der Prüfung: etwa drei Viertel der Punkte

✅ Korrekt

• Drei Akteure (Kunde, IT-Abteilung, Serviceteam) benannt und außerhalb der Systemgrenze
• Use Cases als Ellipsen innerhalb der Systemgrenze
• Kunde mit „Störungsmeldung melden“ über einfache Linie verbunden
• IT-Abteilung mit „Störungsmeldung erfassen“ und „Arbeitsplanung erstellen“ verbunden
• «include» von „Arbeitsplanung erstellen“ zu „Priorisierung“ gestrichelt mit offener Pfeilspitze in korrekter Richtung
• Serviceteam mit „Arbeitsaufträge bearbeiten“ verbunden
• Beziehung zu „Rückmeldung“ gestrichelt und in richtiger Richtung vom Basis-Use-Case zum eingebundenen Use Case
• Kein Use Case ohne Verbindung

❌ Fehlt

• Stereotyp «include» an der gestrichelten Linie von „Arbeitsaufträge bearbeiten“ zu „Rückmeldung“
• Beschriftung der Systemgrenze mit dem Systemnamen, z. B. „Störungsmanagement OptiSoft-XXL“

⚠️ Vorhanden, aber falsch

• „Priorisierung“ entspricht nicht dem Muster Objekt + Verb, besser z. B. „Aufträge priorisieren“
• „Rückmeldung“ entspricht nicht dem Muster Objekt + Verb, besser z. B. „Rückmeldung geben“
• „Störungsmeldung melden“ ist doppelt formuliert, passender wäre „Störungsmeldung senden“ (Kleinigkeit)

❌ Die Akteure und die fachlichen Schritte hast du gut herausgearbeitet, aber gezeichnet ist ein Ablaufdiagramm statt eines Use-Case-Diagramms. Übe die Grundnotation: Systemgrenze, Ellipsen, einfache Assoziationslinien und vor allem «include» für Schritte, die „immer“ stattfinden (hier Priorisierung und Rückmeldung).

Geschätzt in der Prüfung: kaum Punkte

✅ Korrekt

• Die drei Akteure Kunde, IT-Abteilung und Serviceteam sind erkannt, benannt und als Strichmännchen dargestellt.
• Wichtige Prozessschritte sind inhaltlich erkannt: Störungsmeldung senden, Arbeitsplan erstellen, Arbeitsaufträge, Rückmeldung an Kunden.
• Die Akteure sind den Schritten grob passend zugeordnet (Kunde – Senden, IT – Arbeitsplan, Serviceteam – Rückmeldung).

❌ Fehlt

• Systemgrenze als beschriftetes Rechteck (z. B. „Störungsmanagement“), mit allen Akteuren außerhalb.
• Use Case „Störungsmeldung erfassen“ für die IT-Abteilung.
• Use Case „Priorisierung durchführen“ mit «include» von „Arbeitsplanung erstellen“, da die Priorisierung immer stattfindet.
• Use Case „Arbeitsauftrag bearbeiten“ für das Serviceteam mit «include» zu „Rückmeldung geben“, da die Rückmeldung immer stattfindet.
• «include»-Beziehungen fehlen vollständig (gestrichelter Pfeil mit offener Spitze vom Basis- zum eingebundenen Use Case).

⚠️ Vorhanden, aber falsch

• Diagrammtyp: Die Lösung ist ein Ablauf-/Flussdiagramm und kein Use-Case-Diagramm. Use-Case-Diagramme zeigen keine zeitliche Reihenfolge der Schritte.
• Use Cases sind als Rechtecke gezeichnet. Richtig sind Ellipsen.
• Verbindungen sind gerichtete Pfeile, die einen Ablauf darstellen. Assoziationen zwischen Akteur und Use Case sind einfache Linien ohne Pfeilspitze; Use Cases werden nicht untereinander durch Ablaufpfeile verkettet.
• Benennung nicht durchgängig nach dem Muster Objekt + Verb: „Arbeitsaufträge“ ist kein Anwendungsfall (richtig: „Arbeitsauftrag bearbeiten“), „Erstellt Arbeitsplan“ sollte „Arbeitsplanung erstellen“ heißen, „Rückmeldung an Kunden“ sollte „Rückmeldung geben“ heißen.
• Die IT-Abteilung ist als Empfänger eines Pfeils von „Senden Störmeldungen“ modelliert. Richtig wäre eine eigene Assoziation zum Use Case „Störungsmeldung erfassen“.

🟡 Die «include»-Beziehungen und die Akteure sind sauber umgesetzt. Ergänze den fehlenden Use Case „Störungsmeldung erfassen“, beschrifte die Systemgrenze und zeichne Assoziationen ohne Pfeilspitzen.

Geschätzt in der Prüfung: etwa zwei Drittel der Punkte

✅ Korrekt

• Drei Akteure (Kunde, IT-Abteilung, Serviceteam) benannt und außerhalb der Systemgrenze
• Systemgrenze als Rechteck vorhanden
• Use Cases als Ellipsen, überwiegend nach dem Muster Objekt + Verb benannt
• Kunde über einfache Linie mit „Störmeldungen senden“ verbunden
• IT-Abteilung mit „Arbeitsplanung erstellen“ verbunden
• «include» von „Arbeitsplanung erstellen“ zu „Arbeit priorisieren“ gestrichelt mit offener Pfeilspitze in korrekter Richtung
• Serviceteam mit „Arbeitsauftrag bearbeiten“ verbunden
• «include» von „Arbeitsauftrag bearbeiten“ zu „Rückmeldung senden“ korrekt gezeichnet

❌ Fehlt

• Use Case „Störungsmeldung erfassen“ fehlt (wurde durchgestrichen); er muss als eigene Ellipse mit Assoziation zur IT-Abteilung modelliert werden
• Beschriftung der Systemgrenze fehlt (z. B. „Störungsmanagement OptiSoft-XXL“)

⚠️ Vorhanden, aber falsch

• Assoziation zwischen „Störmeldungen senden“ und IT-Abteilung hat eine Pfeilspitze; Assoziationen zwischen Akteur und Use Case sind einfache Linien ohne Pfeil
• IT-Abteilung ist dadurch fachlich am Senden beteiligt; richtig wäre eine Verbindung zur IT-Abteilung nur über „Störungsmeldung erfassen“
• Generalisierung Serviceteam → IT-Abteilung ist aus der Aufgabe nicht ableitbar: Das Serviceteam würde damit alle Use Cases der IT-Abteilung erben (z. B. Arbeitsplanung erstellen); besser weglassen und Akteure getrennt modellieren