Use cases

Deze practice geeft invulling aan de Requirements-alpha door de eisen aan het systeem te ordenen rond het gebruik ervan. In plaats van een lange, platte lijst met losse eisen wordt vastgelegd wie het systeem gebruikt — de actoren — en welk waardevol resultaat zij ermee willen bereiken. Elk van die resultaten is een use case. Door de eisen op deze manier te structureren blijft steeds zichtbaar waaróm een eis bestaat en voor wie, en ontstaat een verhaal dat opdrachtgever, gebruikersvertegenwoordigers en het realisatieteam met elkaar kunnen delen.

De practice kent twee stappen die elkaar opvolgen maar in de praktijk iteratief worden doorlopen. Eerst wordt de buitenkant van het systeem in kaart gebracht: welke actoren zijn er, welke use cases herkennen zij, en waar ligt de systeemgrens. Dat levert het use-casemodel op — het overzicht dat de omvang van het werk begrenst. Vervolgens worden de use cases die er werkelijk toe doen uitgeschreven tot use-casespecificaties, met het hoofdscenario en de afwijkingen daarop. In diezelfde stap worden de eisen die niet aan één use case toe te wijzen zijn — kwaliteitseisen, wettelijke verplichtingen, ontwerpbeperkingen — vastgelegd in de aanvullende specificaties, zodat ze niet verdwijnen tussen de use cases in. Dat is geen apart moment: juist het uitschrijven van een scenario maakt zulke eisen zichtbaar.

De practice beschrijft het identificeren en specificeren van use cases, niet het opdelen ervan in stukken werk voor een realisatieteam. Die verdeling hoort thuis in de planning van het werk en niet in het vastleggen van de eisen.

Het use-casemodel en de use-casespecificaties zijn ook voor de architectuur van belang: de architectuurbepalende eisen worden eruit geselecteerd, en de use cases die technisch risicovol of structuurbepalend zijn, sturen de architectuurbeslissingen en de opbouw van de architectuurbeschrijving.