Inleiding

Use Case Model

Hint

Neem hier het use case model / diagram op.

Use Case 1: Naam van de use case

Korte omschrijving (brief vorm)

Hint

Neem hier de korte omschrijving uit het Use Case Model over. Deze geeft een samenvattende omschrijving van 1 of 2 alinea's. Iemand die alleen de korte omschrijving leest, moet een accurate indruk krijgen van het doel van de Use Case en wat er in gebeurt. Neem zo mogelijk ook de Actor in de omschrijving op, zodat direct duidelijk wordt op wie de Use Case betrekking heeft.Bijvoorbeeld: De administratief medewerker voert pakketgegevens in, met als doel een nieuw verzekeringspakket aan te maken. Het pakket is beschikbaar voor polissen vanaf de ingangsdatum van het pakket. Elk pakket heeft een berekenwijze: per dag, per polis of procentueel.

Kenmerken

Kenmerk

Omschrijving

Aanleiding ("Trigger")

Het gaat hier om een functionele trigger, dus: wat heeft de Actor bewogen om de Use Case uit te voeren (en niet welke knop is aangeraakt zodat dit deel van het systeem beschikbaar is)

Actors

Een Actor is iemand die (of iets dat) interactie met het systeem heeft. Een Actor kan de Use Case initiëren of door de Use Case aangesproken worden. Een Actor is meestal een rolnaam (bijv. administratief medewerker).

Wijze van uitvoering

Interactief of Niet interactief (kan ook Batch zijn)

Samenhang met andere Use Cases of requirements

Verwijs hiervoor naar het betreffende Use Case diagram in het Use Case Model, zoals genoemd bij referenties. Bijvoorbeeld: Zie diagram x.x in het bij referenties genoemde Use Case Model.

Frequentie van uitvoering

Bijvoorbeeld: 20-500 x per 24 uur.


Volgorde van gebeurtenissen

Activiteitendiagram

Hint

Neem hier een activiteitendiagram op. Dit diagram geeft de samenhang van de scenario's die hierna worden beschreven weer. Geef duidelijk aan welke scenario's door welke activiteit worden gedekt.

Afbeelding 1: Voorbeeld activiteitendiagram bij Use Case: <Use Case naam>

Hint

Je kunt het scenario op meerdere manieren beschrijven, onderstaande vorm is een voorbeeld. Je mag ook de twee-kolom-notatie gebruiken, waarbij alternatieven in dezelfde tabel staan. Verder vind je in het voorbeeld enkele implementatiedetails, dat kan conflicteren met eisen/indicatoren vanuit ICA.

Basisscenario — <naam van het scenario>

Actor

Meestal zal de Actor degene zijn die reeds bij de kenmerken is genoemd. Als daar meer Actors zijn genoemd, kan het voorkomen dat een scenario voor slechts één van deze Actors is bedoeld.

Preconditie

In de preconditie staat in welke status het systeem moet zijn om het scenario te kunnen beginnen. De preconditie wordt als constatering geformuleerd. Er hoeft niet altijd een preconditie te zijn.
Voorbeeld: de medewerker is ingelogd

Scenario beschrijving

In een aantal stappen staat hier de interactie van de Actor met het systeem. Dit is altijd een 'succes scenario'; scenario's waarmee het doel van de Use Case niet gehaald wordt, worden als foutscenario's beschreven.
Voorbeeld:

  1. De medewerker geeft te kennen, een pakket te willen toevoegen.
  2. Het systeem toont het scherm 'Pakket toevoegen'.
  3. De medewerker vult pakketnaam, omschrijving, berekenwijze en ingangsdatum in en bevestigt.
  4. Het systeem valideert* de ingevulde gegevens.
  5. Het systeem slaat de gegevens op.
  6. Het systeem ververst en toont het scherm "Pakket overzicht".
    * 'valideert' wil zeggen dat de ingevulde gegevens gecontroleerd worden en goed bevonden. Dit bevordert de leesbaarheid; anders zou je moeten zeggen 'controleert' en in de volgende stap 'als de gegevens goed zijn, dan...'

Postconditie

In de postconditie formuleer je in welke status het systeem is na afronding van het scenario.



Hint

Optioneel: Hier is ruimte voor een schermontwerp, in HTML (screenshot) of als schets met andere tools. Geef het schermontwerp een bijschrift met daarin de schermtitel. In het geval dat er sprake is van een bericht, geef dan hier een voorbeeld van het bericht.

Afbeelding 2: Schermontwerp van scherm <schermtitel>
Optioneel: als er sprake is van een schermontwerp of berichtvoorbeeld, is onderstaande tabel gevuld. Hierin staan de velden die in gebruik zijn met hun karakteristieken.
Tabel 1: Beschrijving van velden bij scherm <schermtitel>

Label

Verplicht

Status

Formaat /
lengte

Validatie

Toelichting

Naam van scherm- of berichtveld
Voorbeeld: Pakketnaam

J

I

Voorbeeld: Text (30, 50)

Voorbeeld:
Bevat alleen de tekens A t/m Z, a t/m z en spatie

Deze kolom bevat verhelderende informatie die niet in een van de andere kolommen past, bijv. opbouw van een veld uit diverse andere velden, wat niet blijkt uit de screenshot. Het is niet de bedoeling, het complete schermontwerp hier te beschrijven.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Hint

Neem altijd de volgende legenda op, zodat de opdrachtgever ook weet wat de tabelelementen betekenen.

Tabel 2: Legenda bij de veldbeschrijvingstabel(len)

Label

Naam van het veld zoals dit op het scherm zichtbaar is

Verplicht

Ja, nee of n.v.t. (als een veld een output veld is, is verplicht niet van toepassing)

Status

I(nput) veld, O(utput) veld of M(uteerbaar) veld. Input, d.w.z. door de gebruiker in te vullen. Output, d.w.z. door het systeem gevuld en niet door de gebruiker te wijzigen. Muteerbaar, d.w.z. initieel door het systeem gevuld en door de gebruiker te wijzigen. Bij de waarde M moet de kolom Validatie minimaal gevuld zijn met de initiële waarde.

Formaat / lengte

Type veld (pulldown, select, radio, numeric, text, date etc.) en lengte: zowel de getoonde lengte als de door het systeem geaccepteerde maximale lengte. Bijv. een straatnaam veld kan 30 posities op het scherm weergeven maar 50 posities accepteren. Het betreffende invulvak gaat dan 'scrollen.' Het eerste getal geeft de input lengte aan. Als er één getal wordt weergegeven betekent dit dat input lengte en door het systeem geaccepteerde lengte samenvallen.

Validatie

Alle validaties / business rules die op het betreffende veld van toepassing zijn (waardebereik, formaat, verhouding tot andere velden, wijzigbaarheid, tabvolgordes etc.). Ook sorteringsspecificaties kunnen hier een plaats krijgen, evenals initiële vulling en default waarden.

Toelichting

Verhelderende informatie die niet in een van de andere kolommen past.



Alternatief Scenario 1 — <naam van het alternatieve scenario >

Actor

De Actor is meestal dezelfde als in het basisscenario. Neem in dit geval een verwijzing op.

Preconditie

De preconditie is meestal hetzelfde als in het basisscenario. Neem in dit geval een verwijzing op.

Scenario beschrijving

Het scenario vormt een alternatief voor het basisscenario. Een alternatief is bijv. betalen met credit card i.p.v. contant. Het hoofdscenario hoeft dan niet geheel te worden herhaald. Beschrijf alleen de alternatieve stappen t.o.v. het hoofdscenario.

Postconditie

In de postconditie formuleer je in welke status het systeem is na afronding van het scenario.



Hint

Optioneel: hier is ruimte voor een schermontwerp. Meestal kun je verwijzen naar het scherm bij het basisscenario, zodat er hier geen apart scherm getoond hoeft te worden. Hetzelfde geldt voor de bijbehorende tabel.

Foutscenario 1 — <naam van het foutscenario>

Actor

De Actor is meestal dezelfde als in het basisscenario. Neem in dit geval een verwijzing op.

Preconditie

De preconditie is meestal hetzelfde als in het basisscenario. Neem in dit geval een verwijzing op.

Scenario beschrijving

Het foutscenario beschrijft een situatie waarin een uitzondering optreedt in basis- of alternatief scenario. Het hoofdscenario hoeft niet geheel te worden herhaald. Beschrijf alleen de alternatieve stappen t.o.v. het hoofdscenario.
Voorbeeld:
Stap 1 t/m 3 zoals in het basisscenario, en vervolgens:

  1. Het systeem constateert dat de ingangsdatum na de maximumdatum ligt en toont het scherm "Pakket toevoegen" met onder het invulgedeelte de melding 'de ingangsdatum ligt boven de maximumdatum'.
  2. De medewerker corrigeert de ingangsdatum en bevestigt.

    Het scenario vervolgt bij stap 4 van het basisscenario.

    Als foutscenario's erg op elkaar lijken kan er een generiek foutscenario worden gemaakt, met daarbij een tabel van de foutmeldingen.

Postconditie

In de postconditie formuleer je in welke status het systeem is na afronding van het scenario.



Hint

Optioneel: hier is ruimte voor een schermontwerp. Meestal kun je een variant van het scherm bij het basisscenario maken. Hetzelfde geldt voor de bijbehorende tabel.

System Sequence Diagram


Aanvullende eisen

Hint

Optioneel: Een aanvullende eis is een requirement dat specifiek bij een Use Case hoort, maar dat niet makkelijk of op natuurlijke wijze kan worden opgenomen in een scenario. Let op dat een aanvullende eis grote impact kan hebben op de architectuur en de benodigde bouwtijd. Maak een lijst van aanvullende eisen, indien aanwezig.

Functionaliteit

Nummer

Beschrijving

Prioriteit (MoSCoW)

 

 

 


Bruikbaarheid en gebruiksvriendelijk

Nummer

Beschrijving

Prioriteit (MoSCoW)

 

 

 


Betrouwbaarheid

Nummer

Beschrijving

Prioriteit (MoSCoW)

 

 

 


Performance

Nummer

Beschrijving

Prioriteit (MoSCoW)

 

 

 


Ondersteuning

Nummer

Beschrijving

Prioriteit (MoSCoW)

 

 

 


Interfaces

Nummer

Beschrijving

Prioriteit (MoSCoW)

 

 

 


Implementatie

Nummer

Beschrijving

Prioriteit (MoSCoW)

 

 

 


Gebruiksrecht

Nummer

Beschrijving

Prioriteit (MoSCoW)

 

 

 


Domeinmodel


Overzicht Schermen

Hint

Optioneel. Als er meer schermen zijn gedefinieerd geef je hier een overzicht van de manier waarop deze schermen samenhangen; een schermverloopschema dus. Het is ook mogelijk, te verwijzen naar de Navigation Map, waar een overkoepelend schermverloopschema te vinden is.

  • No labels