Der Baustein Case


Methode

Motivation für den Einsatz

Anfor­derungen an ein System entstehen in den Fach­abteilungen aus einem Bedarf, den die Nutzer eines IT-Systems haben oder auf­grund von Anpassung an eine ver­änderte Unter­nehmens­strate­gie oder Organi­sations­struktur im Unter­nehmen. Der Bau­stein Case ist das Artefakt in der System­beschrei­bung, mit dem Autoren die Ergeb­nisse der Anfor­derungs­analyse sichern. Er gibt einer ange­forderten Fähig­keit des Produktes einen ein­deutigen Namen. Der Überblick im Bau­stein muss jeden Leser in die Lage ver­setzen, die Fähig­keit fach­lich einzu­ordnen. Der Ver­wendung der Begriffe aus dem Glossar hilft dabei. Der Bau­stein doku­mentiert einen Anwendungs­fall, eine beson­dere Situa­tion oder einen bekann­ten akzep­tierten Fehler in der Soft­ware.

Der Bau­stein Case stellt jedoch keine Doku­mentation der Anfor­derung dar, sondern ist immer eine Pro­jektion der Anfor­derung auf das Pro­dukt.

Autoren sichern fach­liches Wissen aus der Anfor­derungs­analyse. Später, zum Zeitpunt der Reali­sierung bekommt das Team einen guten Einblick in die Moti­vation der inter­essierten Par­teien, allen voran der Nutzer. Leser finden Ant­worten auf die Frage, bei welcher kon­kreten Ausgangs­lage die Nutzer eine bestimmte Fähig­keit des Pro­duktes ver­wenden. Das ist ein ent­scheiden­der Vor­teil für das Team, die “beste” Lösung für die Nutzer zu finden.

Wissens­­­­­manage­­ment richtig organi­­sieren.
Ziel­gerichtet. Agil. Iterativ.


Pro­zesse

Pro­jekt­manage­ment

Der Pro­dukt­­verant­wort­liche hat mit dem Bau­stein Case die Mög­lich­keit, eine pro­dukt­­spezi­fische Fähig­keit vor­läufig zu beschrei­ben. Der Auf­trag­geber legt fest, welche Anfor­derungen an das IT-System ge­stellt werden. Der Pro­dukt­verant­wort­liche nutzt den Bau­stein, um eine wich­tige Ent­schei­dung des Auf­trag­gebers für oder gegen die Reali­sierung einer angefor­derten Fähig­keit nach­haltig zu doku­mentieren. Ein guter Titel legt früh­zeitig den Grund­stein für eine gemein­same Sprache von Auf­trag­geber, Pro­dukt­­verant­wort­lichen und dem Team.

 


Pro­zesse

Anfor­derungs­analyse

Der Bau­stein Case hilft dem Pro­dukt­verant­wort­lichen bei der Sicherung der Ergeb­nisse der Anfor­derungs­analyse. Eine von Auf­trag­geber und inter­essierten Par­teien akzep­tierte Beschrei­bung einer kon­kreten Fähig­keit des Pro­duktes stellt den dritten Schritt der Vali­dierung einer Anfor­derung dar.

Anders als beim Bau­stein Epic geht es beim Bau­stein Case um die Identifi­zierung von Fähig­keiten der Soft­ware, mit denen die Anfor­derungen erfüllt werden können.

Die Tech­niken und Methoden für die Erstel­lung einer Story, z.B. die Erzähl­methode (engl. story telling), kann ohne Ein­schrän­kungen auch für das Schrei­ben der Aus­gangs­lage im Bau­stein Case ver­wendet werden. Der Bau­stein Case ist in sich geschlos­sen, test­bar und im Normalf­all klein genug, um in einer Iteration (z.B. Sprint bei Scrum) umge­setzt zu werden. Die Aus­gangs­lage ist immer “lösungs­offen”. Wie bei einer Story sollten Autoren unbe­dingt das Prinzip INVEST berück­sich­tigen. Im Unter­schied zu einer Story hat der Bau­stein Case keine Akzep­tanz­krite­rien und auch weitere Ebene der Ver­feinerung durch Auf­gaben.

Der Bau­stein Case darf jedoch nicht mit einem Use­case ver­wechselt werden. Ein Use­case hat in der Regel das Ziel, Soft­ware mit abstrak­ten Anwen­dungs­fällen zu beschrei­ben. Der Bau­stein Case hat jedoch große Ähnlich­keit mit der Idee der Slices aus der agilen Tech­nik “Use Case 2.0”, das 2011 von Ivar Jacobson, Ian Spence und Kurt Bittner in dem gleich­namigen E-Book ver­öffent­licht wurde.

 


Pro­zesse

Pro­dukt­entwick­lung

Mit dem Bau­stein Case lernt ein Leser (z.B. Entwickler oder Tester) einen wich­tigen Begriff der fach­lichen Domäne kennen. Er kennt die Aus­gangs­lage für eine bestimmte Fähig­keit des Pro­duktes. So bekommt er eine bessere Vor­stellung, wie ein Nutzer mit dem IT-System arbei­tet. Der Bau­stein Case stellt den Übergang von der System­beschrei­bung in die System­struk­tur dar.

Jedes Pro­dukt­inkre­ment erweitert das Pro­dukt um min­destens eine neue Fähig­keit oder ändert eine bestehende. In seltenen Fällen wird eine Fähig­keit ent­fernt. Neben den Bau­steinen der System­struktur spielt der Bau­stein Case bei der Defini­tion für ein fer­tiges Pro­dukt­inkremet (vgl. Prinzip DOD) eine wich­tige Rolle. Für jede reali­sierte Fähig­keit im Pro­dukt gibt es einen Bau­stein Case mit einer Lösungs­beschrei­bung. Die Lösungs­beschrei­bung ist ein wicht­iges Feed­back der Ent­wick­ler an den Pro­dukt­verant­wort­lichen. Bei der Lösungs­beschrei­bung müssen die Ent­wick­ler ganz stark darauf achten, dass sie nur die “Essenz” der Lösung erfassen. Das bedeutet, dass die Ent­wick­ler in ein­fachen Worten erklä­ren, wie die Fähig­keit des Pro­duktes sich in den Kompo­nenten und Daten­flüssen des IT-Systems spiegelt. Ziel ist es, die Lösung als eine Art Navi­gation durch die System­struktur zu beschrei­ben, ohne groß ins Details zu gehen. Die Gefahr ist, das Ent­wick­ler in (meist tech­nisch moti­vierte) Details abglei­ten. Der Pro­dukt­verant­wort­liche muss in der Lösungs­beschrei­bung nicht lernen, wie die Soft­ware im Detail funktio­niert. Das steht in erster Linie im Code, ergänzt durch die Bau­steine der Systems­truk­tur.

Seiten­vorlagen für alle Bau­steine und hilf­reiche Makros für die Ver­wendung in Con­fluence.


Quali­tät

Seiten­vor­lage des Bau­steins

Confluence unter­stützt mit Seiten­vor­lagen die Idee der Bau­steine optimal. Das fol­gende Bei­spiel kann direkt als HTML im Editor der Seiten­vor­lagen ein­gefü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>

 


Struk­tur

Eigen­schaf­ten des Bau­steins

Der Bau­stein Case ver­mittelt eine ange­messen genaue Beschrei­bung einer kon­kreten Fähig­keit der Soft­ware als Aus­gangs­lage und seine Lösung im Pro­dukt. Ange­messen bedeu­tet, dass Ent­wick­ler und Tester die Fähig­keit ver­stehen. Der Seiten­titel beginnt immer mit Case. Durch die Seiten­vor­lage hat jede Seite das Stich­wort case. Sie kann aber um weitere Schlag­worte ergänzt wer­den. Dadurch wird die Seite leich­ter auf­find­bar.

Der Bau­stein Case beschreibt die Lösung in einer stark ver­ein­fach­ten Form als Essenz­schritte. In jedem Essenz­schritt wird auf ein Element der System­struktur ver­wiesen. Das kann mit dem Bau­stein Layout ein Teil der Bediener­ober­fläche oder mit dem Bau­stein Service ein Dienst des IT-Systems sein.

Der Bau­stein Case hat einen Zustand. Er ist in Arbeit, wenn die Aus­gangs­lage die gefor­derte Fähig­keit der Soft­ware beschreibt, aber die Lösung noch offen ist. Er ist fertig, wenn es eine Lösung für die gefor­derte Fähig­keit des Pro­duktes in einem Produkt­inkre­ment gibt.

Der Bau­stein Case hat durch die kon­krete Lösung immer einen Bezug zu einem Pro­dukt­inkre­ment.

Der Bau­stein Case wird in der Sprache der inter­essierten Par­teien geschrie­ben.