Anfor­derungen an ein System ent­stehen in den Fach­abtei­lungen aus einem Bedarf der Nutzer eines IT-Systems oder aufgrund von Anpassung an eine ve­ränderte Unter­nehmens­strategie oder Organi­sations­struktur im Unter­nehmen oder wegen Änderungen in Gesetzen bzw. Verordnungen. Der Bau­stein Case ist das Arte­fakt in der System­beschrei­bung, mit dem Autoren ein­zelne, nicht weiter teil­bare Fähig­keiten der Soft­ware beschreiben.

Der Baustein Case gibt einem Anwen­dungs­­­fall, einer beson­­deren Situat­ion oder einem bekann­­ten und akzep­­tier­­ten Feh­ler einen ein­­deu­ti­gen Namen und ent­­hält eine fach­­liche Beschrei­­bung. Die Beschrei­bung der Aus­gangs­lage im Bau­stein muss jeden Leser in die Lage ver­setzen, die Fähig­keit fach­lich einzu­ordnen und zu ver­stehen. Der Ver­wendung der Begriffe aus dem Glossar hilft dabei.

Der Baustein Case bildet den Über­gang der System­beschrei­bung in die System­struk­tur und umge­kehrt. Sobald die Fähig­­keit reali­­siert wurde, werden die Essenz­­schritte der gewähl­­ten Lösung ergänzt. Diese kom­pakte Liste beschreibt die Lösung als eine Art «Pfad» durch die Soft­ware, eine Art «Navi­gation» durch die Kompo­nenten und Daten­flüsse des IT-Systems.

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.

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.

Tech­niken und Methoden für die Erstel­lung einer Story, z.B. die Erzähl­methode (engl. story telling), können 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 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 ver­öffent­licht wurde.

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 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. Durch die kompakte, listenorientierte Form der Dokumentation sinkt die Gefahr, dass 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. Die konkrete Lösung wird mit den Bau­steinen der Systems­truk­tur dokumentiert und steht in erster Linie im Code.