Ontwerp scope en use cases

Het is gevaarlijk om er vanuit te gaan dat de lezers en schrijvers van een use case wel weten wat de scope is van het te ontwerpen systeem. Ieder lid van het team heeft waarschijnlijk een ander beeld van het te ontwerpen systeem en de grenzen hiervan. De ontwerp scope is de omvang van het te ontwerpen systeem. De discussies die worden gehouden tijdens de ontwerp en specificatie sessies gaan over software dat wordt geïnstalleerd op een server. De grenzen van het te ontwerpen systeem en dus de ontwerp scope houden hier vaak ook op. Toch is dit vaak variabel te interpreteren.  Lezers en schrijvers van use cases moeten snel inzicht kunnen krijgen in de ontwerp scope van het te ontwerpen systeem. De ontwerp scope komt terug in iedere use case.

Ieder lid van het team heeft waarschijnlijk een ander beeld van het te ontwerpen systeem en de grenzen hiervan. Lezers en schrijvers van use cases moeten snel inzicht kunnen krijgen in de scope van het te ontwerpen systeem.

Het is van groot belang dat iedereen binnen het team het eens wordt over de grenzen van het te ontwerpen systeem. Deze grenzen zullen overigens niet duidelijk worden door de naam van de use case of de betrokken primaire actor. Het is daarom van groot belang dat iedere use case gelabeld wordt met de ontwerp scope.

Niveaus van de ontwerp scope

De interactie die de primaire actor aangaat in een use case kan op diverse niveaus. Zo kan het gedrag van de gehele organisatie worden beschreven of wordt het gedrag van een computersysteem in kaart gebracht. Het is ook mogelijk dat het gedrag van een specifiek component in het computersysteem wordt beschreven. Er zijn globaal drie scope namen:

Onderneming

Het gedrag van de gehele organisatie of onderneming wordt beschreven. Neem in de use case een label van het bedrijf op (bijvoorbeeld ‘Acme’) in plaats van alleen ‘de organistatie’. Het is ook mogelijk om een bepaalde afdeling van de organisatie als design scope te nemen. Een voorbeeld is ‘Acme Inkoop’. Use cases die gaan over dit niveau worden ‘business use cases’ genoemd.

Systeem

Het systeem als scope is een verzameling computer systemen. Buiten de scope staan systemen van derden inclusief benodigde diensten van en naar deze systemen en niet te vergeten de gebruikers van het systeem dat ontworpen wordt. Systemen van derden kunnen overigens ook actoren zijn met het systeem. Use cases die gaan over het systeem worden ‘systeem use cases’ genoemd. Neem in de use case de naam van de applicatie op als label van de scope.

Subsysteem

Het systeem wordt onder de loep genomen en er wordt ingegaan op de onderdelen van het te ontwerpen systeem. Enkele voorbeelden zijn de zoekmachine, het content management systeem en de webservices. Use cases die gaan over subsystemen worden ‘component use cases’ genoemd. Neem in de use case de naam van het component op als label van de scope.

Grafische herkenning

Het is een goed om de lezer van de use case de scope van de use case te laten herkennen door het gebruik van een grafisch icoon. In het boek ‘Writing Effective Use Cases’ geschreven door Alistair Cockburn wordt gebruik gemaakt van diverse simpele grafische iconen. Hier wordt ook het onderscheid gemaakt in ‘black-box’ en ‘white-box’ use cases. Een black-box use case gaat niet over de interne structuur van het systeem, de onderneming of de afdeling van een bedrijf. Een white-box use case gaat wel in op de interactie tussen componenten in een systeem of de interactie tussen afdelingen binnen een onderneming.