use cases considered harmful

De titel is een grapje. Use cases zijn wel degelijk nuttige instrumenten bij de specificatie van systemen. Tenminste: als ze op de goede manier worden gebruikt. Dus zonder teveel details, zonder beschrijving van het UI, en toegespitst op wat het resultaat van een actie van het systeem moet zijn. En de use case moet vooral niet beschrijven hoe een resultaat bereikt wordt, maw: hoe het systeem moet werken.

In de overgrote meerderheid van de gevallen gaan de use cases ver buiten de grenzen die hierboven zijn beschreven. En dan komen er problemen, want een (gedetailleerde) beschrijving van de werking, de binnenkant, van een systeem vereist een formele taal. Use cases zijn niet formeel. En als UI beschrijvingen worden opgenomen, dan moeten use cases worden gewijzigd als het UI wijzigt. Dat is niet te doen, want UIs zijn zoals bekend erg veranderlijk.

Goed, use cases moeten goed worden gebruikt (ja natuurlijk), en als het toch mis gaat, ligt dat aan degenen die use cases toepassen. Of niet?

Ik denk dat use cases als techniek een paar ingebouwde problemen heeft, en dat die bijdragen aan het wijdverbreide misbruik.

Allereerst: use cases maken deel uit van UML. Dat heeft tot gevolg gehad dat use cases allerwege werden gezien als NIEUW! en MODERN! en vooral ook: OBJECT-GEORIENTEERD! En men verwachtte ook dat de daaraan verbonden (veronderstelde) voordelen zich bij gebruik van use cases als vanzelf zouden manifesteren. Dat is niet gebeurd. Niet alleen omdat die voordelen nooit vanzelf komen, maar ook omdat use cases niets meer zijn dan in een nieuw jasje gestoken functionele ontwerpen. Beter gestrctureerd, enigszins gestandaardiseerd, een leuk diagrammetje waar je niks aan hebt er bij, jazeker, maar eigenlijk gewoon oude wijn in nieuwe zakken. Op zichzelf was er met die oude wijn niet zoveel mis, maar de verwachtingen waren hoger gespannen. En die komen niet uit, want use cases leiden niet tot een betere of een andere wijze van systeemontwikkeling. Dat verklaart waarschijnlijk ook hun populariteit: je hoeft er niks nieuws voor te leren.

Verder: use cases worden gepresenteerd als HET middel voor requirementsanalyse. Dat is onjuist. Voor hoog niveau requirements zijn use cases eigenlijk een niveau "te diep": je kunt pas use cases schrijven als je weet welke processen er zijn, wanneer die processen met het systeem interageren, en wat het resultaat van die interacties moet zijn. En voor het "in kaart brengen" van het business-domein zijn use cases ongeschikt. Daarvoor is een class-model (in UML) een veel beter middel. Maar in de gangbare projectopzet komt een class-model pas na de use cases (als het al komt, want meestal zit het project in de use cse trap, waarover zo dadelijk meer). Use cases worden dus vaak ingezet voor het verkeerde doel.

Tenslotte: use cases komen altijd vergezeld van een preek over hoe ze te gebruiken, en vooral hoe ze niet te gebruiken (zoiets als in de eerste alinea van deze past, maar dan veel langer). En die preken zijn nodig, want het is veel te makkelijk om ze verkeerd toe te passen. Dat komt doordat use cases volledig informeel zijn. Hoe je specificeert, wat de vereiste mate van detail is, het is allemaal open. De hoogste vorm van formalisatie is: een Word-template. Tsja. Fouten maken is dus veel te makkelijk.

Goed, use cases sluiten dus niet goed aan bij (moderne) methoden voor systeemontwikkeling, use cases worden verkeerd ingezet, en use cases zijn veel te informeel. Toch (of juist daardoor) zijn ze populair. De populariteit van use cases heeft ervoor gezorgd dat menig project in de use case trap terecht is gekomen. Hoe werkt de use case trap?

Een voorbeeld. Er moet een nieuw order entry systeem worden gebouwd, en dat moet op een bepaalde datum klaar zijn. Allereerst moet er een inventarisatie van de requirements komen. Daarvoor zetten we use cases in. Die zijn vreselijk onhandig daarvoor, want je moet dan gelijk de interacties van het systeem met de buitenwereld beschrijven, hoewel we nog helemaal weten niet of er wel een systeem moet komen! En veel requirements zullen in verscheidene use cases worden beschreven. Dat is dubbel werk. Maar niet getreurd, we huren een stelletje consultants in.

Bovendien heeft men geen goed zicht op het probleemdomein, dus worden allerlei wetenswaardigheden over het domein in de use cases opgeschreven, bijvoorbeeld dat een order tenmnste een en maximaal tien orderregels bevat. Die zijn daarvoor ongeschikt. En omdat men nu toch zo fijn met de gebruiker aan de gang is, wordt het UI ook gelijk maar even beschreven in de use cases.

Allemaal heel begrijpelijk, maar het gevolg is dat we al heel snel door de bomen het bos niet meer zien, en de tijd die in het projectplan was gereserveerd voor de use cases wordt ruimschoots overschreden. Maar we gaan toch maar door, want je moet toch beschrijven wat je nodig hebt? Maar op een gegeven moment is de einddatum van het hele project nog maar 4 maanden verwijderd. Moet er nou toch niet eens worden gebouwd?

Ja, eigenlijk wel. Gelukkig herinnert een consultant zich dat use cases eigenlijk helemaal niet zo gedetailleerd moeten zijn, dus kunnen we nu best stoppen. (Dat had ie wel eens eerder mogen zeggen.) De bouwers krijgen de stapel met use cases toegeworpen, en mogen op basis daarvan aan de gang gaan. Voor domein analyse is geen tijd meer, voor een goed ontwerp ook niet. Er moet geklopt worden!

Affijn, de bekende ellende dus. En een deel daarvan wordt veroorzaakt door de (verkeerde) toepassing van de use cases. Maar dat ligt niet alleen aan ons, ook wel een beetje aan de use case techniek zelf.

Misschien is die titel toch niet alleen maar een grapje...