Home · Fasen · Rollen · Producten · Best practices · Referenties · Nieuws & release notes · Begrippen

Haalbaarheidsstudie
Opstellen use cases

Al heel snel in het project worden voor de volledige scope van het project de use case diagrammen opgesteld, op een abstract niveau. Deze use case diagrammen fungeren ook in de haalbaarheidsstudie al als basis voor het maken van schattingen. De use cases vormen een uitstekende eenheid voor de schatting van de complexiteit van een applicatie. Use cases zijn namelijk niet oplossingsgericht modelleertechnieken, dit in tegenstelling tot een gegevensmodel of een klassendiagram, maar beschrijven slechts de requirements van een applicatie.

Doel

Het opstellen van de first-cut use case diagrammen. Deze use case diagrammen worden reeds in de haalbaarheidsstudie opgesteld, omdat ze de rode draad vormen voor het project, onder andere voor het stellen van prioriteiten, het plannen van iteraties en als uitgangspunt voor ontwerpen en testen.

Stappen

  1. Van bedrijfsproces naar requirements
    Maak voor ieder bedrijfsproces een use case diagram aan. Geef dit use case diagram bij voorkeur dezelfde naam als het bedrijfsproces. Voor ieder use case diagram alvast van een primaire use case, die het bedrijfsproces gaat weergeven. Dit kan in het geval het beschreven bedrijfsproces 'doorlopend' is, dat wil zeggen een verzameling taken kent die tezamen het bedrijfsproces realiseren.

  2. Verbinden actors
    Organiseer een gefaciliteerde workshop waarbij per bedrijfsproces (en dus per use case diagram) de requirements worden vastgesteld. Ga per bedrijfsproces na welke actors erbij betrokken zijn.

  3. Modelleren use cases
    Stel per bedrijfsproces de vraag welke taken moeten worden uitgevoerd om het te realiseren. Modelleer deze taken als secundaire use cases in het diagram. Voorzie iedere use case van een naam en noteer het doel dat de use case dient.
    De facilitator geeft het use case diagram zoveel mogelijk vorm tijdens deze workshop, waarbij - indien nu al inzichtelijk is - de "include" en "extend" relaties worden onderkend.

Richtlijnen

Naamgeving use cases
De naam van een use case is vaak te vereenvoudigen tot een volledig werkwoord plus een zelfstandig naamwoord.

Ontbreken van een procesmodel
Bij het ontbreken van een procesmodel kan de actor catalogus woren gebruikt als uitgangspunt om tot use cases te komen. De facilitator kan tijdens de workshop eenvoudige vragen stellen als "als deze actor 's ochtends op zijn werkplek komt, wat gaat hij dan doen?" of "stel dat er een nieuwe hypotheekaanvraag binnenkomt, wat gaat de actor dan doen?". Dergelijke vragen initiëren vaak een levendige discussie waarbij het werkproces van de actor haast vanzelfsprekend onder de loep wordt genomen.

Detaillering van use cases
Omdat deze eerste use case diagammen als basis dienen voor een groot aantal andere activiteiten, bijvoorbeeld het komen tot een realistische schatting aan het eind van de haalbaarheidsstudie, is het zaak de use cases op een 'schatbaar' detailniveau uit te drukken. Zo kan een nauwkeuriger schatting worden verkregen en fungeert de use case als een betere eenheid voor de rest van het project. Doordat een use case diagram wordt gebruikt voor het realiseren van een enkel bedrijfsproces, met daarbij een aantal secundaire use cases ter ondersteuning, is de granulariteit van de use case al prettig laag. Een praktische richtlijn is om een use case per te verwachten form of andere eenheid van user interface te hanteren.

Use cases en relaties
Er zijn twee (a drie) typen relaties tussen use cases. Op dit niveau hoeven deze niet te worden geïdentificeerd. Afhankelijk van de ervaring van het team gebeurt dit vaak toch, bij evidente relaties. Dit is bijvoorbeeld vaak het geval bij standaard onderhoudsfunctionaliteit, waarbij bijvoorbeeld de use cases "Selecteren Grootboekrekening" en "Onderhoud Grootboekrekening" worden geïdentificeerd.

 [TASK012] Versie 2003Q2 Basic - ©1999-2006 Sander Hoogendoorn (aahoogendoorn@gmail.com), 1 juli 2003