Velthoven E-Business Consultancy

Actoren en rollen voor use cases vinden

Vaak worden use cases geschreven vanuit een enkel type gebruiker. Dit is een risico omdat hierdoor use cases gemist kunnen worden. Het is beter om in meerdere rollen te schrijven. Een enkele actor kan meerdere rollen uitvoeren. In dit artikel geef ik een toelichting op het onderwerp actoren en een workshop format om actoren te vinden.

Wat is een actor?

Een actor is alles dat een gedrag heeft ten opzichte van een systeem. Een actor kan een persoon zijn maar ook een bedrijf, organisatie of een systeem. Een actor hoeft dus niet per definitie menselijk te zijn. Iedere use case heeft een primaire actor. De primaire actor heeft een specifiek doel en voert de use case uit. Vaak begint de use case omdat de primaire actor een actie uitvoert. De actor opent een url in een browse, klikt op een knop of opent een app op de smartphone. Er is echter een uitzondering dat de primaire actor niet de use case begint. Deze uitzondering is tijd. Een geplande taak wordt namelijk niet uitgevoerd door de actor. De actor heeft echter wel de doelstelling in de use case.

Stakeholders als actoren

Een stakeholder is iets of iemand die interesse heeft in het gedrag van een use case. Primaire actoren zijn automatisch ook stakeholder. Sommige stakeholders hebben geen interactie met het te ontwerpen systeem maar hebben wel interesse in de werking. Voorbeelden zijn de investeerders, eigenaren, managers, product owners, business analisten en opdrachtnemers. In sommige gevallen zijn deze stakeholders ook actoren. Een voorbeeld hiervan is een functioneel beheerder of iemand van de redactie.

Brainstormen

In het begin van een project wordt er een brainstorm sessie gehouden om de primaire actoren te vinden. Het is niet erg dat er meerdere typen gebruikers worden gevonden omdat deze later worden ontdubbeld. In een aparte sessie worden stakeholders en ontwikkelaars bij elkaar gebracht. In deze sessie worden er op post-its zoveel mogelijk rollen opgeschreven. Iedereen noemt de rol zodra deze op het bord wordt gehangen. Het is belangrijk dat er nog geen discussie ontstaat op dit moment. De enige beperking is dat een rol een enkele gebruiker of systeem moet zijn.

Een rol moet een gebruiker of een systeem zijn

Actoren en doelstellingen

Tijdens het brainstormen is het gebruikelijk om het doel van een actor te benoemen. Deze doelen worden opgenomen in de actor-doel-lijst. Deze lijst geeft de relatie aan tussen de primaire actoren en de doelstellingen op taak niveau.

De actor-doel-lijst is een tabel met twee kolommen waarin de actoren en hun doelstellingen worden bijgehouden

Organiseren

Na het brainstormen worden de rollen gegroepeerd. Rollen die volledig overeenkomen worden over elkaar geplakt. Rollen die dezelfde eigenschappen bevatten worden bij elkaar gehangen.

Consolideren

Rollen die volledig overeenkomen worden vereenvoudigd naar een enkele rol. Het is belangrijk dat de schrijvers van deze rollen dezelfde rollen bedoelen. Dit kan worden bepaald in een korte toelichting of discussie. Hierna wordt er per groep rollen een generieke rol bepaald.

Verfijnen

Om de rollen verder te modelleren worden er attributen aan de rollen toegevoegd. Dit kan door op de achterkant van de post-it te schrijven. Iedere informatie die de rol onderscheidend maakt van de andere rol is waardevol. Enkele vragen die gesteld kunnen worden zijn:

Uitbreiden naar persona’s

Na deze stap kan er verder worden gegaan met het schrijven van persona’s. Een persona is een een denkbeeldige representatie van een actor of rol.

Hoe nu verder?

Nadat de actoren en rollen zijn bepaald kan er over worden gegaan tot het schrijven van user stories of het opmaken van het use case diagram. Ook is het een goede oefening om story telling toe te passen met deze actoren en rollen. Persoonlijk ben ik vooral fan van de use case narratives. Ik ben benieuwd hoe jij in je projecten actoren en rollen vindt.