Mit einer Anforderung drückt ein Stakeholder einen aus seiner Sicht wichtigen Bedarf an einer Erweiterung oder Änderung des Software-Produktes aus. In der Analyse der Anforderung wollen Product-Owner, Business-Analysten und das cross-funktionale Team einen Einblick in das fachliche Problem bekommen und ein gemeinsames Verständnis über Ziele und Lösungen entwickeln. Wir machen uns auch Gedanken über die Auswirkungen der Umsetzung. Das Sammeln von relevanten Informationen (das Produktwissen) und das Einholen von Feedback aus den Fachabteilungen ist ein ganz wichtiger Teil der Analyse.

Ein Case ist das Ergebnis von Entscheidungen aus dem Backlog-Management agiler Software-Entwicklung.

In der Methode CARDS+ untersuchen wir jede Anforderung vom Groben (als Epic) ins Feine (als Case). Über den beiden schwebt noch die Zuordnung zum Aufgabenbereich (als Topic).

Motivation

Konkrete Anwendungsfälle, Sonderfälle und bekannte Fehlersituationen beschreiben wir mit dem Baustein Case. Es klingt möglicherweise paradox, aber wir wollen auch einen Case erfassen, für den es keine Lösung gibt. Denn wenn es gute Gründe gibt, einen Case nicht umzusetzen (z.B. zu teuer, tritt einmal im Jahr auf), ist die erfasste Situation trotzdem wichtiges Produktwissen und wert, aufgeschrieben zu werden.

ktip Ein Case darf nicht mit einem Usecase verwechselt werden. Ein Usecase hat unterschiedliche Bedeutungen. Die Praxis reicht von einem Usecase auf sehr hohem Niveau bis auf Ebene von UML-Diagrammen mit dem Ziel, die Software mit Usecases zu beschreiben. Ein Case hat jedoch große Ähnlichkeit mit der Idee der Slices aus der agilen Technik “Use Case 2.0”, das 2011 von  Ivar Jacobson, Ian Spence und Kurt Bittner in dem gleichnamigen eBook veröffentlicht wurde.

Ein Case wird wie eine Story im Product-Backlog in der Sprache der Nutzer geschrieben. Die Techniken und Methoden für die Erstellung einer Story, z.B. die Erzählmethode (englisch: story telling), kann ohne Einschränkungen auch für das Schreiben eines Case verwendet werden. Im Unterscheid zu einer Story hat ein Case keine Akzeptanzkriterien und auch keine weitere Ebene der Verfeinerung durch Aufgaben. Ein Case ist in sich abgeschlossen, testbar und im Normalfall klein genug, um in einem Sprint umgesetzt zu werden. Wie bei einer Story sollten wir bei der Beschreibung eines Case unbedingt das Prinzip INVEST berücksichtigen.

Die fachliche Lösung zeigt im wörtlichen Sinn nur die Essenzschritte, die in der Anwendung zum erforderlichen Ergebnis führt.

Bei der Beschreibung von Lösungen müssen wir ganz stark darauf achten, dass wir nur die “Essenz” der Lösung erfassen..

Die Gefahr ist, in (meist technisch motivierte) Details abzugleiten. Wir müssen in einem Case dem Entwickler nicht erklären, wie er Abläufe und Strukturen im Rahmen der Architektur realisieren soll. Das weiß ein Entwickler in den meisten Fällen besser! Aber auch Entwickler und Tester profitieren von der Beschreibung des Weges, der für den beschriebenen Case in der Software-Architektur notwendig ist. Sie erkennen in den Essenzschritten auf einen Blick betroffene Komponenten, sehen Abhängigkeiten.

Definition

Beschreibung

Der Baustein Case ist das Artefakt in unserer Systembeschreibung, mit dem wir die Ergebnisse der Analyse einer Anforderung sichern. Er gibt einem Vorgang, Anwendungsfall, Sonderfall oder einer bekannten und akzeptierten Fehlersituation einen eindeutigen Namen und enthält eine detaillierte Ausarbeitung der fachlichen Problemstellung. Er kann aber auch eine Situation sein, für die es keine Lösung gibt.

Ein Case wird aus Sicht des Nutzers geschrieben. Er benennt Dinge, die das zu System für den Nutzer tun soll. Das erleichtert vor allem die Kommunikation. Die Beschreibung ist für jeden im Team verständlich und drückt den Kundennutzen klar aus.

Aber eines ist ganz wichtig: Ein Case ist

  • kein technisches Umsetzungskonzept.
  • kein Änderungskonzept.
  • kein Teil des Benutzerhandbuches.
  • kein Teil des Betriebshandbuches.
  • kein Usecase im klassischen Sinn.
  • keine User-Story.

Struktur

Abschnitt Ausgangslage

Der Abschnitt beschreibt die Ausgangslage für

  • einen einzelnen Anwendungsfall,
  • einen bestimmten Sonderfall,
  • einen bekannten Fehlerfall oder
  • eine Situation ohne Lösung.

Der Leser wird in die Lage versetzt, die beschriebene Situation in der Anwendung herzustellen. Er bekommt Einblick in die Sicht des Nutzers.

Abschnitt Lösung

Der Abschnitt enthält die Idee der Lösung. Er muss sich bei der Ausarbeitung auch Fragen, was das Ergebnis für den Nutzer sein soll. Die Lösung muss soweit detailliert sein, dass Entwickler und Tester die Lösung in die technische Architektur einordnen können.

Die Essenzschritte werden nur soweit detailliert, wie es für das Verständnis der Lösung unbedingt notwendig ist. Im einzelnen Essenzschritt nutzen wir ein Service und/oder Event, um konkrete Hinweise auf die technische Umsetzung zu geben.