Requirements Engineering/het werk/werkstuk/2013-14/Groep 01

Uit Werkplaats
< Requirements Engineering‎ | het werk‎ | werkstuk‎ | 2013-14
Versie door Etienne Bruines (overleg | bijdragen) op 10 jul 2014 om 22:16
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Ga naar: navigatie, zoeken


 






Requirements voor Ibn Kalkoen



Werkstuk Requirements Engineering


Niek Janssen, Ties Robroek, Bauke Brenninkmeijer, Brandaan Brouwers, Etienne Bruines



Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen







version 18 februari 2022



Page Break




Inhoud

Introductie

Vanuit een kleine middelbare school, het Ibn Kalkoen, zijn wij benaderd voor het maken van een digitaal systeem voor het regelen van de toetsen. Dit systeem moet alles gaan regelen wat in verband staat met toetsen. Zo moeten docenten toetsen kunnen toevoegen, leerlingen de toetsen kunnen maken, docenten de antwoorden kunnen invoeren, de toets kunnen worden nagekeken, en moet je de resultaten kunnen bekijken. Dit moet natuurlijk zo gebeuren zodat een leerling niet zijn eigen resultaten kan aanpassen, of andere fraude kan worden gepleegd. Meer uitleg hierover staat in de probleemstelling hieronder

In dit bestand zullen we ingaan op wie de belanghebbende van ons systeem zijn, wat ons doel wordt in dit project, en wat ons systeem moet gaan doen in korte, duidelijke punten. Verder behandelen we de risico's die we tijdens dit project kunnen tegenkomen. Hierna zullen we dieper ingaan op de verschillende functies die ons systeem allemaal moet kunnen doen, door middel van use cases, en scenario's van deze use cases, waarbij de alternatieve en exclusieve gevallen ook een eigen scenario hebben. We zullen afsluiten met non-functionele eigenschappen, een domeinmodel van het gehele systeem, en de regels van het Ibn Kalkoen - waaronder de rechten van verschillende gebruikers van dit systeem worden behandeld.

Natuurlijk is er onderaan ook een terminologie te vinden voor alle niet onmiddellijk duidelijke termen.


Probleemstelling

De huidige situatie is als volgt: De toetsen worden bedacht door de docent, vervolgens worden deze gekopieerd voor de leerlingen, gemaakt door de leerlingen, nagekeken door de docenten, nabesproken met de leerlingen en in het archief gezet door de docent.

Dit levert veel kritieke punten op. Het gebeurt regelmatig dat een docent te weinig kopieën maakt, toetsen kwijt raken, handschriften onleesbaar zijn, enzovoorts. Een bijkomend nadeel is dat leerlingen zo gemakkelijk in staat waren af te kijken bij elkaar, of te frauderen bij het nabespreken.

Naast het feit dat er veel punten zijn waarop dit proces mis kan gaan, is het ook erg arbeidsintensief werk voor de docenten; continu de controle houden op de toetsen die in de tas liggen (i.v.m. diefstal), handschriften van scholieren ontcijferen, cijfers aanpassen en ga zo maar door. Aangezien docenten ook betaald moeten worden, is het erg duur om docenten dit werk op deze traditionele manier te laten doen.

Volgens de schoolleiding van Ibn Kalkoen moet hier verandering in komen. Veel taken zouden in een nieuw systeem van de docent overgenomen moeten worden, waardoor kosten en ergernis gereduceerd zouden moeten worden. Ook zou het beheer van een digitaal systeem een stuk minder fraudegevoelig zijn dan de huidige traditionele wijze. Immers, het idee van zo een dergelijk systeem kwam doordat buurscholen ook al met een digitaal systeem werken - waardoor deze buurscholen geen last hadden van bovengenoemde problemen.

Samenvattend zou het nieuwe systeem verbeteringen moeten aanbrengen ten opzichte van het traditionele systeem, op de volgende punten:

  • werklast voor docenten;
  • fraude door leerlingen;
  • ergernis bij leerlingen, ouders en docenten wanneer docenten fouten maken;
    • het reduceert dus ook de kans op fouten door docenten.

Analyse van de casus

Analyse van de belanghebbenden

Demografische beschrijving van belanghebbenden

We kunnen onze belanghebbenden grofweg verdelen in de volgende categorieën:

  • Directeur:
    • het hoofd van de school; eindverantwoordelijke voor alles wat er op de school gebeurt en ook degene die een GO/NO-GO voor het project kan geven.
  • Docent:
    • een persoon die één of meerdere leerlingen lesgeeft. Hij of zij moet veelvuldig met het systeem werken om bijvoorbeeld toetsen in te voeren.
  • Leerling:
    • een persoon die les krijgt van één of meerdere docenten, en na een aantal jaren zijn of haar diploma hoopt te behalen. Hij of zij moet veelvuldig met het systeem werken om bijvoorbeeld toetsen te maken. Aangezien het resultaat van de leerling mede afhankelijk is van het systeem dat gebruikt wordt, heeft een leerling er een groot belang bij in vergelijking tot de overige belanghebbenden.
  • Ouder en/of verzorger:
    • een persoon die wettelijk bevoegd is om de resultaten van één of meerdere van zijn of haar kinderen te bekijken. Een ouder gebruikt het systeem om informatie te controleren, en heeft er dus baat bij dat dit systeem gebruiksvriendelijk, snel en privacy-vriendelijk is.

We kunnen de directeur als primaire belanghebbende benoemen, omdat hij of zij volledige zeggenschap heeft over het project. Verder benoemen we de leerlingen als secundaire belanghebbenden omdat hun schoolresultaten van het systeem afhangen. Voor de overige belanghebbenden is het voornamelijk een kwestie van 'gemak'.

Lijst van belanghebbenden

Om het overzicht te bewaren hebben we ons beperkt tot drie docenten, drie leerlingen en drie ouders. In werkelijkheid zijn alle docenten, leerlingen en ouders belanghebbenden, maar zullen ze niet betrokken worden bij het project.

  • Piet Peterson, directeur;
  • Jan Janssen, docent;
  • Daniëlle Daniel, docent;
  • Bert Barendrecht, docent;
  • Sander Sanders, leerling;
  • Amber Adriaans, leerling;
  • Sanne de Slegte, leerling;
  • Vlerk Vaters, ouder en/of verzorger;
  • Marie Mutters, ouder en/of verzorger;
  • Valerie Versorger, ouder en/of verzorger.

Mission statement

Het doel van dit project is om een stabiele en efficiënte elektronische toetsomgeving te creëren voor Ibn kalkoen. Hiermee zou het onderwijs in kwaliteit moeten verbeteren door een snellere verwerking van toetsresultaten en snellere feedback voor de leerlingen. Het huidige systeem voldoet niet aan de eisen die worden gesteld en dat moet dit nieuwe systeem wel doen.

Vision statement

Met behulp van de nieuwe toetsomgeving zal de leraar-leerling interactie vlotter, duidelijker en netter worden. Het creëren, maken en nakijken van toetsen gaat hier veel makkelijker en vooral ook veiliger. Meerkeuze en eenduidige antwoorden kunnen automatisch worden nagekeken en de docent kijkt de rest handmatig na. Concreet hebben we de volgende functies behandeld:

  • Een leraar kan een toets toevoegen.
  • Een leraar kan antwoorden voor toetsen toevoegen en bestaande antwoorden wijzigen.
  • Een leerling kan zijn antwoorden en de resultaten van een toets bekijken.
  • Het nakijken van toetsen wordt automatisch gedaan.
  • De gebruikers van dit systeem krijgen rechten om bepaalde acties te kunnen uitvoeren, hiervoor moeten ze zich authenticeren tegenover het komende systeem.

Risico-analyse

Een hogere risico-rangorde geeft aan dat een bepaald risico belangrijker is dan een ander risico. Wanneer hier in een vroeg stadium rekening mee gehouden wordt, kan dit de vertraging minimaliseren.

# Categorie Risico Oplossing vereist Status Kans Dagen vertraging Risico-rangorde
01 Fysieke Gezondheid Vanwege lichamelijk letsel wordt iemand verhinderd verder te werken Direct Gesloten 10% 3 30
02 Psychische staat Een lid wordt door te hoge psychische druk verhinderd verder te werken Niet direct Gesloten 5% 3 15
03 Planning Niet op tijd beginnen Direct Gesloten 100% 2 200
04 Groepsleden Groepslid doet zijn deel niet, stopt met het baan/vak/studie Direct Gesloten 15% 4 60
05 Groepsleden Conflict tussen groepsleden
(kan leiden tot 02 en 03)
Direct Gesloten 76% 4 304
06 Communicatie Geen goede communicatie tussen groepsleden
(01 en 02 kunnen hierdoor erger worden, 05 kan hier het gevolg van zijn)
Direct Gesloten 30% 3 90
07 Werkplaats De elektronische werkplaats werkt niet naar behoren
(08 kan hier het gevolg van zijn)
Direct Gesloten 99% 2 198
08 Dataverlies Men verliest belangrijke gegevens voor het project Direct Gesloten 10% 5 50

Requirements

Use cases

Overzicht van use cases (Use case survey)

# Name Description Initiating actor
01 Authenticatie Een gebruiker authenticeert zich tegenover het systeem en krijgt hieraan verbonden rechten Docent, leerling, ouder/verzorger van leerling
02 Toetsen beheren De docent heeft de mogelijkheid toetsen in het systeem te zetten, zodat deze door de leerlingen op een later moment gemaakt kunnen worden. Ook is het mogelijk toetsen aan te passen die al eerder zijn toegevoegd. Docent
03 Antwoordresultaat verwerken Een docent voert de antwoorden van de toetsen in zodat het systeem deze automatisch kan nakijken Docent
04 Resultaten bekijken Een (ouder of verzorger van een) leerling kan hier de resultaten en antwoorden zien van door de leerling gemaakte toetsen. Leerling, ouder/verzorger van leerling
05 Toetsen nakijken De door de leerlingen gemaakte toetsen worden door de docent nagekeken. Docent

Geïntegreerde use-case diagram (Integrated use case diagram)

Op de elektronische werkplaats is ons geïntegreerde use case diagram hieronder te zien. De PDF-versie bevat helaas niet het use case diagram vanwege beperkingen van de Werkplaats. UCDgroep1.png

Individuele use cases

Op de elektronische werkplaats is onze domeinmodellen aangegeven per use case. De PDF-versie bevat helaas deze diagrammen niet vanwege beperkingen van de Werkplaats.

Authenticatie

Door Niek Janssen

UC# 01
Use Case Authenticatie
Versie 3
Note Als in dit document gerefereerd wordt naar 'een actie' wordt hiermee een actie bedoeld die binnen het systeem valt.
Beschrijving Een gebruiker authenticeert zich tegenover het systeem en krijgt hieraan verbonden rechten.
Actoren Docent, leerling, ouder/verzorger van leerling
Trigger De gebruiker onderneemt een actie waarvoor deze gebruiker ingelogd moet zijn.
Basic course of events

Authenticatie en autorisatie
1. (Trigger) De docent, leerling of ouder, hierna gebruiker, start een actie die authenticatie vereist.
2. Het systeem start de authenticatie d.m.v. een inlogformulier. Hierop kan de gebruiker een gebruikersnaam en wachtwoord invoeren.
3. De gebruiker vult het authenticatieformulier in en verstuurt het inlogformulier naar de server.
4. Het systeem kijkt of de authenticatie gelukt is en of de gebruiker de juiste rechten heeft om de actie uit te voeren. Hierna toont het een scherm waarop staat dat de authenticatie is gelukt.
5. De gebruiker start de actie waarvoor het systeem de authenticatie gestart heeft.
6. Het systeem checkt of de authenticatie nog steeds geldig is en verwerkt de resultaten van de gebruiker.
7. De gebruiker logt uit het systeem.

Alternate paths

Annuleren
x. De gebruiker annuleert het proces en logt uit het systeem. Hierna volgt stap 7.
x. De gebruiker annuleert het proces en kiest er voor om nog een andere actie te ondernemen. Hierna volgt stap 5.

Meerdere acties
7. De gebruiker kiest ervoor om nog een actie te ondernemen. Hierna volgt stap 5.

Exception paths

Niet gemachtigd
4. De gebruiker heeft niet de juiste rechten. Het systeem toont dit op het scherm. Hierna volgt stap 7.

Foutief wachtwoord
4. De gebruiker heeft niet het juiste wachtwoord ingevoerd. Het systeem toont dit op het scherm. Hierna volgt stap 3.

Niet-bestaande gebruikersaccount
4. De gebruiker heeft een onbestaand gebruikersaccount ingevoerd. Het systeem toont dit op het scherm. Hierna volgt stap 3.

Assumptie
  • Het systeem weet welke rechten aan welke acties zijn gekoppeld.
Preconditions
  • De gebruiker heeft geldige aanmeldgegevens. Hieronder vallen gebruikersnaam en wachtwoord.
Postconditions
  • Mits de authenticatie goed is gegaan zijn de resultaten van de actie op de juiste manier verwerkt.
Related business rules
  • [BR-1] Niet iedere gebruiker heeft dezelfde rechten. Deze rechten moeten duidelijk en te bewerken zijn.
  • [BR-2] Het is belangrijk dat bijgehouden wordt wie wat heeft gewijzigd.
  • [BR-3] In de meeste gevallen hebben leerlingen meerdere ouders. Deze ouders krijgen samen één ouderaccount per leerling.
Domain Model DM.png

Toetsen beheren

Door Etienne Bruines

UC# 02
Use Case Toetsen beheren
Versie

4

Beschrijving

De docent heeft de mogelijkheid toetsen in het systeem te zetten, zodat deze door de leerlingen op een later moment gemaakt kunnen worden. Ook is het mogelijk toetsen aan te passen die al eerder zijn toegevoegd.

Actoren
  • De docent
Trigger
  • Docent geeft aan toetsen toe te willen voegen.
Basic course of events

Toets toevoegen
1. (Trigger) Docent geeft aan toetsen toe te willen voegen.
2. Het systeem vraagt om algemene toetsgegevens (zie "Terminologie").
3. Docent voorziet systeem van gevraagde toetsgegevens.
4. Het systeem bevestigt dat de ingevulde gegevens correct zijn en vraagt om de toetsvragen.
5. Docent voorziet systeem van toetsvragen.
6. Het systeem bevestigt dat de toets is toegevoegd.

Alternative paths

Toets wijzigen
1. Docent geeft aan een toets te willen wijzigen. Hij gebruikt hiervoor de toetscode om de juiste toets te selecteren. Het systeem zal bij stappen 2 en 4 de eerder ingevulde gegevens meesturen - en bij stap 6 de toets niet toevoegen maar wijzigen in het systeem.

Exception paths

Fout bij algemene toetsgegevens
4. Het systeem geeft aan dat de algemene toetsgegevens incorrect zijn. Hierna volgt stap 3.

Fout bij toetsvragen en -antwoorden
6. Het systeem geeft aan dat de toetsvragen en -antwoorden niet correct zijn ingevuld. Hierna volgt stap 5.

Assumptie Indien de docent een toets wilt wijzigen, weet hij de toetscode van die toets.
Preconditions De docent moet geauthenticeerd zijn.
Postconditions De docent heeft de gewenste toets toegevoegd aan het systeem, of - indien deze al bestond - deze toets gewijzigd in het systeem.
Related business rules
  • [BR-1a-1] De docent is de enige die toetsen kan toevoegen en wijzigen.
  • [BR-4] Elke toets wordt geïdentificeerd door een toets-code.
Domain Model Groep01 ORM 2.png

Antwoordresultaat verwerken

Door Bauke Brenninkmeijer

UC# 03
Use Case: Antwoordresultaat verwerken
Beschrijving Een docent voert de antwoorden van de toetsen in zodat het systeem deze automatisch kan nakijken.
Actoren De docent
Versie 3
Triggers 1. De docent geeft aan antwoorden in te willen vullen.

2. De docent geeft aan de eerder ingevulde antwoorden te willen wijzigen.

Basic course of events Antwoorden verwerken

1. (Trigger) De docent geeft aan antwoorden in te willen vullen of deze te willen wijzigen. 2. Het systeem vraagt om welke toets het gaat.
3. De docent geeft een toetscode.
4. Het systeem geeft antwoordvelden.
5. De docent vult antwoorden in.
6. Het systeem slaat deze antwoorden op als nieuwe antwoorden voor de toets.

Alternate paths

Annuleren
x. De docent kiest ervoor de actie te annuleren. Ingevoerde antwoorden worden niet verwerkt en de use case wordt beëindigd.

Exception paths

Ongeldige toetscode
3. De docent voert een ongeldige toetscode in. De use case springt terug naar stap 2.

Assumptie De docent is bevoegd om dit soort bewerkingen uit te voeren.
Preconditions
  • De toetscode moet bestaan. (Er wordt gecontroleerd op foutieve toetscodes)
  • De docent moet geauthenticeerd zijn.
Postconditions De ingevoerde antwoorden zijn de antwoorden die vanaf dan gebruikt worden bij het nakijken van de toets met de ingevoerde toetscode.
Related business rules
  • [BR-1a-1] Alleen docenten mogen antwoorden toevoegen of wijzigen.
Domain Model Domainmodel.PNG

Resultaten bekijken

Door Ties Robroek

UC# 04
Use Case: Resultaten bekijken
Beschrijving Een (ouder of verzorger van een) leerling kan hier de resultaten en antwoorden zien van door de leerling gemaakte toetsen.
Actoren Leerling, ouder/verzorger van leerling
Versie 3
Trigger De gebruiker geeft aan de antwoorden voor een door de leerling gemaakte toets te willen bekijken.
Basic course of events

Antwoorden en resultaten bekijken
1. (Trigger) De leerling of ouder, hierna gebruiker, geeft aan de antwoorden voor een door de leerling gemaakte toets te willen bekijken.
2. Het systeem geeft een lijst met de door de leerling gemaakte toetsen.
3. De gebruiker kiest een toets uit de lijst.
4. Het systeem geeft hoe de leerling de toets heeft gemaakt samen met de juiste antwoorden.

Alternate paths

Toetscode in plaats van kiezen uit lijst
3. In plaats van een toets uit de lijst te kiezen voert de gebruiker een toetscode in. Hierna volgt gewoon stap 4.

Exception paths

Fout bij de toets
4. De gekozen toets is nog niet nagekeken. Hierna volgt stap 2.

Assumptie De toetsen zijn correct ingevoerd.
Preconditions De gebruiker is geauthenticeerd.
Postconditions De gebruiker heeft zijn resultaat en de antwoorden kunnen zien.
Related business rules
  • [BR-1b-2] De leerling kan alleen zijn eigen resultaten inzien.
  • [BR-1b-3] De leerling kan niet de antwoorden van iemand anders inzien.
  • [BR-1c-1] De ouders mogen de resultaten van de leerling inzien.
Domain Model DomeinmodelTies.png

Toetsen nakijken

Door Brandaan Brouwers

UC# 05
Use Case: Toetsen Nakijken
Versie 5
Beschrijving De door de leerlingen gemaakte toetsen worden door de docent nagekeken.
Actoren Docent
Trigger De docent geeft aan toetsen na te willen kijken
Basic course of events

Toetsen nakijken
1. (Trigger) De docent geeft aan toetsen na te willen kijken.
2. Het systeem vraagt om welke toets het gaat.
3. De docent geeft aan om welke toets het gaat.
4. Het systeem vraagt om welke leerling het gaat.
5. De docent geeft aan om welke leerling het gaat.
6. Het systeem toont de antwoorden die de gevraagde leerling heeft ingevuld bij de vragen. Het systeem toont ook de correcte antwoorden die de docent daarvoor al in het systeem heeft gezet - ter vergelijking.
7. De docent geeft commentaar op en punten voor de antwoorden die de leerling gegeven heeft. Vervolgens slaat de docent de gegevens op.
8. Het systeem bevestigt het opslaan van de gegevens en vraagt of de docent dezelfde toets van een andere leerling wilt nakijken.
9. De docent geeft aan te willen stoppen.

Alternate paths

Annuleren
x. De docent annuleert het proces.

Opnieuw nakijken
6. Het systeem ziet dat er al eerder beoordelingen zijn gegeven. Deze beoordelingen worden ook getoond aan de docent.

Een extra leerling
9. De docent geeft aan nog een toets van een leerling na te willen kijken. De use case gaat verder bij stap 4.

Exception paths

Niet gemachtigd
2. De docent is niet gemachtigd om deze resultaten te bekijken/beoordelen. De use case wordt afgebroken.

Assumptie
  • Toetsantwoorden worden opgeslagen per (deel)vraag.
  • Systeem weet welke vraag meerkeuze of open is.
Preconditions
  • De leerling heeft deze toets gemaakt.
  • De docent is geauthenticeerd.
Postconditions
  • De toetsen zijn nagekeken, met punten bij alle vragen, en commentaar bij de meesten, afhankelijk van de docent.
Related business rules
  • [BR-1a-3] Docenten mogen niet op alle toetsen commentaar leveren.
Domain Model ToetsNakijken.png

Scenario's

We hebben de keuze gemaakt om een scenario te maken per pad in de use cases. De scenario's zijn dan ook hiernaar vernoemd. Dit zorgt voor traceability tussen de Use Cases en de Scenario's.

Scenario Authenticatie - Authenticatie en autorisatie

  • Jan Janssen, wil toegang tot de toetsen van de leerlingen hebben, en wordt daarom doorgeleid naar de authenticatie-sectie.
  • Het systeem start de authenticatie met een inlogformulier - er wordt gevraagd om een gebruikersnaam en inlogcode.
  • Jan vult als zijn gebruikersnaam 'jjanssen' en als zijn wachtwoord 'welkom123!', en verstuurt het naar het systeem.
  • Het systeem controleert deze gegevens, kijkt of Jan inderdaad gemachtigd is de sectie authenticatie te openen en toont vervolgens - nadat is vastgesteld dat Jan inderdaad gemachtigd is - de lijst met toetsen.
  • Jan voert handelingen uit conform Scenario "Toetsen beheren - Toetsen toevoegen".
  • Jan logt uit.

Scenario Authenticatie - Annuleren

  • Jan Janssen, wil toegang tot de toetsen van de leerlingen hebben, en wordt daarom doorgeleid naar de authenticatie-sectie.
  • Het systeem start de authenticatie met een inlogformulier - er wordt gevraagd om een gebruikersnaam en inlogcode.
  • Jan annuleert de handeling.
  • Jan logt uit.

Scenario Authenticatie - Meerdere acties

  • Jan Janssen wil toegang tot de toetsen van de leerlingen hebben, en wordt daarom doorgeleid naar de authenticatie-sectie.
  • Het systeem start de authenticatie met een inlogformulier - er wordt gevraagd om een gebruikersnaam en inlogcode.
  • Jan vult als zijn gebruikersnaam 'jjanssen' en als zijn wachtwoord 'welkom123!', en verstuurt het naar het systeem.
  • Het systeem controleert deze gegevens, kijkt Jan inderdaad gemachtigd is de sectie authenticatie te openen en toont vervolgens - nadat is vastgesteld dat Jan inderdaad gemachtigd is - de lijst met toetsen.
  • Jan voert handelingen uit conform Scenario "Toetsen beheren - Toetsen toevoegen".
  • Jan voert handelingen uit conform Scenario "Toetsen nakijken - Toetsen nakijken".
  • Jan logt uit.

Scenario Authenticatie - Niet gemachtigd

  • Sanne de Slegte wil toegang tot de toetsen van de leerlingen hebben, en wordt daarom doorgeleid naar de authenticatie-sectie.
  • Het systeem start de authenticatie met een inlogformulier - er wordt gevraagd om een gebruikersnaam en inlogcode.
  • Sanne vult als haar gebruikersnaam 'sdeslegte' en als haar wachtwoord 'ditweettochniemand!', en verstuurt het naar het systeem.
  • Het systeem controleert deze gegevens, kijkt of de leerlinge inderdaad gemachtigd is de sectie authenticatie te openen en toont vervolgens - nadat is vastgesteld dat de leerlinge helemaal niet gemachtigd is - de melding dat ze niet gemachtigd is om de toetsen van de leerlingen te bekijken. Het systeem vraagt opnieuw om een gebruikersnaam en wachtwoord.
  • Sanne annuleert inloggen.

Scenario Authenticatie - Foutief wachtwoord

  • Sanne de Slegte wil toegang tot de toetsen van de leerlingen hebben, en wordt daarom doorgeleid naar de authenticatie-sectie.
  • Het systeem start de authenticatie met een inlogformulier - er wordt gevraagd om een gebruikersnaam en inlogcode.
  • Sanne vult als haar gebruikersnaam 'jjanssen' en als haar wachtwoord 'zouditzijnwachtwoordzijn?', en verstuurt het naar het systeem.
  • Het systeem controleert deze gegevens, kijkt of de leerlinge inderdaad gemachtigd is de sectie authenticatie te openen en toont vervolgens - nadat is vastgesteld dat het opgegeven wachtwoord niet het wachtwoord is dat past bij gebruikersnaam 'jjanssen' - de melding dat niet het juiste wachtwoord is ingevoerd. Het systeem vraagt opnieuw om een gebruikersnaam en wachtwoord.
  • Sanne annuleert en logt uit.

Scenario Authenticatie - Niet-bestaande gebruikersaccount

  • Sanne de Slegte wil toegang tot de toetsen van de leerlingen hebben, en wordt daarom doorgeleid naar de authenticatie-sectie.
  • Het systeem start de authenticatie met een inlogformulier - er wordt gevraagd om een gebruikersnaam en inlogcode.
  • Sanne vult als haar gebruikersnaam 'janssen' en als haar wachtwoord 'zouditzijnwachtwoordzijn?', en verstuurt het naar het systeem.
  • Het systeem controleert deze gegevens, kijkt of de leerlinge inderdaad gemachtigd is de sectie authenticatie te openen en toont vervolgens - nadat is vastgesteld dat de opgegeven gebruikersnaam niet bekend is in het systeem - de melding dat de gebruiker een onbestaand gebruikersaccount heeft ingevoerd. Het systeem vraagt opnieuw om een gebruikersnaam en wachtwoord.
  • Sanne annuleert en logt uit.

Scenario Toetsen beheren - Toets toevoegen

  • Jan Janssen geeft bij het systeem aan toetsen toe te willen voegen.
  • Het systeem vraagt hem om de algemene toetsgegevens.
  • Jan vult in:
    • Toetscode: NAT-T1
    • Klassen: AH1a, AH1b, G1a
    • Vak: natuurkunde
    • Toetsstof: de werking van elektriciteit - zie hfst. 1 in het boek
    • Periode: vierde kwartaal
  • Het systeem bevestigt dat deze inderdaad correct zijn ingevoerd en vraagt Jan om de toetsvragen.
  • Jan vult in:
    • Vraag 1: Hoe ziet elektriciteit eruit?
    • Vraag 2: Hoe kan men eenvoudig elektriciteit opwekken?
    • Vraag 3: Leg uit wat het verschil is tussen spanning en stroomsterkte.
  • Het systeem bevestigt dat ook dit correct is ingevoerd en dat de toets is toegevoegd aan het systeem.

Scenario Toetsen beheren - Toets wijzigen

  • Jan Janssen geeft bij het systeem aan dat hij toets NAT-T1 wil wijzigen.
  • Het systeem vraagt hem om de algemene toetsgegevens, en laat zien dat hij eerder had ingevuld:
    • Toetscode: NAT-T1
    • Klassen: AH1a, AH1b, G1a
    • Vak: natuurkunde
    • Toetsstof: de werking van elektriciteit - zie hfst. 1 in het boek
    • Periode: vierde kwartaal
  • Jan vult in:
    • Toetscode: NAT-T1
    • Klassen: AH1a, AH1b, G1a, G1b
    • Vak: natuurkunde
    • Toetsstof: de werking van elektriciteit - zie hfst. 1 in het boek
    • Periode: vierde kwartaal + de webpagina van dit vak
  • Het systeem bevestigt dat deze inderdaad correct zijn ingevoerd en vraagt Jan om de toetsvragen. Het systeem laat hierbij zien dat Jan eerder had ingevuld:
    • Vraag 1: Hoe ziet elektriciteit eruit?
    • Vraag 2: Hoe kan men eenvoudig elektriciteit opwekken?
    • Vraag 3: Leg uit wat het verschil is tussen spanning en stroomsterkte.
  • Jan vult in:
    • Vraag 1: Hoe ziet elektriciteit eruit?
    • Vraag 2: Hoe kan men elektriciteit opwekken?
    • Vraag 3: Leg uit wat het verschil is tussen spanning en stroomsterkte. Maak hierbij een tekening ter verduidelijking.
    • Vraag 4: Wat is de relatie tussen elektriciteit en magnetisme?
  • Het systeem bevestigt dat ook dit correct is ingevoerd en dat de toets is aangepast in het systeem.

Scenario Toetsen beheren - Fout bij algemene toetsgegevens

  • Jan Janssen geeft bij het systeem aan toetsen toe te willen voegen.
  • Het systeem vraagt hem om de algemene toetsgegevens.
  • Jan vult in:
    • Toetscode: NAT-T1
    • Klassen: AH1a, AH1b, G1a
    • Vak: natuurkunde
    • Toetsstof: de werking van elektriciteit - zie hfst. 1 in het boek
    • Periode: vierde kwartaal
  • Het systeem bevestigt geeft aan dat deze toetsgegevens onjuist zijn. Er bestaat namelijk al een toets met die toetscode. Het systeem vraagt opnieuw om de algemene toetsgegevens.
  • Jan vult in:
    • Toetscode: NAT-T2
    • Klassen: AH1a, AH1b, G1a
    • Vak: natuurkunde
    • Toetsstof: de werking van elektriciteit - zie hfst. 1 in het boek
    • Periode: vierde kwartaal
  • Het systeem bevestigt dat deze inderdaad correct zijn ingevoerd en vraagt Jan om de toetsvragen
  • Jan vult in:
    • Vraag 1: Hoe ziet elektriciteit eruit?
    • Vraag 2: Hoe kan men eenvoudig elektriciteit opwekken?
    • Vraag 3: Leg uit wat het verschil is tussen spanning en stroomsterkte.
  • Het systeem bevestigt dat ook dit correct is ingevoerd en dat de toets is toegevoegd aan het systeem.

Scenario Antwoordresultaat verwerken - Antwoorden toevoegen

  • Danielle Daniel geeft bij het systeem aan antwoorden te willen toevoegen bij een toets.
  • Het systeem vraagt om een toetscode.
  • Danielle vult BIO-T3 in.
  • Het systeem geeft haar antwoordvelden
  • Danielle vult in:
    • Beren
    • Rendement van energie
    • Aids
    • Nectar
    • Dinosauriërs
    • Apen
    • Ademhaling
    • Normaallijn
  • Het systeem slaat de antwoorden op als nieuwe antwoorden.

Scenario Antwoordresultaat verwerken - Toevoegen annuleren

  • Danielle Daniel geeft bij het systeem aan antwoorden te willen toevoegen bij een toets.
  • Het systeem vraagt om een toetscode.
  • Danielle annuleert het invullen.

Scenario Antwoordresultaat verwerken - Antwoorden wijzigen

  • Danielle Daniel geeft bij het systeem aan antwoorden te willen wijzigen bij een toets.
  • Het systeem vraagt om een toetscode.
  • Danielle vult BIO-T3 in.
  • Het systeem geeft antwoordvelden met oude antwoorden.
  • Danielle vult in bij veld 1:
    • Feces
  • Het systeem slaat de antwoorden op als nieuwe antwoorden.

Scenario Antwoordresultaat verwerken - Foute toetscode

  • Danielle Daniel geeft bij het systeem aan antwoorden te willen invullen bij een toets.
  • Het systeem vraagt om een toetscode.
  • Danielle vult AFNEIA in.
  • Het systeem herkent een ongeldige toetscode en gaat terug naar het scherm waar om een toetscode wordt gevraagd.
  • Danielle vult BIO-T5 in.
  • Het systeem geeft antwoordvelden.
  • Danielle vult in:
    • Celkern
    • Cytoplasma
    • Endoplasmatisch Reticulum
  • Het systeem slaat de antwoorden op als nieuwe antwoorden.

Scenario Resultaten bekijken - Antwoorden en resultaten bekijken

  • Marie mutters geeft aan de resultaten van Sander Sanders te willen bekijken
  • Het systeem geeft een lijst met de door Sander gemaakte toetsen.
  • Marie kiest toets Biologie Toets 3 (BIO-T3).
  • Het systeem geeft de resultaten van Sander met antwoorden weer.

Scenario Resultaten bekijken - Toetscode in plaats van kiezen uit lijst

  • Marie mutters geeft aan de resultaten van Sander Sanders te willen bekijken
  • Het systeem geeft een lijst met de door Sander gemaakte toetsen.
  • Marie kiest zelf een toetscode invullen en vult BIO-T3 in.
  • Het systeem geeft de resultaten van Sander met antwoorden weer.

Scenario Resultaten bekijken - Foute toetscode

  • Marie mutters geeft aan de resultaten van Sander Sanders te willen bekijken
  • Het systeem geeft een lijst met de door Sander gemaakte toetsen.
  • Marie kiest Biologie toets 4 (BIO-T4)
  • Het systeem geeft aan dat de gekozen toets nog niet is nagekeken en brengt Marie terug naar de lijst met toetsen.
  • Marie kiest Biologie toets 3 (BIO-T3)
  • Het systeem geeft de resultaten van Sander met de antwoorden weer.

Scenario Toetsen nakijken - Toetsen nakijken

  • Jan Janssen geeft bij het systeem aan toetsen na te willen kijken.
  • Het systeem vraagt aan Jan om welke toets het gaat.
  • Jan geeft aan dat het om toets NAT-T1 gaat.
  • Het systeem vraagt aan Jan om welke leerling het gaat.
  • Jan geeft aan dat het om Sanne de Slegte gaat.
  • Het systeem toont de antwoorden van Sanne en van de docent:
    • De antwoorden van Sanne:
      • Vraag 1: Elektriciteit is paars
      • Vraag 2: Door harder te fietsen met een dynamo
      • Vraag 3: Spanning is wanneer iets eng is, stroomsterkte geeft aan hoeveel spieren stroom heeft.
    • De antwoorden van de docent:
      • Vraag 1: Elektriciteit is onzichtbaar
      • Vraag 2: Door een verandering in het magnetische veld van de stroomdraad
      • Vraag 3: Stroomsterkte drukt men uit in Ampère, terwijl spanning uitgedrukt wordt in Volt.
  • Jan geeft commentaar en scores bij de antwoorden van Sanne, en slaat vervolgens op:
    • Antwoord 1: 0 punten - geen toelichting
    • Antwoord 2: 5 punten - dat is inderdaad een goede manier, maar niet wat ik bedoelde
    • Antwoord 3: 0 punten - zie boek op pagina 34
  • Het systeem bevestigt het opslaan en vraagt aan Jan of hij nog een toets van een andere leerling wilt nakijken.
  • Jan geeft aan te willen stoppen.

Scenario Toetsen nakijken - Annuleren

  • Jan Janssen geeft bij het systeem aan toetsen na te willen kijken.
  • Het systeem vraagt aan Jan om welke toets het gaat.
  • Jan geeft aan dat het om toets NAT-T1 gaat.
  • Het systeem vraagt aan Jan om welke leerling het gaat.
  • Jan geeft aan dat het om Sanne de Slegte gaat.
  • Het systeem toont de antwoorden van Sanne en van de docent:
    • De antwoorden van Sanne:
      • Vraag 1: Elektriciteit is paars
      • Vraag 2: Door harder te fietsen met een dynamo
      • Vraag 3: Spanning is wanneer iets eng is, stroomsterkte geeft aan hoeveel spieren stroom heeft.
    • De antwoorden van de docent:
      • Vraag 1: Elektriciteit is onzichtbaar
      • Vraag 2: Door een verandering in het magnetische veld van de stroomdraad
      • Vraag 3: Stroomsterkte drukt men uit in Ampère, terwijl spanning uitgedrukt wordt in Volt.
  • Jan annuleert het nakijken.

Scenario Toetsen nakijken - Opnieuw nakijken

  • Jan Janssen geeft bij het systeem aan toetsen na te willen kijken.
  • Het systeem vraagt aan Jan om welke toets het gaat.
  • Jan geeft aan dat het om toets NAT-T1 gaat.
  • Het systeem vraagt aan Jan om welke leerling het gaat.
  • Jan geeft aan dat het om Sanne de Slegte gaat.
  • Het systeem toont de antwoorden van Sanne en van de docent, tezamen met een eerdere beoordeling van Jan:
    • De antwoorden van Sanne:
      • Vraag 1: Elektriciteit is paars
      • Vraag 2: Door harder te fietsen met een dynamo
      • Vraag 3: Spanning is wanneer iets eng is, stroomsterkte geeft aan hoeveel spieren stroom heeft.
    • De antwoorden van de docent:
      • Vraag 1: Elektriciteit is onzichtbaar
      • Vraag 2: Door een verandering in het magnetische veld van de stroomdraad
      • Vraag 3: Stroomsterkte drukt men uit in Ampère, terwijl spanning uitgedrukt wordt in Volt.
    • Eerdere beoordeling van Jan:
      • Antwoord 1: 0 punten - geen toelichting
      • Antwoord 2: 5 punten - dat is inderdaad een goede manier, maar niet wat ik bedoelde
      • Antwoord 3: 0 punten - zie boek op pagina 33
  • Jan geeft commentaar en scores bij de antwoorden van Sanne, en slaat vervolgens op:
    • Antwoord 1: 0 punten - geen toelichting
    • Antwoord 2: 5 punten - dat is inderdaad een goede manier, maar niet wat ik bedoelde
    • Antwoord 3: 0 punten - zie boek op pagina 34 en tabel 3C.
  • Het systeem bevestigt het opslaan en vraagt aan Jan of hij nog een toets van een andere leerling wilt nakijken.
  • Jan geeft aan te willen stoppen.

Scenario Toetsen nakijken - Een extra leerling

  • Jan Janssen geeft bij het systeem aan toetsen na te willen kijken.
  • Het systeem vraagt aan Jan om welke toets het gaat.
  • Jan geeft aan dat het om toets NAT-T1 gaat.
  • Het systeem vraagt aan Jan om welke leerling het gaat.
  • Jan geeft aan dat het om Sanne de Slegte gaat.
  • Het systeem toont de antwoorden van Sanne en van de docent:
    • De antwoorden van Sanne:
      • Vraag 1: Elektriciteit is paars
      • Vraag 2: Door harder te fietsen met een dynamo
      • Vraag 3: Spanning is wanneer iets eng is, stroomsterkte geeft aan hoeveel spieren stroom heeft.
    • De antwoorden van de docent:
      • Vraag 1: Elektriciteit is onzichtbaar
      • Vraag 2: Door een verandering in het magnetische veld van de stroomdraad
      • Vraag 3: Stroomsterkte drukt men uit in Ampère, terwijl spanning uitgedrukt wordt in Volt.
  • Jan geeft commentaar en scores bij de antwoorden van Sanne, en slaat vervolgens op:
    • Antwoord 1: 0 punten - geen toelichting
    • Antwoord 2: 5 punten - dat is inderdaad een goede manier, maar niet wat ik bedoelde
    • Antwoord 3: 0 punten - zie boek op pagina 34 en tabel 3C.
  • Het systeem bevestigt het opslaan en vraagt aan Jan of hij nog een toets van een andere leerling wilt nakijken.
  • Jan geeft aan nog een toets van een leerling na te willen kijken.
  • Het systeem vraagt om welke leerling het gaat.
  • Jan geeft aan dat het om Amber Adriaans gaat.
  • Het systeem toont de antwoorden van Amber en die van de docent:
    • De antwoorden van Amber:
      • Vraag 1: Elektriciteit is groen
      • Vraag 2: Elektriciteit komt uit de grond; net als olie.
      • Vraag 3: ?
    • De antwoorden van de docent:
      • Vraag 1: Elektriciteit is onzichtbaar
      • Vraag 2: Door een verandering in het magnetische veld van de stroomdraad
      • Vraag 3: Stroomsterkte drukt men uit in Ampère, terwijl spanning uitgedrukt wordt in Volt.
  • Jan geeft commentaar en scores bij de antwoorden van Sanne, en slaat vervolgens op:
    • Antwoord 1: 0 punten - geen toelichting
    • Antwoord 2: 5 punten - helaas, maar nee
    • Antwoord 3: 0 punten - zie boek op pagina 34 en tabel 3C.
  • Het systeem bevestigt het opslaan en vraagt aan Jan of hij nog een toets van een andere leerling wilt nakijken.
  • De docent geeft aan te willen stoppen.

Scenario Toetsen nakijken - Niet gemachtigd

  • Sanne de Slegte geeft bij het systeem aan toetsen na te willen kijken.
  • Het systeem vertelt Sanne dat ze hier geen autorisatie voor heeft.

Niet-functionele vereisten (Non-functional Requirements)

De volgende niet-functionele vereisten zijn tot stand gekomen na het interview met de Cliënt:

  1. Een gebruiker mag geen acties ondernemen waar hij niet geautoriseerd voor is.
  2. Bestanden dienen niet, zonder dat een geautoriseerd gebruiker hiertoe opdracht heeft gegeven, verwijderd te worden.
  3. 's Nachts gaat in verband met verlaagd internetverkeer een deel van de servers uit. Door middel van trial en error zal moeten blijken hoeveel dit moet zijn. Dit kan uiteraard enkel als er genoeg internetverkeer is om meerdere servers te gebruiken en deze onafhankelijk van elkaar het hele systeem kunnen verwerken.
  4. Het laden van nieuwe pagina's mag niet langer dan 1 seconde duren bij de server. Wij zijn uiteraard niet verantwoordelijk voor traag internet etc. waardoor de laadtijden eventueel nog kunnen verhogen.
  5. Het systeem dient niet meer dan 5% downtime te hebben.
  6. De downtime moet tenzij onbedoeld altijd plaatsvinden tussen de uren 2:00 en 6:00 uur.
  7. Data van toetsen dient altijd opnieuw opgehaald te worden omdat hierbij actualiteit erg relevant is.
  8. Een persoon die geen gebruiker is mag niet door het systeem toegang worden verleent tot gegevens.
  9. Mensen kunnen niet zichzelf een gebruiker maken, dit wordt gedaan door de systeembeheerder of automatisch bij het inschrijven voor de school.
  10. Alle gegevens moeten geback-upt worden op een externe server die bij verlies van data op de primaire server data kan herstellen.

Addendum

Geïntegreerde domeinmodel

Op de elektronische werkplaats is ons geïntegreerde domeinmodel hieronder te zien. De PDF-versie bevat helaas niet het geïntegreerde domeinmodel vanwege beperkingen van de Werkplaats. DomainModel.png

Overzicht van bedrijfsregels (Business Rules Catalogue)

De volgende bedrijfsregels zijn tot stand gekomen in overleg met de Cliënt. De nummering maakt het verwijzen vanuit de Use Cases mogelijk.

  • [BR-1] Niet iedere gebruiker heeft dezelfde rechten. Deze rechten moeten duidelijk en te bewerken zijn. De gewenste accounttypes zijn:
    • [BR-1a] Leraar. Dit type gebruiker is typisch een onderwijzer of onderwijs-assistent. Zijn rechten zijn voorbehouden voor leraren - geen enkele groep heeft (een van) deze rechten. Zijn rechten zijn:
      • [BR-1a-1] Het aanmaken, bewerken of verwijderen van proefwerken dat bij een vak hoort waar hij of zij bij mag.
      • [BR-1a-2] Deze proefwerken verbergen of vrijgeven, voor elke leerling apart.
      • [BR-1a-3] De resultaten van zijn leerlingen nakijken en hier beoordelingen op geven.
    • [BR-1b] Leerling. Dit type gebruiker is een student die proefwerken op dit systeem zal gaan maken. Zijn rechten zijn:
      • [BR-1b-1] Het maken van een vrijgegeven proefwerk.
      • [BR-1b-2] Het bekijken van zijn of haar resultaten.
      • [BR-1b-3] Het bekijken van zijn en de goede antwoorden nadat deze zijn vrijgegeven en nagekeken.
      • [BR-1b-4] Het bekijken van het gemiddelde resultaat, als de leraar dit heeft vrijgegeven.
    • [BR-1c] Ouder. Ouders zijn altijd gekoppeld aan een leerling. Zijn rechten zijn:
      • [BR-1c-1] Het bekijken van de behaalde resultaten van de leerling (maar niet de antwoorden van het proefwerk zelf!)
      • [BR-1c-2] Het bekijken van het gemiddelde resultaat, als de leraar dit heeft vrijgegeven.
  • [BR-2] Het is belangrijk dat bijgehouden wordt wie wat heeft gewijzigd. Dit wordt voor de bewerkingen van leraren gedaan, evenals de "bewerkingen" van leerlingen als ze een toets maken. Ouders mogen niets bewerken en de antwoorden van leerlingen zijn automatisch gekoppeld aan deze leerling.
  • [BR-3] In de meeste gevallen hebben leerlingen meerdere ouders. Deze ouders krijgen samen één ouderaccount per leerling.
  • [BR-4] Elke toets wordt geïdentificeerd door een toets-code.

Terminologie

We gebruiken enkele vaktermen in dit document, namelijk:

  • Docent: Synoniem voor leraar.
  • Leerling: Een persoon die de kennis probeert te vergaren van een leraar.
  • Leraar: Een persoon die les geeft aan een of meer leerlingen.
  • Proefwerk: Een schriftelijke test waarin gekeken wordt of een leerling de stof begrepen heeft.
  • Toets: Synoniem voor proefwerk.
  • Algemene toetsgegevens: Een verzamelnaam voor verschillende gegevens van een toets, namelijk: wat de toets-code is, welke klassen de toets krijgen, welk vak de toets van is, een beschrijving van de stof die getoetst wordt en een periode waarin de toets afgenomen wordt.
  • Ouder: Een vader of moeder - wordt soms gebruikt om "ouder en/of verzorger" af te korten.
  • Downtime: de tijd of het percentage dat het systeem niet beschikbaar is voor gebruik.