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
Les avantages d'acheter des résumés chez Stuvia:
Qualité garantie par les avis des clients
Les clients de Stuvia ont évalués plus de 700 000 résumés. C'est comme ça que vous savez que vous achetez les meilleurs documents.
L’achat facile et rapide
Vous pouvez payer rapidement avec iDeal, carte de crédit ou Stuvia-crédit pour les résumés. Il n'y a pas d'adhésion nécessaire.
Focus sur l’essentiel
Vos camarades écrivent eux-mêmes les notes d’étude, c’est pourquoi les documents sont toujours fiables et à jour. Cela garantit que vous arrivez rapidement au coeur du matériel.
Foire aux questions
Qu'est-ce que j'obtiens en achetant ce document ?
Vous obtenez un PDF, disponible immédiatement après votre achat. Le document acheté est accessible à tout moment, n'importe où et indéfiniment via votre profil.
Garantie de remboursement : comment ça marche ?
Notre garantie de satisfaction garantit que vous trouverez toujours un document d'étude qui vous convient. Vous remplissez un formulaire et notre équipe du service client s'occupe du reste.
Auprès de qui est-ce que j'achète ce résumé ?
Stuvia est une place de marché. Alors, vous n'achetez donc pas ce document chez nous, mais auprès du vendeur GraduateITF. Stuvia facilite les paiements au vendeur.
Est-ce que j'aurai un abonnement?
Non, vous n'achetez ce résumé que pour €5,19. Vous n'êtes lié à rien après votre achat.
