3. IDEENFINDUNG

1. Use Cases → Beschreiben detailliert die Funktionalität eines Systems.

2. User Stories → Kleine, agile Beschreibungen von Nutzeranforderungen.

3. Kontextszenarien → Narrative Darstellung der Nutzungssituation aus Sicht des Nutzers.

1. Grenzen eines Systems definieren und mögliche Fehlerquellen früh erkennen.

2. Zu zeigen, wie das System auf Nutzerziele reagiert.

3. Zu helfen, Berührungspunkte mit anderen Systemen (z. B. Bezahlsysteme) zu erkennen.

• Sie sind kurze Beschreibungen von Anforderungen für agile Entwicklung.

• Helfen, den Arbeitsaufwand pro Iteration abzuschätzen.

• Simpler als Use Cases, da sie nur eine kleine Funktion oder Aufgabe beschreiben.

• Beschreiben die Nutzungssituation aus der Perspektive des Nutzers.

• Können Details zur Benutzeroberfläche enthalten.

• Enge Verbindung zu Personas, da sie Handlungsmotivationen widerspiegeln.

• Werden oft für Storyboards genutzt, um Nutzungsszenarien visuell darzustellen.

Eine Methode zur Beschreibung von Benutzeranforderungen in einfacher Sprache.

• Beschreibt eine bestimmte Handlung für einen bestimmten Nutzer (Akteur).

• Wird als Text oder Diagramm dargestellt.

Dokumentiert alle wichtigen Nutzungsszenarien eines Systems.

• Hilft Entwicklern und Auftraggebern, Anforderungen zu verstehen.

• Erkennt frühzeitig mögliche Fehlerquellen in der Interaktion.

1. Primärer Akteur: Wer benutzt das System?

2. Ziel: Was soll erreicht werden?

3. Stakeholder: Wer ist betroffen, welche Interessen gibt es?

4. Vorbedingungen: Was muss vorher erfüllt sein?

5. Erfolgsgarantien: Wann gilt der Vorgang als erfolgreich?

6. Szenario: Ablauf der Interaktion in Schritten.

7. Erweiterungen: Was passiert bei Abweichungen oder Problemen?

Business Use Cases: Beschreiben die Arbeitsweise eines Unternehmens.

System Use Cases: Beschreiben das Verhalten eines (Software-)Systems oder einzelner Komponente

Je nach Projekt kann ein Use Case detailliert oder nur grob beschrieben werden.

• Iteratives Vorgehen ist sinnvoll: zuerst einfach, später detaillierter ausformulieren.

• Direkte Nutzer (Personen).

• Technische Geräte oder Softwarekomponenten.

• Andere Stakeholder mit Interesse am Systemverhalten.

Auch stille Stakeholder (z. B. indirekt betroffene Personen) haben Interessen.

• Stakeholder helfen, alle wichtigen Systemanforderungen frühzeitig zu erfas

• Anfangsphase: Definieren die Ziele des Systems.

• Projektabschluss: Wichtig für Rollenzuweisung und Schulungen.

• Spätere Entwicklungsphasen: Treten in den Hintergrund, da Fokus auf Systemfunktionen liegt

1. Unternehmensebene: Verhalten des gesamten Unternehmens.

2. Systemebene: Verhalten des zu entwickelnden Produkts.

3. Subsystemebene: Verhalten einzelner Teile des Systems.

• Black Box: Nur das Ergebnis ist sichtbar, nicht die Funktionsweise.

  
  

• White Box: Interne Abläufe sind sichtbar (z. B. wie Abteilungen zusammenarbeiten).

Voraussetzungen, die erfüllt sein müssen, bevor der Use Case startet.

• Beispiel: Ein erfolgreicher Login ist nötig, bevor ein Kauf getätigt werden kann.

Erfolgsgarantie: Bedingungen für den erfolgreichen Abschluss (z. B. Geld wird korrekt ausgezahlt).

Minimale Garantie: Was passiert, wenn der Use Case fehlschlägt (z. B. Transaktionslog als Absicherung).

Die Schritte einer erfolgreichen Interaktion mit dem System.

• Beispiel Geldabhebung: PIN eingeben → Überprüfung durch Automaten → Geld wird ausgezahlt.

Alternativen oder Fehlerfälle, die vom Haupterfolgsszenario abweichen.

• Beispiel: Paketlieferung → Empfänger nicht da → Paket wird bei Nachbarn abgegeben oder Retoure.

1. Fully Dressed (ausführlich): Detaillierte Schritte, Erweiterungen nummeriert.

2. Informell: Kurzer Erzähltext mit Haupterfolgsszenario und Erweiterungen.

3. Konversationsformat: Dialog zwischen Akteur und System in zwei Spalten.

1. In-Out-Liste: Festlegen, welche Funktionen im System enthalten sind.

2. Akteur-Ziel-Liste: Definieren, welche Akteure welche Ziele verfolgen.

3. Use Case Briefs: Kurze Beschreibung von Interaktionen und Zielen.

4. Use-Case-Spezifikation: Detaillierte Dokumentation aller Abläufe.

5. Use-Case-Diagramm (optional): Grafische Darstellung der Zusammenhänge

Sie trennt Funktionen, die im System enthalten sind („in“), von denen, die nicht dazugehören („out“).

• Beispiel: Ein Webshop kann Produkte anzeigen („in“), hat aber keinen Einfluss auf externe Bezahlsysteme („out“).

Sie enthält alle beteiligten Akteure und ihre Ziele.

-> Hilft, Prioritäten für die Entwicklung zu setzen.

Use Case Briefs: Kurzfassung der Interaktionen und Ziele, nützlich für kleinere Projekte.

Use-Case-Spezifikationen: Detaillierte Beschreibung für große Projekte mit komplexen Abläufen.

Sie visualisieren Beziehungen zwischen Use Cases.

• helfen, eine objektorientierte Struktur zu entwickeln.

• Cockburn empfiehlt eher Kontextdiagramme als detaillierte UML-Use-Case-Diagramme.

Use Cases beinhalten immer ein Haupterfolgsszenario , in dem der ideale Ablauf der Interaktion mit dem System beschrieben ist, sowie diverse Erweiterungen, in denen alternative Handlungsabläufe oder mögliche Probleme beschrieben werden. Letztere beziehen sich auf Ersteres durch ein Nummerierungssystem.

1. mithilfe einer In-Out-Liste wird definiert, welche Funktionen überhaupt Teil des zu gestaltenden Systems sein sollen.

2.Anhand einer Liste werden die Akteure und ihre Ziele versammelt, die das System betrifft, und priorisiert.

3. Es werden für die wichtigsten Akteure Use Case Briefs formuliert, die die Interaktion für jedes Ziel jeweils in wenigen Sätzen schildern.

4. Werden nach Bedarf als vollumfängliche Use-Case-Spezifikationen ausformuliert.

Eine Methode zur Dokumentation von Benutzeranforderungen.

-> Wird vor allem in agilen Softwareentwicklungsprozessen genutzt.

-> Beschreibt, was ein Nutzer braucht, ohne technische Details.

• User Stories sind kürzer und fokussieren sich auf einzelne Anforderungen.

• Sie haben einen ähnlichen Arbeitsaufwand und sind innerhalb eines Sprints umsetzbar.

• Werden flexibel angepasst und nicht von Anfang an vollständig dokumentiert.

1. Story Card: Enthält eine prägnante Beschreibung der Anforderung.

   • Beispiel: „Als [Nutzer] möchte ich [Ziel], damit [Nutzen]“

     
     

2. Akzeptanzkriterien: Definieren, wann die Story erfolgreich umgesetzt ist.

   
   

3. Konversationen: Diskussionen im Team, um Details zu klären.

Sie definieren, wann eine User Story als fertig gilt.

• Sie helfen Entwicklern, das Ziel der Story zu verstehen.

• Sie dienen als Grundlage für Tests, um die Umsetzung zu überprüfen.

User Stories sind oft kurz und dienen nur als Gedächtnisstütze.

-> Teams klären Details durch Gespräche, statt lange Dokumente zu schreiben.

• Erleichtert schnelle Anpassungen an neue Anforderungen.

Ein erstes funktionsfähiges Produkt mit nur den wichtigsten Features.

• Ziel: Schnelles Kundenfeedback erhalten und das Produkt verbessern.

Sie lösen Probleme des traditionellen Wasserfallmodells, das unflexibel ist.

• Anforderungen ändern sich oft während eines Projekts.

• Agile Methoden ermöglichen schnellere Anpassungen und flexiblere Entwicklung.

Ein fester Zeitraum (meist 2–4 Wochen) für die Umsetzung bestimmter Aufgaben.

• Ziel: Schnelle, nutzbare Versionen eines Produkts entwickeln.

• Arbeitsaufwand wird an den verfügbaren Sprint-Zeitraum angepasst.

Die kleinste inhaltliche Aufgabe in einem agilen Projekt.

• Sie beschreibt eine Funktion aus Sicht des Nutzers.

• Beispiel: „Als [Nutzer] möchte ich [Ziel], um [Nutzen].“

Eine Liste aller User Stories, die für das Projekt benötigt werden.

• Wird vom Product Owner verwaltet.

• Die User Stories werden nach Priorität geordnet.

Eine Einheit zur Aufwandsschätzung von User Stories.

• Erleichtert die Planung von Sprints.

• Beispiel: Ein Sprint kann z. B. 15 Story Points umfassen.

• Product Owner: Erstellt und verwaltet die User Stories.

• Entwicklungsteam: Setzt sie um.

• Scrum Master: Koordiniert den Prozess.

1. Immediately actionable – Sofort umsetzbar.

2. Negotiable – Anpassbar und flexibel.

3. Valuable – Bringt dem Nutzer einen Mehrwert.

4. Estimable – Aufwand gut abschätzbar.

5. Short – Kurz und präzise.

6. Testable – Ergebnis muss überprüfbar sein.

Eine visuelle Darstellung aller User Stories entlang eines chronologischen Bedienprozesses.

• Zeigt den Gesamtzusammenhang eines Systems.

• Hilft, die Interaktionen der Nutzer mit dem System zu verstehen.

Eine zeitliche Darstellung aller Aktivitäten von Anfang bis Ende.

• Enthält alle wichtigen Nutzeraktionen und Systemprozesse.

• Wird auf einer horizontalen Achse angeordnet.

• Einzelne Handlungsschritte innerhalb einer Aktivität.

• Oben platzierte Tasks sind wichtiger als unten platzierte.

• Dienen dazu, Unstimmigkeiten frühzeitig zu erkennen.

Teilen die Story Map in verschiedene Entwicklungsphasen.

• Obere Swim Lane: Enthält das Minimum Viable Product (MVP) mit den wichtigsten Funktionen.

• Weitere Swim Lanes enthalten zusätzliche Funktionen für spätere Releases.

Helfen, reale Nutzer und ihre Bedürfnisse besser zu verstehen.

• Verhindern, dass Anforderungen nur aus Systemsicht formuliert werden.

• Unterstützen die Priorisierung der User Stories für das MVP.

Bildsequenzen mit Erklärungen, die einen Handlungsablauf zeigen.

• Ursprünglich aus der Filmindustrie, heute in UX-Design verwendet.

• Helfen, Nutzungsszenarien zu visualisieren und Konzepte zu testen.

Erleichtern die Kommunikation neuer Ideen an Stakeholder.

• Erkennen von Fehlern oder Lücken in Nutzungsszenarien.

• Unterstützen die Entwicklung von Interface-Konzepten.

Beschreiben die Nutzung aus Sicht einer Persona.

• Zeigen Motivation, Ziele und den Kontext der Nutzung.

• Liefern eine gute Basis für die Gestaltung von Storyboards.

1. Narrative Szenarien: Geschichtliche Darstellung von Abläufen.

2. Use Case Szenarien: Formale Beschreibung von Systemprozessen.

3. Schlüsselpfadszenarien: Detaillierte Interaktionen mit dem System.

• Storyboards visualisieren Abläufe mit Bildern und sind leichter verständlich.

• Texte allein reichen oft nicht aus, um komplexe Prozesse zu erklären.

• Storyboards helfen, Innovationen anschaulich zu präsentieren.

Zeigt Abläufe und Interaktionen mit einem Produkt oder Service.

• Erklärt Nutzererfahrungen in visueller Form.

• Hilft Entwicklern und Stakeholdern, Nutzerbedürfnisse besser zu verstehen.

Erzählt eine Geschichte mit Bildern.

• Zeigt nicht nur Abläufe, sondern auch Emotionen der Nutzer.

• Wird auf Basis von Personas und Kontextszenarien erstellt.

Dient dazu, eine Reihe an User Stories für ein zu entwickelndes System in einen chronologischen Zusammenhang zu bringen.

• Hierdurch wird die Rolle einzelner User Stories bei der Interaktion mit dem System sichtbar.

• Anhand der User Story Map können die Rollen einzelner Akteure dargestellt und Releases geplant werden.

Eine User Story besteht aus den folgenden drei Komponenten: einer Story Card, Akzeptanzkriterien und Konversationen.

Eine gute User Story beinhaltet Informationen zu folgenden drei Aspekten: einem Akteur, einem Ziel und dem Mehrwert, den das Ziel für den Akteur hat.

Narrative Storyboards:

stellen den gesamten Anwendungskontext für ein System dar.

-> Sie zeigen die Benutzerschnittstelle innerhalb dieses Zusammenhangs.

Sequenzielle Storyboards:

stellen in erster Linie die Benutzerschnittstelle dar

-> und illustrieren darin die einzelnen Zustände und Übergänge zwischen ihnen.

Storyboards sind illustrierende Bildsequenzen, die einen Handlungsablauf darstellen.

Für Eröffnungsszenen ist eine Weitwinkelaufnahme angemessen, um den Anwendungskontext ausreichend erkennbar darstellen zu können.

Einzelne Einstellungen in einem narrativen Storyboard sollten mit Annotationen und Pfeilen versehen werden, um Bewegung und Übergänge zu visualisieren.

1. Storyline entwickeln (Problem, beteiligte Personen, Lösung).

2. Schlüsselszenen definieren (5–8 Bilder pro Ablauf).

3. Skizzen anfertigen mit einfachen Zeichnungen oder Fotos.

4. Kameraeinstellungen beachten (Weitwinkel, Nahaufnahme etc.).

5. Annotationen hinzufügen (Bewegungen, Emotionen, Interface-Änderungen)

• Weitwinkelaufnahme: Überblick über die gesamte Szene.

• Totale: Zeigt eine oder mehrere Personen.

• Nahaufnahme: Fokus auf Emotionen oder Details.

• Über-die-Schulter: Zeigt Interface und Umgebung aus Sicht des Nutzers.

• Detailaufnahme: Hebt kleine Objekte oder Interface-Elemente hervor.

• Zeigt, wie sich das User Interface Schritt für Schritt verändert.

• Beschreibt Übergänge zwischen verschiedenen Zuständen.

• Enthält oft Annotationen zu Aktionen und Veränderungen.

1. Sequenzielles Storyboard: Zeigt Interface-Zustände nacheinander.

2. State Transition Diagram: Zeigt Zustände und mögliche Übergänge.

3. Branching Storyboard: Zeigt Entscheidungspfade und alternative Abläufe.