Kundenanforderungen greifbar machen

Eine Software-Idee greifbar zu machen und in klare Anweisungen für Entwickler umzuwandeln, ist eine anspruchsvolle Aufgabe. Allerdings erscheint sie zu Anfang oft gar nicht komplex und Projektverantwortliche neigen dazu, diesen Schritt nur minimal oder gar nicht durchzuführen. Und ja, manchmal funktioniert das. Bei kleinen und überschaubaren Projekten.

Bei größeren, anspruchsvollen, kritischen und nachhaltigen Projekten wird es problematisch. Im besten Fall schlägt Pareto zu: die ersten 80% laufen wie von alleine. Dann kommen die letzten 20% und die haben‘s in sich: Verwirrung, Budget-Überschreitungen, verpasste Meilensteine und Liefertermine und ein unglücklicher Kunde. Im Worst Case erreicht man nicht mal die 80%-Schwelle.

Das müssen wir vermeiden. Und auch wenn klar ist, dass es keine hundertprozentige Perfektion gibt… eine Verbesserung und Optimierung gibt es allemal.

Es gibt viele Ansätze und ganze Studien zum Thema. Aber es gibt auch Wege, die ein akzeptables Aufwand/Benefit-Verhältnis haben. Einer davon: Use Cases. Im Einsatz seit den 90er-Jahren, geliebt und verschmäht zugleich, gehören sie (eigentlich) zum Repertoire eines jeden Informatikers.

Und das Beste: Use Cases lassen sich ziemlich einfach in User Storys umwandeln und in agilen Vorgehensmodellen weiter nutzen.

Was ist UML?

UML (Unified Modeling Language) ist eine standardisierte visuelle Modellierungssprache, die in der Softwareentwicklung verwendet wird, um Struktur, Verhalten und Interaktionen eines Systems zu beschreiben.

UML definiert eine Vielzahl von Diagrammtypen:

• Klassendiagramm
• Anwendungsfalldiagramm
• Sequenzdiagramm
• uvm.

Diese helfen dabei, komplexe Systeme zu entwerfen, zu analysieren und zu dokumentieren.

Use Case Diagram / Anwendungsfalldiagramm

Sicher hast Du irgendwo bereits einen modellierten Anwendungsfall gesehen.

Dies ist die gebräuchlichste grafische (und eine sehr einfache) Darstellung von den Möglichkeiten eines Software-Systems. Aber da sie sowohl für Laien als auch Profis gut zu erfassen ist und somit als Grundlage für Abstimmungen dienen kann, ist sie gut geeignet für den Einstieg in die Modellierung von Anforderungen.

Was sehen wir also in diesem Diagramm?

Use Case / Anwendungsfall

Ein Use Case zeigt eine Interaktion zwischen einem Benutzer und einem System. Der Benutzer möchte ein bestimmtes Ziel zu erreichen, der Use Case beschreibt die Schritte und Szenarien, die dafür erforderlich sind.

Actor / Akteur

Immer, wenn wir über Anforderungen an ein System sprechen, erkennen wir eine oder mehrere Personen oder Dinge, die ein Interesse am Verhalten dieses Systems haben. Diese werden „Stakeholder“ genannt.

Im Use Case Diagramm treten sie als Akteure auf, die mit dem System interagieren und Use Cases auslösen. Auch andere System können Akteure sein.

Die Linie, die einen Akteur mit einem Use Case verbindet nennt man Assoziation. Sie zeigt an, dass der Akteur in irgendeiner Weise mit dem Use Case interagiert oder an ihm beteiligt ist.

Mit diesen Elementen lässt sich bereits viel darstellen. Dennoch reicht dies meist nicht aus. Um Beziehungen zwischen Uses Cases zu zeigen, werden „include“ und „extend“ verwendet.

Include / Inklusion

Eine Inklusion (oder Include-Beziehung) beschreibt eine Beziehung, in der ein Use Case das Verhalten eines anderen Use Cases explizit einbezieht oder wiederverwendet. Dies wird genutzt, um gemeinsame Funktionalitäten zu modularisieren und wiederzuverwenden, wodurch Redundanzen in der Modellierung vermieden werden.

In der Darstellung zeigt eine gestrichelte Pfeillinie von dem ursprünglichen Use Case auf den eingebundenen Use Case.

Extend / Erweiterung

Eine Erweiterung (oder Extend-Beziehung) beschreibt eine Beziehung, bei der ein Use Case das Verhalten eines anderen Use Cases unter bestimmten Bedingungen erweitert oder ergänzt. Dies ermöglicht es, optionale oder bedingte Funktionalitäten darzustellen, die nur unter speziellen Umständen ausgeführt werden.

Eine gestrichelte Pfeillinie mit einem «extend»-Stereotyp zeigt vom erweiterten Use Case auf den Basis-Use Case.

System boundary / Systemgrenzen

Systemgrenzen in einem Use Case Diagramm definieren das betrachtete System oder Teilsystem, indem sie klar festlegen, welche Funktionen und Interaktionen Teil des Systems/Teilsystems sind und welche nicht.

Diese Grenzen werden durch ein Rechteck dargestellt, das die Use Cases und Akteure innerhalb des Systems einschließt.

Oft gibt es Gemeinsamkeiten bzw. Unterschiede zwischen Anwendungsfällen (Use Cases) oder Akteuren (Actors), die man darstellen möchte.

Mittels s.g. Generalisierung und Spezialisierung wird dargestellt, wie Funktionalitäten strukturiert und wiederverwendet werden sollen.

Generalisierung

Generalisierung beschreibt die Beziehung zwischen einem allgemeinen Element (Eltern-Element) und spezialisierteren Elementen (Kind-Elementen). Es ist eine „Ist-ein“-Beziehung, bei der das spezialisierte Element die Eigenschaften des allgemeinen Elements erbt und möglicherweise weitere spezialisierte Eigenschaften hinzufügt.

In UML Use-Case-Diagrammen kann Generalisierung sowohl zwischen Use Cases als auch zwischen Akteuren auftreten.

Generalisierung von Use Cases

• Eltern-Use-Case: Zahlung
• Kind-Use Cases: Bargeld-Zahlung, Kreditkarten-Zahlung

„Bargeld-Zahlung“ und „Kreditkarten-Zahlung“ sind eine Spezialisierung des allgemeinen Use Cases „Zahlung“. Beide spezialisierte Use Cases erben die Schritte des allgemeinen Use Cases und können zusätzliche Schritte oder Anpassungen haben.

Generalisierung von Akteuren

• Elternakteur: Mitarbeiter
• Kindakteure: Entwickler, Verkäufer

„Entwickler“ und „Verkäufer“ sind eine Spezialisierung von „Mitarbeiter“. Beide spezialisierte Akteure erben die Eigenschaften und Verhaltensweisen des allgemeinen Akteurs „Mitarbeiter“ und können zusätzlich spezifische Verhaltensweisen haben.

Spezialisierung

Spezialisierung ist das Gegenstück zur Generalisierung und beschreibt die Beziehung, bei der ein Element spezifische Eigenschaften und Verhaltensweisen eines allgemeineren Elements erweitert oder spezialisiert.

Es ist die Implementierung der Generalisierungsbeziehung - betrachtet „aus der anderen Richtung“.

Spezialisierung von Akteuren

• Allgemeiner Akteur: Benutzer
• Spezialisierter Akteur: Administrator

„Administrator“ spezialisiert den allgemeinen „Benutzer“, indem er zusätzliche Rechte und Aufgaben erhält, die normale Benutzer nicht haben.

Spezialisierung von Use Cases

• Allgemeiner Use Case: Bericht erstellen
• Spezialisierter Use Case: Verkaufsbericht erstellen

„Verkaufsbericht erstellen“ spezialisiert den allgemeinen Use Case „Bericht erstellen“, indem er spezifische Schritte und Daten für Verkaufsberichte hinzufügt.

Eine Generalisierungs- bzw. Spezialisierungsbeziehung wird durch eine Linie mit einem offenen, dreieckigen Pfeil dargestellt, der vom spezialisierten Element zum allgemeinen Element zeigt.