Methode
Motivation für den Einsatz
Anforderungen an ein System entstehen in den Fachabteilungen aus einem Bedarf, den die Nutzer eines IT-Systems haben oder aufgrund von Anpassung an eine veränderte Unternehmensstrategie oder Organisationsstruktur im Unternehmen. Der Baustein Case ist ein Artefakt in der Systembeschreibung, mit dem Autoren die einen Teil der Ergebnisse der Anforderungsanalyse sichern. Er gibt einem Anwendungsfall, einer besonderen Situation oder einem bekannten und akzeptierten Fehler einen eindeutigen Namen und enthält eine fachliche Beschreibung und — sobald die Fähigkeit realisiert wurde — die Essenzschritte der gewählten Lösung. Er gibt einer angeforderten Fähigkeit des Produktes einen eindeutigen Namen. Die Beschreibung der Ausgangslage im Baustein muss jeden Leser in die Lage versetzen, die Fähigkeit fachlich einzuordnen und zu verstehen. Der Verwendung der Begriffe aus dem Glossar hilft dabei. Der Baustein dokumentiert einen Anwendungsfall, eine besondere Situation oder einen bekannten akzeptierten Fehler in der Software.
Der Baustein Case stellt jedoch keine Dokumentation der Anforderung dar, sondern ist immer eine Projektion der Anforderung auf das Produkt.
Autoren sichern fachliches Wissen aus der Anforderungsanalyse. Später, zum Zeitpunt der Realisierung bekommt das Team einen guten Einblick in die Motivation der interessierten Parteien, allen voran der Nutzer. Leser finden Antworten auf die Frage, bei welcher konkreten Ausgangslage die Nutzer eine bestimmte Fähigkeit des Produktes verwenden. Das ist ein entscheidender Vorteil für das Team, die “beste” Lösung für die Nutzer zu finden.
Wissensmanagement richtig organisieren.
Zielgerichtet.
Agil.
Iterativ.
Prozesse
Projektmanagement
Der Produktverantwortliche hat mit dem Baustein Case die Möglichkeit, eine produktspezifische Fähigkeit vorläufig zu beschreiben. Der Auftraggeber legt fest, welche Anforderungen an das IT-System gestellt werden. Der Produktverantwortliche nutzt den Baustein, um eine wichtige Entscheidung des Auftraggebers für oder gegen die Realisierung einer angeforderten Fähigkeit nachhaltig zu dokumentieren. Ein guter Titel legt frühzeitig den Grundstein für eine gemeinsame Sprache von Auftraggeber, Produktverantwortlichen und dem Team.
Prozesse
Anforderungsanalyse
Der Baustein Case hilft dem Produktverantwortlichen bei der Sicherung der Ergebnisse der Anforderungsanalyse. Eine von Auftraggeber und interessierten Parteien akzeptierte Beschreibung einer konkreten Fähigkeit des Produktes stellt den dritten Schritt der Validierung einer Anforderung dar.
Anders als beim Baustein Epic geht es beim Baustein Case um die Identifizierung von Fähigkeiten der Software, mit denen die Anforderungen erfüllt werden können.
Die Techniken und Methoden für die Erstellung einer Story, z.B. die Erzählmethode (engl. story telling), kann ohne Einschränkungen auch für das Schreiben der Ausgangslage im Baustein Case verwendet werden. Der Baustein Case ist in sich geschlossen, testbar und im Normalfall klein genug, um in einer Iteration (z.B. Sprint bei Scrum) umgesetzt zu werden. Die Ausgangslage ist immer “lösungsoffen”. Wie bei einer Story sollten Autoren unbedingt das Prinzip INVEST berücksichtigen. Im Unterschied zu einer Story hat der Baustein Case keine Akzeptanzkriterien und auch weitere Ebene der Verfeinerung durch Aufgaben.
Der Baustein Case darf jedoch nicht mit einem Usecase verwechselt werden. Ein Usecase hat in der Regel das Ziel, Software mit abstrakten Anwendungsfällen zu beschreiben. Der Baustein 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 E-Book veröffentlicht wurde.
Prozesse
Produktentwicklung
Mit dem Baustein Case lernt ein Leser (z.B. Entwickler oder Tester) einen wichtigen Begriff der fachlichen Domäne kennen. Er kennt die Ausgangslage für eine bestimmte Fähigkeit des Produktes. So bekommt er eine bessere Vorstellung, wie ein Nutzer mit dem IT-System arbeitet. Der Baustein Case stellt den Übergang von der Systembeschreibung in die Systemstruktur dar.
Jedes Produktinkrement erweitert das Produkt um mindestens eine neue Fähigkeit oder ändert eine bestehende. In seltenen Fällen wird eine Fähigkeit entfernt. Neben den Bausteinen der Systemstruktur spielt der Baustein Case bei der Definition für ein fertiges Produktinkremet (vgl. Prinzip DOD) eine wichtige Rolle. Für jede realisierte Fähigkeit im Produkt gibt es einen Baustein Case mit einer Lösungsbeschreibung. Die Lösungsbeschreibung ist ein wichtiges Feedback der Entwickler an den Produktverantwortlichen. Bei der Lösungsbeschreibung müssen die Entwickler ganz stark darauf achten, dass sie nur die “Essenz” der Lösung erfassen. Das bedeutet, dass die Entwickler in einfachen Worten erklären, wie die Fähigkeit des Produktes sich in den Komponenten und Datenflüssen des IT-Systems spiegelt. Ziel ist es, die Lösung als eine Art Navigation durch die Systemstruktur zu beschreiben, ohne groß ins Details zu gehen. Die Gefahr ist, das Entwickler in (meist technisch motivierte) Details abgleiten. Der Produktverantwortliche muss in der Lösungsbeschreibung nicht lernen, wie die Software im Detail funktioniert. Das steht in erster Linie im Code, ergänzt durch die Bausteine der Systemstruktur.
Seitenvorlagen für alle Bausteine und hilfreiche Makros für die Verwendung in Confluence.
Qualität
Seitenvorlage des Bausteins
Confluence unterstützt mit Seitenvorlagen die Idee der Bausteine optimal. Das folgende Beispiel kann direkt als HTML im Editor der Seitenvorlagen eingefügt werden.
Bitte hier Klicken, um den Quelltext anzuzeigen
<h1>Ausgangslage</h1>
<p>
<ac:placeholder>Hier bitte die fachlichen Ausgangslage beschreiben. Die Fachbegriffe bitte mit Einträgen aus dem Glossar verknüpfen.</ac:placeholder>
</p>
<h1>Lösung</h1>
<p>
Offen<ac:placeholder>Hier bitte die Essenzschritte der Lösung in einer Tabelle mit automatischer Nummerierung eintragen. Die Essenzschritt bitte mit Elementen der Systemstruktur verknüpfen.</ac:placeholder>
</p>
Struktur
Eigenschaften des Bausteins
Der Baustein Case vermittelt eine angemessen genaue Beschreibung einer
konkreten Fähigkeit der Software als Ausgangslage und seine
Lösung im Produkt.
Angemessen bedeutet, dass Entwickler und Tester die Fähigkeit verstehen.
Der Seitentitel beginnt immer mit Case.
Durch die Seitenvorlage hat jede Seite das Stichwort case.
Sie kann aber um weitere Schlagworte ergänzt werden.
Dadurch wird die Seite leichter auffindbar.
Der Baustein Case beschreibt die Lösung in einer stark vereinfachten Form als Essenzschritte. In jedem Essenzschritt wird auf ein Element der Systemstruktur verwiesen. Das kann mit dem Baustein Layout ein Teil der Bedieneroberfläche oder mit dem Baustein Service ein Dienst des IT-Systems sein.
Der Baustein Case hat einen Zustand. Er ist in Arbeit, wenn die Ausgangslage die geforderte Fähigkeit der Software beschreibt, aber die Lösung noch offen ist. Er ist fertig, wenn es eine Lösung für die geforderte Fähigkeit des Produktes in einem Produktinkrement gibt.
Der Baustein Case hat durch die konkrete Lösung immer einen Bezug zu einem Produktinkrement.
Der Baustein Case wird in der Sprache der interessierten Parteien geschrieben.