Artikel

Verbeter uw use case diagrammen

Het UML use case diagram is een veel gebruikte techniek voor het modelleren van de requirements van een ICT-systeem. Hoewel het use case diagram qua modelleertechniek een van de eenvoudigste diagrammen uit UML is, blijkt het opstellen ervan in de praktijk vaak tegen te vallen. Met de tips in dit artikel kunt u de voordelen van de use case techniek ten volle benutten.

In veel projecten leidt vooral de granulariteit van de use cases tot discussies. Een use case wordt soms te groot maar meestal te klein gedefinieerd. Hoe is dat in uw organisatie? Geven de use case modellen voldoende overzicht en inzicht in de requirements? Heeft een systeem met een gemiddelde omvang in uw organisatie tussen de twintig en vijftig use cases?

Met de onderstaande tips zijn relatief eenvoudig substantiële verbeteringen te halen.

Bied overzicht

De functie van een use case diagram is het bieden van overzicht en het weergeven van het bestaansrecht van het systeem. Iedere use case in het diagram representeert namelijk een business value die door het systeem geleverd moet worden. Als een use case diagram veel kleine use cases bevat of onoverzichtelijk wordt, verliest het zijn functie. Figuur 1 geeft eerst een goed en daarna een verkeerd voorbeeld van de use cases in een use case diagram.

Figuur 1: De use cases in een use case diagram

Pas geen analyse maar synthese toe

Dat een use case vaak te klein wordt gedefinieerd komt omdat veel mensen use cases als analysetechniek hanteren. In de ICT bestaat een lange traditie met het analyseren (letterlijke betekenis: ontleden) van problemen. Hierbij wordt een groot, complex probleem opgedeeld in kleinere problemen zodat het eenvoudiger is om een oplossing voor elk van die kleinere problemen te ontwerpen. Een use case beschrijft geen probleem maar beschrijft de behoefte aan geautomatiseerde ondersteuning. Om die behoefte te begrijpen is het tegenovergestelde van analyse vereist, namelijk synthese. Alle (gedetailleerde) requirements die bijdragen aan het vervullen van een bepaalde business behoefte vormen namelijk samen een logisch geheel van opeenvolgende acties in een use case.

Vergelijk een use case met een procestaak

De granulariteit van een use case is gelijk aan die van een procestaak. Het is een eenheid van werk die op een bepaald moment in zijn geheel wordt uitgevoerd.

Voorbeelden van correcte use cases:

  • Reserveren hotelkamer
  • Opnemen geld (bij pinautomaat)
  • Controleren ingediende claim (inbraakverzekering)

Voorbeelden van te klein gedefinieerde use cases:

  • Invoeren selectiecriteria hotelkamer
  • Controleren pincode
  • Raadplegen klantinformatie (in verband met schadeclaim)

Herken de signalen voor te kleine use cases

Een use case diagram met te kleine use cases bevat vaak onevenredig veel zogeheten CRUD use cases. Een CRUD use case is een use case die begint met Create, Read, Update of Delete. Bijvoorbeeld de use case 'Invoeren klant- en betaalgegevens'. De meerwaarde die een use case biedt is in de meeste gevallen te omschrijven met behulp van een ander werkwoord. Bijvoorbeeld de use case 'Reserveren hotelkamer' of de use case 'Beoordelen hotelverblijf'. Als het niet lukt om CRUD use cases te vermijden is de kans groot dat de use cases te ver opgesplitst zijn.

Een ander signaal van te kleine use cases is de behoefte om relaties tussen de use cases te leggen en er een volgorde in aan te brengen. Er zijn dan waarschijnlijk meerdere use cases nodig om een eindresultaat te leveren dat waarde heeft voor de actor. Voeg in dat geval de use cases dan samen tot een use case met een duidelijke business value.

Benader actoren vanuit het gezichtspunt van het systeem

In een use case diagram worden de grenzen van het systeem zichtbaar gemaakt door de interactie van het systeem met zijn directe omgeving, de actoren, te modelleren. Actoren kunnen menselijke gebruikers en ander ICT-systemen zijn. Een actor is een rol die iets of iemand vervult gezien vanuit het gezichtspunt van het systeem. Figuur 2 geeft eerst een goed en daarna een verkeerd voorbeeld van de actoren in een use case diagram.

Figuur 2: De actoren in een use case diagram

Als de actoren vanuit het gezichtspunt van de business worden benaderd ontstaan problemen met het aantal actoren dat interacteert met de use case. Vaak mogen meerdere functies in de organisatie een use case uitvoeren. Voor het systeem maakt het echter niet uit of bijvoorbeeld een medewerker binnendienst, een manager of een voorraadbeheerder de use case 'Plaatsen bestelling' uitvoert. Vanuit het systeem gezien heeft die gebruiker de rol van inkoper. Deze use case interacteert dus met één actor, niet met drie actoren.

Actoren onderkennen vanuit het gezichtspunt van de business is niet alleen methodisch onjuist, maar leidt tot een complex en onoverzichtelijk use case diagram. Zo'n use case diagram vergt bovendien meer onderhoud omdat wijzigingen in de benamingen en de bevoegdheden van (business) functies leiden tot aanpassingen in de specificaties.

Categorie:   
Auteur(s)
afbeelding van reaco
Nicole de Swart
Reaco Academy - Requirements expert

Nicole de Swart is auteur van Handboek Requirements en oprichtster van het Requirements Kenniscentrum. Via de Reaco Academy helpt Nicole requirementsanalisten de overstap naar agile te maken. Daarnaast geeft ze les aan studenten Business Information & Management op de Hogeschool van Amsterdam.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.