Specificeer use cases

Waar het use-casemodel laat zien wélke use cases er zijn, legt deze activiteit vast wat er in een use case gebeurt. Per use case wordt het hoofdscenario beschreven: de stappen waarin de actor en het systeem elkaar afwisselen totdat het beoogde resultaat is bereikt. Daarnaast worden de afwijkingen op dat scenario vastgelegd — wat gebeurt er als de gegevens niet kloppen, als een koppeling niet beschikbaar is, als de actor halverwege afhaakt. In die afwijkingen zit doorgaans het merendeel van het werk en van de verrassingen.

Niet elke use case verdient dezelfde uitwerking. Use cases die technisch risicovol zijn, die de structuur van het systeem bepalen of waarover de stakeholders het onderling nog niet eens zijn, worden volledig uitgeschreven; herkenbare, goed begrepen use cases volstaan met een beknopte beschrijving. Het detailniveau is daarmee een expliciete keuze en geen gewoonte: er wordt uitgeschreven zolang dat onzekerheid wegneemt, en niet langer.

Tijdens het uitschrijven komen onvermijdelijk eisen naar boven die niet aan één use case toebehoren: kwaliteitseisen, wettelijke verplichtingen en beperkingen die van buitenaf zijn opgelegd. Die worden in dezelfde beweging vastgelegd in de aanvullende specificaties. Het is geen apart moment en geen aparte stap — juist doordat het uitschrijven van een scenario zulke eisen zichtbaar maakt, worden ze daar meteen geordend naar kwaliteitskenmerk en toetsbaar geformuleerd, in plaats van later alsnog te moeten worden gereconstrueerd.

Het uitschrijven is zelf een onderzoeksmiddel. Zodra het hoofdscenario stap voor stap op tafel ligt, komen tegenstrijdigheden tussen stakeholders, ontbrekende gegevens en impliciete aannames aan het licht die in het beknopte model onzichtbaar bleven. Wat daarbij naar boven komt, kan leiden tot aanpassing van het use-casemodel — de werkproducten groeien in samenhang.

De aanpak begint met kiezen. Uit het use-casemodel worden de use cases geselecteerd waarvan de uitwerking het meeste oplevert: de use cases die de structuur van het systeem bepalen, waar technisch risico zit, waar wet- en regelgeving hard ingrijpt, of waarover de stakeholders het onderling nog oneens zijn. Die worden als eerste uitgeschreven, zodat de onzekerheid vroeg verdwijnt in plaats van laat.

Per use case wordt eerst het hoofdscenario opgeschreven: genummerde stappen waarin steeds duidelijk is wie handelt, de actor of het systeem, en die eindigen bij het resultaat waarvoor de use case bestaat. Vervolgens wordt bij elke stap de vraag gesteld wat er anders kan lopen. Elk antwoord daarop wordt een alternatief scenario met een eigen afloop. Deze twee stappen worden bewust gescheiden gehouden: een hoofdscenario dat al doorspekt is met uitzonderingen leest niemand meer.

Rond het scenario worden de voorwaarden vastgelegd waaronder de use case start en de toestand waarin het systeem achterblijft, plus de gegevens die worden uitgewisseld en de regels die daarop gelden. Wat tijdens het uitschrijven boven water komt maar niet aan deze use case toebehoort, wordt niet weggeschreven maar doorgegeven: eisen die voor meerdere use cases gelden gaan naar de aanvullende specificaties, nieuwe of verkeerd afgebakende use cases gaan terug naar het use-casemodel.

Elke uitgewerkte use case wordt getoetst bij de betrokken actoren en de opdrachtgever. Pas als zij het scenario herkennen als hun eigen werkwijze — of bewust kiezen voor een andere — is de specificatie af.

Voor de eisen die niet aan één use case toebehoren wordt een vaste indeling naar kwaliteitskenmerken aangehouden, zodat systematisch kan worden nagegaan of er niets ontbreekt in plaats van af te wachten wat stakeholders uit zichzelf noemen. Per kenmerk — beschikbaarheid, prestaties, beveiliging, toegankelijkheid, onderhoudbaarheid en de overige die de organisatie hanteert — wordt gevraagd welke eis geldt en waar die vandaan komt.

Elke eis wordt vervolgens toetsbaar gemaakt. Dat betekent een meetbare uitspraak met de omstandigheden erbij: welke gebeurtenis doet zich voor, welk deel van het systeem betreft het, welke reactie wordt verwacht en binnen welke marge. Zo'n formulering maakt niet alleen achteraf toetsing mogelijk, maar dwingt tijdens het gesprek al scherpte af over wat werkelijk nodig is.

Daarna wordt de set naast de bestaande kaders gelegd. Wat de paved road, de architectuurprincipes of geldende wet- en regelgeving al voorschrijven, wordt niet opnieuw uitgeschreven maar met een verwijzing overgenomen; wat ervan afwijkt, wordt expliciet benoemd omdat het tot een architectuurbeslissing of een uitzondering moet leiden. Onderlinge tegenstrijdigheden — een prestatie-eis die zich niet verhoudt tot een beveiligingseis — worden niet gladgestreken maar voorgelegd aan de stakeholders, die de afweging maken.

Tot slot wordt per eis vastgelegd voor welke use cases hij geldt, zodat bij realisatie en toetsing zichtbaar blijft waar de eis raakt aan het gebruik van het systeem.