Usecasemodel
Requirements omvatten de mogelijkheden van het systeem (functies/kenmerken) en voorwaarden of
beperkingen op hoe deze mogelijkheden kunnen toegepast worden. Het externe gedrag van het
systeem.
2 soorten eisen:
1. Functionele eisen (= functionaliteit en gegevens)
a. Wat wil de gebruiker dat het systeem kan?
2. Niet-functionele eisen (= kwaliteit en beperkingen)
a. Randvoorwaarden waarbinnen de functionaliteiten moeten worden aangeboden
Functionele eisen
1. Analyseer de taken van de gebruiker
2. Overweeg of een geautomatiseerd systeem hulp/ondersteuning kan bieden bij de uitvoering
van de job
Usecasemodel
Een usecasemodel is:
• Een hulpmiddel om functionele eisen te bepalen tijdens analyse en design
• Een basis voor testen
• Ondersteunt communicatie tussen klant, ontwikkelaar, marketing, verkoop, …
• Basis voor documentatie van het systeem
Het usecasediagram geeft een overzicht van de functionele eisen (usecases) per type gebruiker.
Per functionele eis in het usecasediagram wordt een usecasebeschrijving gemaakt waarbij:
- Het systeem wordt beschouwd als black box
- Focus is wat het systeem moet kunnen doen in reactie op de gebruiker en niet hoe.
Systeemgrens (scope) = rechthoek met systeemnaam en dus de start van de analyse.
Een actor is een entiteit de buiten het systeem staat en:
- Het systeem gebruikt
o Een kassierster wil het kassasysteem gebruiken om …
- Er een interactie mee heeft
- Ermee communiceert
Een actor is:
• Een rol die iets of iemand in de context van een systeem speelt
• Een organisatie
• Een systeem
2 soorten actoren:
• Actieve actor (staat links)
o Initieert een functionaliteit
• Passieve actor (staat rechts)
o Neemt deel (nadat een ander heeft geïnitialiseerd)
JDK 2020
,Een usecase is:
- Een geval/situatie waarvoor de gebruiker het systeem wil gebruiken
- Een doelstelling van het systeem waarvoor een of meer actoren het systeem gebruiken
- Zelfstandig naamwoord + werkwoord
o Klanten beheren, bestelling ingeven, kamer reserveren
Primaire usecases:
- Voldoet een gebruikersdoel
o Ondersteunt een hoofdfunctionaliteit van het systeem (evaluatie invullen)
- Start en eindigt een taak
- Kan op zichzelf staan, is compleet, levert een eindwaarde
- Kan in 1 sessie met het systeem voltooid worden
Om primaire usecases mogelijk te maken, zijn er vaak ondersteunende secundaire usecases nodig.
Secundaire usecases:
- Ondersteunt een functionaliteit die nodig is om een hoofdfunctionaliteit (primaire usecase)
mogelijk te maken
Voorbeeld: Het systeem moet een lijst van evaluatiecriteria kunnen tonen
- Deze evaluatiecriteria moeten ook ooit in het systeem geraken en aangepast kunnen worden
secundaire usecase toevoegen « Criteria voor evaluatie beheren »
- Het systeem moet aan een student zijn teamleden tonen
de teamsamenstelling moet ook ooit in het systeem geraken en aangepast
kunnen worden
secundaire usecase toevoegen « Teams beheren »
- Er moet een mogelijkheid zijn om de ene soort gebruiker andere autoriteiten te geven dan een
andere soort gebruiker
secundaire usecase toevoegen « Inloggen » en « registreren »
- Bevat details hoe de functionaliteit moet verlopen
- Documentatie in tekstvorm met schermontwerpen
- Een opeenvolging van interacties tussen actor en systeem met een doel
3 soorten Usecasebeschrijvingen:
1. Brief usecase: bestaat uit 1 paragraaf tekst die de usecase samenvat. Enkel successcenario.
2. Casual usecase: bestaat uit enkele paragrafen tekst, die de usecase samenvatten. Meerdere
scenario’s worden beschreven. (wij)
3. Fully dressed usecase: een formeel document gebaseerd op een gedetailleerde vaste
structuur met velden voor verschillende secties.
Structuur usecasebeschrijving
Functionaliteit:
Hier beschrijf je de functionaliteit in de vorm van een user story: hierin zeg je ‘wie’, ‘wat’, [‘waarom’]
kan: Als student, kan ik me inschrijven voor een lezing.
[Voorwaarde:]
- Optioneel. Hier beschrijf je de voorwaarde die vervuld moet zijn om de functionaliteit te
kunnen starten
- Student is ingelogd en heeft gekozen voor inschrijven voor een lezing
JDK 2020
, Normaal verloop:
- Hier beschrijf je het successcenario
- Beschrijving start op het moment nadat de actor net gekozen heeft voor de functionaliteit
- Afwisselend wat actor doet en wat systeem vervolgens doet…
- De student geeft zoektermen (onderwerp, spreker of datum) om een lezing te vinden.
Systeem geeft resultatenlijst. Student selecteert hieruit een lezing waarvoor hij zich wil
inschrijven en geeft vervolgens zijn studentennummer in waarna het systeem de inschrijving
registreert en een bevestiging naar de student stuurt.
[Alternatief verloop / uitzonderingen:]
- Optioneel. Hier beschrijf je de alternatieve scenario’s. 1 paragraaf per alternatief scenario.
- Geef eerst een korte naam voor het alternatief / de uitzondering en vervolgens wat zich
anders afspeelt dan het normaal verloop
- Lezingen volzet: Als de lezingen volzet zijn, geeft het systeem de student de mogelijkheid om
zich op de wachtlijst te zetten. Het systeem stuurt dan een aangepaste bevestiging en
registreert de student op de wachtlijst.
[Extra opmerkingen:]
- Optioneel. Hier beschrijf je extra opmerkingen die opdrachtgever bij een functionaliteit heeft
vermeld en waar rekening mee gehouden moet worden bij het uitwerken
- Wanneer de resultatenlijst te lang is, verdeelt het system de lezingen over meerdere pagina’s
waardoor de student kan bladeren.
Usecasemodellering stappenplan
1. Identificeer de grenzen van het systeem
2. Vind de actoren
3. Definieer usecases voor iedere actor
4. Beschrijf elke usecase
5. Maak een proper usecasediagram
Relaties tussen Usecases
Extend-relatie (met conditie)
De extend-relatie voegt aan het gedrag van een usecase
extra gedrag toe.
- Dit extra gedrag wordt optioneel uitgevoerd (soms wel, soms niet)
- Dit nieuwe gedrag wordt gemodelleerd in een nieuwe usecase
In het diagram wordt dit aangegeven met een onderbroken pijl met stereotype <<extend>> die
vertrekt bij de usecase met het additionele gedrag en aankomt bij de hoofdusecase.
Include-relatie
De include-relatie geeft aan dat de ene usecase gebruikmaakt
van de andere usecase waardoor het gedrag van de eerste
usecase verandert.
- Dit extra gedrag wordt altijd uitgevoerd: zonder het gedrag van de 2de usecase kan de eerste
usecase niet succesvol zijn.
- Dit extra gedrag wordt gemodelleerd in een nieuwe usecase.
In het diagram wordt dit aangegeven met een onderbroken pijl met stereotype <<include>> die
vertrekt bij de hoofdusecase en aankomt bij de benodigde usecase.
JDK 2020
Voordelen van het kopen van samenvattingen bij Stuvia op een rij:
√ Verzekerd van kwaliteit door reviews
Stuvia-klanten hebben meer dan 700.000 samenvattingen beoordeeld. Zo weet je zeker dat je de beste documenten koopt!
Snel en makkelijk kopen
Je betaalt supersnel en eenmalig met iDeal, Bancontact of creditcard voor de samenvatting. Zonder lidmaatschap.
Focus op de essentie
Samenvattingen worden geschreven voor en door anderen. Daarom zijn de samenvattingen altijd betrouwbaar en actueel. Zo kom je snel tot de kern!
Veelgestelde vragen
Wat krijg ik als ik dit document koop?
Je krijgt een PDF, die direct beschikbaar is na je aankoop. Het gekochte document is altijd, overal en oneindig toegankelijk via je profiel.
Tevredenheidsgarantie: hoe werkt dat?
Onze tevredenheidsgarantie zorgt ervoor dat je altijd een studiedocument vindt dat goed bij je past. Je vult een formulier in en onze klantenservice regelt de rest.
Van wie koop ik deze samenvatting?
Stuvia is een marktplaats, je koop dit document dus niet van ons, maar van verkoper GraduateITF. Stuvia faciliteert de betaling aan de verkoper.
Zit ik meteen vast aan een abonnement?
Nee, je koopt alleen deze samenvatting voor €5,19. Je zit daarna nergens aan vast.
