Requirements Engineering/het werk/werkstuk/2011-12/Groep 04

Uit Werkplaats
Ga naar: navigatie, zoeken

 






'



Werkstuk Requirements Engineering


Martijn Liebrand, Bas Elbers, Pieter Laatum, Gijs Mooren en Ahmed Taha



Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen






version 18 februari 2022

Page Break




De inhoud is opgebouwd als volgt.

Introduction

Close Act Requirements Document [1]

Close Act is een professionele theatergroep die over de gehele wereld voorstellingen opvoert. De acts lopen zeer uiteen en het gebruik van hun eigen gemaakte kostuums en materiaal zorgen voor een uniek geheel. Het aantal artiesten dat onderdeel is van een show, kan variëren tussen de 1 en een totaal van 35 mannen en vrouwen. Er zijn uiteraard meer artiesten, maar de contracten zijn op basis van oproep. De selectie van de artiesten gebeurt door het management zelf, daarbij geldt dat de voorkeur uitgaat voor de beste artiest die de betreffende act kan doen. Behoud van artiesten is ook van belang, maar de show staat voorop.

Het unieke aspect is wat Close Act tot een succes maakt, maar tegelijkertijd ook veel vergt van de mensen binnen de organisatie. Er is geen standaard protocol wat bij elke voorstelling hetzelfde is. Alleen al het feit dat er op allerlei verschillende locaties optredens worden gegeven, zorgt voor de noodzaak tot een dynamische vorm van voorbereiden. Daarbij is de kennis van de planner(s) van cruciaal belang.

Het plannen van voorstellingen is lastig, tijdrovend en arbeidsintensief werk. De gebruiker dient zelf rekening te houden met alle werknemers, de huidige planning, kostuums, logistiek en alle geschreven en ongeschreven regels van de locatie. Bij dit laatste moet je denken aan de wet, maar ook aan de cultuur of religie. Hierbij moet ruim van tevoren al aan alles worden gedacht, van het afstemmen van het geluid vanwege mogelijk geluidsoverlast tot het regelen van een vergunning voor het afsteken van vuurwerk.

Het enige waar momenteel van gebruik wordt gemaakt om dit alles voor elkaar te krijgen, is de kennis en ervaring van het personeel. Een ondersteunend systeem die de enorme stress zou kunnen reduceren, ontbreekt volledig. Er wordt voornamelijk gebruik gemaakt van Outlook en Excel, hetzelfde als een groot kladblok waar je alles in gooit. Er bestaan templates voor o.a. een contract of speelinfo en ook is er gedacht aan de legenda voor de gebruikte labels. De templates zijn alleen geen formulieren, maar vakjes in Word. Over de labels is door het personeel al eens het volgende gezegd: "agenda labels: die liggen nu 'vast' maar eigenlijk willen we ze aanpassen maar ik ben er nog niet achter hoe ik dat kan doen in outlook".

Dit document zal de requirements bevatten voor het te maken systeem voor Close Act. Het te ontwikkelen systeem zal alle huidige functionaliteiten samenvoegen in één geheel. Hierbij is het de bedoeling dat de aparte onderdelen zodanig gelinkt worden dat het een invloed heeft op het ander. Een artiest kan nou eenmaal niet op twee plekken tegelijk zijn, dan moet het systeem dit ook niet toelaten.

Problem statement

Het huidige informatiesysteem van Close Act is dermate niet gebruiksvriendelijk dat ermee werken erg tijdrovend is. Bovendien is het een foutgevoelig systeem. Daarom wil Close Act in de toekomst een systeem dat minder tijdrovend en foutgevoelig is. Ook is Close Act niet helemaal content met de huidige werkwijze van het planner systeem. Hoewel dit systeem tot op zekere hoogte naar behoren werkt, is Close Act ervan overtuigd dat dit beter kan. Zowel voor de planners als voor de spelers die worden ingepland. Hieronder is een overzicht gemaakt.


ProblemStatement Versie1.0.png

Om deze problemen te verhelpen, dient er een geïntegreerd systeem te worden opgeleverd die tevens dezelfde functionaliteiten biedt als het huidige systeem.

De drie primaire doelen van de integratie zijn:

  1. Tijdsbesparing
  2. Foutreductie
  3. Verbetering planner systeem

Case analysis

Stakeholder analysis

Stakeholder Analysis
Stakeholder Role Description Contact
Niels Braakensiek Kantoormedewerker/Administratie Vaak Part-Time medewerkers voor planning van voorstellingen en logistiek Niels Braakensiek
Niels Braakensiek Spelers Alle spelers van alle voorstellingen Niels Braakensiek
Niels Braakensiek Ateliermedewerker Werknemers die werken aan kostuums Niels Braakensiek

Mission and vision statement

  • Mission

De primaire missie van het project zal zijn om het huidige systeem zodanig te verbeteren dat al de betrokken gebruikers efficiënter en effectiever te werk kunnen gaan. Hierbij zal voornamelijk het plannen (spelers, kostuum, agenda) centraal staan, aangezien dit momenteel nog allemaal handmatig aan elkaar gekoppeld wordt.


  • Vision

Het eindproduct zal een geïntegreerd systeem worden die de nu nog afzonderlijke deelsystemen aan elkaar koppelt. Daarbij is het streven om zoveel mogelijk werk uit de handen te nemen van de gebruikers als het gaat om planning en orderbewaking.


  • Value

De gebruikers moeten met het systeem kunnen én willen werken. Daarbij is het de bedoeling dat het systeem rust biedt door een eenvoudige en overzichtelijke werkwijze. Daarnaast zal (waarschijnlijk) de huidige flexibiliteit gewaarborgd moeten worden vanwege de complexe structuur van het geheel.

Statement of work

Deliverable Facade iteratie Huidige status Filled iteratie Huidige status Focused iteratie Huidige status Wie/Wat/Hoe/Comments
Introduction Preliminary version Green.gif Preliminary version Green.gif Complete Green.gif
Problem statement As good as possible Green.gif As good as possible Orange.gif Complete Green.gif
Stakeholder list/analysis As good as possible Orange.gif As good as possible Green.gif Complete Orange.gif
Mission-vision-(values) Complete Green.gif Complete Green.gif Complete Green.gif
Statement of work Complete, and up-to-date Orange.gif Complete, and up-to-date Green.gif Complete, and up-to-date Green.gif
Risk analysis Complete, and up-to-date Green.gif Complete, and up-to-date Green.gif Complete, and up-to-date Green.gif
Use case survey As good as possible Orange.gif Nearly complete Green.gif Complete Green.gif
Integrated UC diagram Complete (though preliminary) Orange.gif Complete Green.gif Complete Green.gif
Use cases Not yet! Lightblue.gif "Filled" level Orange.gif Complete Orange.gif
Scenarios Not yet! Lightblue.gif Several for each UC Orange.gif Complete ("focused" level) Orange.gif
Domain models Not yet! Lightblue.gif Partially complete Orange.gif Complete Green.gif
Business Rules per Use Case Not yet! Lightblue.gif Partially complete Orange.gif Complete Green.gif
Integrated domain model Not yet! Lightblue.gif Partially complete Green.gif Complete Orange.gif
Business rules catalogue Not yet! Lightblue.gif Partially complete Green.gif Complete Orange.gif
Non-functional requirements Notes Lightblue.gif Partially complete Red.gif Complete Orange.gif
Terminological definitions Notes Lightblue.gif Partially complete Green.gif Complete Orange.gif
Executive sponsor viewpoint Complete (integrated in M-V-V!) Orange.gif Complete (integrated in M-V-V!) Orange.gif Complete (integrated in M-V-V!) Orange.gif
Use case tests Notes Lightblue.gif As good as possible Red.gif Complete Red.gif
Business process definitions If available / relevant Lightblue.gif If relevant Lightblue.gif If relevant Lightblue.gif
GUI metaphors / storyboards If relevant Lightblue.gif If relevant Lightblue.gif If relevant Lightblue.gif

Legenda:
Lightblue.gif: Nog niet nodig of N.V.T.
Green.gif: Voor nu af.
Orange.gif: Moet nog naar gekeken worden.
Red.gif: Moet nog worden gedaan!

Logboek

28-03-2012 Interview stakeholder Niels
17-04-2012 Facade Deadline
19-04-2012 Mondelinge feedback Niels (12:40-13:10)
29-05-2012 Filled Deadline
22-06-2012 Focused Deadline

Risk analysis

# Category Risk Solution needed by Status Days lost Expectancy factor Risk factor
01 Groepsleden Ziekte Vanaf start project Close 10 70% 7
02 Groepsleden Afspraken niet na komen Vanaf start project Open 6 50% 3
03 Groepsleden Verlaten Cursus Vanaf start project Close 20 10% 2
04 Planning Missen Deadlines Direct na de deadline Open 10 30% 3
05 Data Data verloren (bv door tegelijk werken in wiki) Vanaf start project Afspraken worden gemaakt 4 50% 2
06 Opdrachtgever Faillissement Close Act Vanaf start project Onderzoek gevolgen belastingverhoging 100 <1% 1

Requirements

Use cases

  • UC01 Aanvraag Opstellen
  • UC02 Spelers Inplannen
  • UC03 Kostuums Inplannen
  • UC04 Optie Bevestigen
  • UC05 Spelers Beheren
  • UC06 Kostuums Beheren
  • UC07 Beschikbaarheid Bewerken
  • UC08 Acts beheren (facade maar final)

Use case survey

# Name Initiating actor Description Completeness Maturity Source Comments
01 Aanvraag Opstellen Kantoormedewerker Het opstellen / wijzigen / beheren van een (nieuwe) aanvraag. Hier wordt gekeken of de eisen van de klant kunnen worden nageleefd. Focused preliminary Interview, [2]
02 Spelers inplannen Kantoormedewerker Het inplannen van speler voor een bepaalde optie op basis van beschikbaarheid van spelers Focused preliminary Interview, [2]
03 Kostuums inplannen Kantoormedewerker Het inplannen van kostuums voor een bepaalde optie op basis van beschikbaarheid van spelers Focused preliminary Interview, [2] De vraag is of in welke stadium deze use case zal worden aangeroep. Wellicht bij het plaatsen van een optie, maar misschien wel tijdens het inplannen van een speler?
04 Optie bevestigen Kantoormedewerker Het bevestigen van een optie. Focused preliminary Interview, [2]
05 Spelers Beheren Kantoormedewerker Het toevoegen of bewerken van een speler van Close Act. Focused preliminary Interview, [2]
06 Kostuums Beheren Ateliermedewerker/ Kantoormedewerker Het toevoegen van een kostuum aan set van kostuums Focused preliminary Interview, [2]
07 Beschikbaarheid Bewerken Speler Bekijken van rooster en daarin de eigen beschikbaarheid aangeven Focused preliminary Interview, [2]
08 Acts beheren Kantoormedewerker Hier worden alle acts aangemaakt en bijgehouden. De informatie die hierbij hoort zijn welke kostuums ervoor nodig zijn en hoeveel, hoeveel spelers (optioneel), welke spelers de act kunnen uitvoeren (eventueel met een aanduiding van hoe goed) en hoe duur het is (binnen Nederland, EU en buiten de EU). Facade Preliminary (final) Interview, [2] Deze UC is niet uitgewerkt, omdat het vrij weinig toevoegt. Het moet er wel zijn om het geheel te laten werken, maar de invulling is straight-forward en arbeidsintensief.

Integrated use case diagram

RE 4 UCD.png

Individual use cases

UC01 Aanvraag Opstellen
Use Case: UC01 Aanvraag Opstellen
Description Het opstellen / wijzigen / beheren van een (nieuwe) aanvraag. Hier wordt met behulp van het systeem gekeken of de wensen van de klant kunnen worden nageleefd (dit kan samen met de klant of achteraf). Als de wensen duidelijk zijn kan er eventueel een (automatische) offerte worden gestuurd. Beide partijen kunnen echter ook zonder offerte tot een overeenkomst komen. Als beide partijen (onofficieel) akkoord zijn, dan kan een medewerker de aanvraag veranderen in een optie. Op dat moment zal alle overige informatie verzameld worden en wordt het definitieve contract opgesteld en opgestuurd.
Source Interview Niels Braakensiek
Version Focused
Trigger Medewerker wilt een aanvraag invoeren / wijzigen.
Basic course of events 
1.  De medewerker kiest in programma voor optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt de gebruiker op welke data en waar het evenement plaats zal vinden.
3.  De medewerker vult de data en locatie in.
4.  Het systeem vraagt de gebruiker om welke act(s) het gaat.
5.  De medewerker selecteert de betreffende act(s) en geeft aan dat de (getoonde) standaard kostuums van toepassing zijn.
6.  Het systeem triggert 'Spelers Inplannen' (van UC: Spelers inplannen).
7.  Het systeem komt terug uit 'Spelers Inplannen' (van UC: Spelers inplannen),
    geeft een overzicht van de nieuwe aanvraag en vraagt de gebruiker of deze door wilt gaan.
8.  De medewerker wil doorgaan naar het invoeren van de klantgegevens.
9.  Het systeem vraagt de gebruiker naar klantgegevens.
10. De medewerker vult klantgegevens in.
11. Het systeem geeft een overzicht en vraagt de gebruiker of alle gegevens juist zijn.
12. De medewerker bevestigt de aanvraag en sluit af.
Alternate paths

Optie plaatsen 

1. De medewerker kiest in het programma voor de optie: 'Optie plaatsen'.
2. Het systeem geeft de lijst weer met alle aanvragen.
3. De medewerker kiest de aanvraag die als optie geplaatst moet worden.
4. Het systeem geeft een overzicht van de aanvraag en vraagt of beide partijen (onofficieel) akkoord zijn.
5. De medewerker gaat akkoord.
6. Het systeem opent de nieuwe optie met de standaard template 'speelinfo' voor een evenement.
7. De medewerker vult eventueel in wat deze al kan invullen en sluit af.

Optie aanvullen of bewerken 

1. De medewerker kiest in programma voor optie: 'Optie aanvullen'.
2. Het systeem geeft een overzicht, met daarbij de huidige speelinfo.
3. De medewerker kiest het onderdeel (of onderdelen) en wijzigt deze / vult deze aan.
5. De medewerker bevestigt de gewijzigde speelinfo en sluit af.

Aanvraag bewerken 

1. De medewerker kiest in programma voor optie: 'Wijzigen aanvraag klant'.
2. Het systeem geeft een lijst weer van alle mogelijke onderdelen die gewijzigd kunnen worden.
3. De medewerker kiest het onderdeel (of onderdelen) en wijzigt deze.
4. Het systeem vraagt of de wijziging correct is, het oude overzicht kan worden gearchiveerd
   en het huidige overzicht dus het nieuwe overzicht wordt.
5. De medewerker bevestigt de gewijzigde aanvraag en sluit af.

Offerte maken 

1. De medewerker kiest in programma voor optie: 'Offerte maken'.
2. Het systeem geeft een lijst weer van alle huidige aanvragen.
3. De medewerker kiest de juiste aanvraag.
4. Het systeem laat een overzicht van de offerte zien en vraagt hoe de offerte moet worden uitgevoerd (mail, print, .doc, .pdf).
5. De medewerker selecteert een of meerdere opties.
6. Het systeem voert het uit en sluit af.

Nieuwe act of andere kostuums (4 mogelijke opties) 

5. De medewerker geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6. Het systeem vraagt of het een nieuwe act is, de standaard kostuums wilt wijzigen,
   of dat deze volledig handmatig kostuums wilt toevoegen.
7.1 Medewerker wilt een nieuwe act toevoegen.
  8. Het systeem triggert 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren).
  9. Het systeem komt terug uit 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren)
  Terug naar BcOE 5.

5. De medewerker geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6. Het systeem vraagt of het een nieuwe act is, de standaard kostuums wilt wijzigen,
   of dat deze volledig handmatig kostuums wilt toevoegen.
7.2 Medewerker wilt van de standaard kostuums nog eventueel kostuums toevoegen of verwijderen.
  8. Het systeem geeft de standaard kostuums bij de act weer.
  9. De medewerker wijzigt de lijst van kostuums voor deze act en bevestigt deze.
  Terug naar BcOE 6.

5. De medewerker geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6. Het systeem vraagt of het een nieuwe act is, de standaard kostuums wilt wijzigen,
   of dat deze volledig handmatig kostuums wilt toevoegen.
7.3 Medewerker wilt voor de act handmatig de kostuums toevoegen.
  8. Het systeem geeft de lijst met mogelijke kostuums.
  9. De medewerker wijzigt de lijst van kostuums voor deze act en bevestigt deze.
  Terug naar BcOE 6.

5. De medewerker geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6. Het systeem vraagt of het een nieuwe act is, de standaard kostuums wilt wijzigen,
   of dat deze volledig handmatig kostuums wilt toevoegen.
7.4 Medewerker wilt bestaande act definitief wijzigen.
  8. Het systeem triggert 'Act beheren' (van UC: Acts toevoegen / beheren).
  9. Het systeem komt terug uit 'Act beheren' (van UC: Acts toevoegen / beheren).
  Terug naar BcOE 5.

Bestaande klant invoeren 

10.1 De medewerker wil een bestaande klant invoeren.
11. Systeem vraagt naar naam of toont lijst van alle klanten.
12. Medewerker kiest klant.
  Terug naar BCoE 11.

Snelle controle beschikbaarheid 

1. De medewerker kiest in het programma voor "Snelle controle beschikbaarheid".
2. Het systeem vraagt de gebruiker op welke data en waar het evenement plaats zal vinden, binnen Nederland, EU of buiten de EU.
3. De medewerker vult de data en locatie in.
4. Het systeem vraagt de gebruiker om een lijst op basis van beschikbaarheid (of op basis van bezetting).
5. De medewerker vult in op basis van beschikbaarheid (of op basis van bezetting).
6. Het systeem geeft aan welke acts / kostuums / spelers er wel (of niet) beschikbaar zijn.
7. Medewerker slaat de lijst op / print de lijst af / mailt de lijst, en sluit af.
Exception paths

Data en/of locatie onbekend 

3.1 Medewerker geeft aan dat deze de datum/locatie/beide niet in kan voeren.
4. Het systeem vraagt de medewerker om expliciet te bevestigen dat de betreffende datum/locatie niet kan worden ingevoerd.
5. Medewerker geeft aan dat deze zich bewust is van de gevolgen voor het systeem
   en dat de aanvraag niet (volledig) in de agenda kan worden verwerkt.
  Terug naar BcOE 4

Conflict acts 

5.1 Het systeem geeft aan dat er een conflict is met een ander evenement.
6. Het systeem laat zien welk evenement een conflict geeft, inclusief act en tijdstip.
7.1 Medewerker wil het huidige evenement aanpassen
  Terug naar BCoE 4
7.2 Medewerker wil het conflict (voor nu) negeren en doorgaan.
  Terug naar BCoE 6
7.3 Medewerker wil het andere evenement aanpassen.
  8. Het systeem selecteert het andere evenement.
  Terug naar Alternate Path: "Aanvraag bewerken" 1.
7.4 Medewerker moet het onderzoeken.
  8. Het systeem zet het huidige evenement in concepten.
  9. Sluit af.
Assumptions Er bestaat iets als een 'standaard' act, waarbij het geheel wel kan afwijken, maar binnen bepaalde grenzen (bijv. 2 Aliens i.p.v. 3). Alle acts en kostuums zijn bekend en hebben een naam.
Preconditions Er is een klant die (mogelijk) een evenement bij Close Act wil boeken.
Postconditions Er is een evenement aangemaakt waar zowel Close Act als de opdrachtgever het mee eens zijn en hier kan eventueel een offerte van worden gemaakt.
Related business rules
  • Een evenement kan maximaal 2 jaar van tevoren worden ingepland.
  • Een evenement moet minimaal 1 week (7 kalenderdagen) van tevoren definitief worden.
  • De prijs voor een offerte wordt gebaseerd op de lengte van de tijd waarop de specifieke spelers en kostuums weg zijn van huis, met daarnaast de prijs van de act (en eventueel de overige verwachte kosten voor vervoer en technici).
  • Wanneer een speler al is ingepland voor een definitief optreden, dient deze niet te worden ingepland bij een andere evenement met overlappende data (inclusief vervoer heen en terug).
  • Wanneer een kostuum al is ingepland voor een definitief optreden, dient deze niet te worden ingepland bij een andere evenement met overlappende data (inclusief vervoer heen en terug).
  • Wanneer er geen alternatieven zijn voor botsende evenementen (d.w.z. een speler is niet te vervangen door andere speler(s), zodanig dat er geen conflicten meer optreden), zal het management hierover beslissen.
  • Wanneer een speler / kostuum al is ingepland voor een mogelijk optreden (dus nog niet definitief), dient deze niet te worden ingepland bij een ander evenement met overlappende data, tenzij dit niet anders kan (d.w.z. er zijn geen alternatieve spelers / kostuums inzetbaar voor dit evenement, of het botsende evenement / de botsende evenementen).
  • Een speler / kostuum kan alleen met toestemming van het management op een ander evenement worden ingepland als deze al voor een mogelijk optreden staat ingepland.
  • Bij bevestiging van een aanvraag (stap 12 BCoE, stap 5 Alt Path: 'Aanvraag bewerken'), worden (wanneer mogelijk) de statussen van de spelers, kostuums en de agenda gewijzigd in een mogelijk evenement (let op, dit is nog géén optie!).
  • Spelers / ateliermedewerkers / kantoormedewerkers / klanten worden, bij élke wijziging dat direct op hun van invloed is, schriftelijk op de hoogte gesteld (mail is schriftelijk).
  • Als er geen datum bekend is voor een evenement, terwijl de aanvraag wel is bevestigd, zullen de statussen pas worden veranderd bij invoering.
  • Wanneer er geen locatie bekend is, zal het de agenda binnen Nederland 5 transportdagen rekenen, buiten Nederland 28 transportdagen, zowel voor heen- als terugreis.
  • Een act hoeft niet per se een kostuum te bevatten en we spreken al van een act bij een optreden van één persoon.
  • Als er meerdere kostuums beschikbaar zijn met verschillende maten, wordt de juiste maat pas geselecteerd op het moment dat de daarbij behorende speler wordt geselecteerd in de planning.
  • Als een kostuum tegelijkertijd door meerdere spelers moet worden gedragen, moeten de spelers dezelfde maten hebben als het kostuum. Alle combinaties van spelers moeten daarbij te selecteren zijn.
  • Wijzigingen moeten te allen tijde kunnen worden teruggedraaid, de gegevens mogen nooit verloren gaan en er moet kunnen worden achterhaald wie wat heeft gewijzigd en wanneer.
  • Een template 'speelinfo' bij een optie, haalt de standaard informatie (d.d., plaats, act etc.) uit de originele aanvraag. Als deze standaard informatie wordt gewijzigd (dit kan alleen na een extra handeling), moet er (door het systeem) worden nagegaan of er geen conflicten optreden.
Author Bas
Date 17-05-12, 19-06-12
Additional comments

De volgorde is 'Evenement -> Act -> Kostuums -> Spelers'. Spelers kunnen meerdere kostuums hebben, maar kostuums kunnen ook meerdere spelers hebben.

ORM Model
BasElbers 0860395 ORM nieuwe aanvraag.jpg
UC02 Spelers Inplannen
Use Case: UC02 Spelers Inplannen
Use case diagram Spelers inplannen
Description Het inplannen van een speler voor een aanvraag op basis van beschikbaarheid en de kwalificaties van de spelers.
Source Interview met Niels Braakensiek
Version Focused
Triggers Deze UC wordt aangestuurd door UC01 'Aanvraag Opstellen'. Bij het opstellen van een aanvraag selecteert de medewerker hier de spelers.
Basic course of events 
1. Het systeem geeft een overzicht van de beschikbare spelers voor de acts van het specifieke evenement.
2. De medewerker kiest bij elke act één of meerdere spelers.
3. De medewerker kiest na de selectie van spelers voor opslaan.
4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
6. De medewerker gaat terug naar het overzicht (BCoE 1) of sluit af.
Alternate paths Planning wijzigen 
1.  De medewerker kiest in programma voor optie: Spelers Plannen.
2.  Het systeem geeft een overzicht van geplande evenementen.
3.  De medewerker kiest één van de getoonde evenementen.
4.  Het systeem geeft een overzicht van de geselecteerde spelers voor het evenement.
5.  De medewerker selecteert één of meerdere spelers die gepland staan.
6.  De medewerker kiest voor verwijderen van de geselecteerde spelers.
7.  Het systeem bevestigt de verwijderde speler(s).
8.  Het systeem vraagt om het toevoegen van nieuwe spelers.
9.  De medewerker kiest voor het toevoegen van nieuwe spelers aan evenement.
10. Het systeem bevestigt de toegevoegde spelers.
11. De medewerker sluit af.
Exception paths 
1.1. Het systeem kan geen beschikbare spelers tonen.
2.   De medewerker sluit af.
Preconditions Er is minimaal één act toegevoegd aan een aanvraag.
Postconditions De geselecteerde spelers zijn verbonden aan een act en het evenement.
Related business rules 
*Een speler kan niet worden ingepland als hij of zij al op een andere optie is ingepland.
*Een speler kan niet worden ingepland als hij of zij niet geschikt is voor de specifieke act.
*Wanneer het minimum aantal spelers voor een act niet is bereikt, kan een aanvraag geen optie worden.
Author Martijn, (20-06-12 Bas, sync met UC01)
Date 14-05-12
ORM Model SpelersInplannen gr4 2012.JPEG
UC03 Kostuums Inplannen
Use Case: UC03 Kostuums Inplannen
Use case diagram Kostuums Inplannen
Description Het naderhand inplannen van kostuums voor een bepaalde aanvraag.
Source Interview met Niels Braakensiek
Version Focused
Triggers Medewerker wil de kostuums van een aanvraag inzien / bewerken.
Basic course of events 
1.  De medewerker kiest in programma voor optie: Kostuum Plannen.
2.  Het systeem geeft een overzicht van alle aanvragen.
3.  De medewerker kiest één van de getoonde aanvragen.
4.  Het systeem geeft een overzicht van de gereserveerde kostuums voor de aanvraag, per act en het totaal.
5.  De medewerker kiest één of meerdere kostuums die gepland staan, of wilt doorgaan naar BCoE 9.
6.  De medewerker kiest voor verwijderen van de geselecteerde kostuums.
7.  Het systeem bevestigt de verwijderde kostuums.
8.  Het systeem vraagt om toevoegen van nieuwe kostuums.
9.  De medewerker kiest voor het toevoegen van één of meerdere nieuwe kostuums aan de act(s), of sluit af.
10. Het systeem bevestigt de toegevoegde kostuums.
11. De medewerker sluit af.
Alternate paths 
1. De medewerker kiest in programma voor optie: Kostuums Inzien.
2. Het systeem geeft een overzicht van alle aanvragen.
3. De medewerker kiest één van de getoonde aanvragen.
4. Het systeem geeft een overzicht van de gereserveerde kostuums voor de aanvraag, per act en het totaal.
5. Het systeem vraagt of het overzicht moet worden uitgevoerd (mail, print, .doc, .pdf).
6. De medewerker selecteert een of meerdere opties.
7. Het systeem voert uit en sluit af.
Exception paths
Preconditions Een aanvraag is aangemaakt in UC01 'Aanvraag Opstellen'.
Postconditions Er zijn kostuums toegevoegd of verwijderd.
Related business rules 
*Een kostuum kan niet ingepland worden als het defect is.
*Een kostuum kan niet ingepland worden als het al gepland staat op een ander evenement.
*..
Author Martijn, (21-06-12, Bas sync UC01)
Date 16-05-12
ORM Model KostuumsInplannen gr4 2012.JPEG
UC04 Optie Bevestigen
Use Case: UC04 Optie Bevestigen
Use case diagram Optie Bevestigen
Description Het bevestigen van optie. Vanaf dit moment is er geen weg meer terug, voor beide partijen niet. Betrokkenen zullen geïnformeerd worden.
Source Interview met Niels Braakensiek
Version Focused
Trigger Het contract is door de klant getekend en retour.
Basic course of events 
1. De medewerker kiest in programma voor optie: Optie Bevestigen
2. Het systeem geeft een overzicht van alle lopende opties.
3. De medewerker kiest uit het overzicht één optie.
4. Het systeem laat de optie van het evenement zien, inclusief alle cruciale elementen.
5. De medewerker kiest voor bevestigen en vastleggen van de optie.
6. Het systeem bevestigt dat de optie geplaatst is.
Alternate paths
Preconditions De planning rond het evenement is (zo goed als) compleet en er is een contract getekend door beide partijen.
Postconditions Een compleet en definitief evenement. Alle betrokkenen zijn geïnformeerd.
Related business rules 
*Ieder definitief evenement heeft alle cruciale elementen van de planning geregeld.
*Spelers / ateliermedewerkers / kantoormedewerkers / klanten worden, 
   bij élke wijziging dat direct op hun van invloed is, schriftelijk op de hoogte gesteld.
*..
Author Martijn, (21-06-12, Bas sync UC01)
Date 16-05-12
ORM Model OptiePlaatsen gr4 2012.JPEG
UC05 Spelers Beheren
Use Case: UC05 Spelers Beheren
Use case diagram Spelers Beheren
Description Het toevoegen of bewerken van een speler van Close Act.
Source Interview met Niels Braakensiek
Version Focused
Basic course of events 
1.  De medewerker kiest in programma voor optie: Speler Toevoegen.
2.  Het systeem vraagt wie er toegevoegd moet worden.
3.  De medewerker voert voor- en achternaam in.
4.  Het systeem vraagt in welke acts de toe te voegen speler betrokken is.
5.  De medewerker selecteert minimaal één act waaraan de nieuwe speler gebonden is.
6.  De medewerker bevestigt de gebonden act(s).
7.  Het systeem vraagt aan welke kostuums de speler gebonden moet worden.
8.  De medewerker selecteert één of meerdere kostuums en bevestigt.
9.  Het systeem vraagt naar de volgende gegevens:
    (Volledige: NAW, geboortedatum, e-mailadres en telefoonnummer)
10. De medewerker vult de gevraagde gegevens in en bevestigt.
11. Het systeem vraagt om de default beschikbaarheid van de speler.
12. De medewerker vult de default beschikbaarheid in van de speler.
13. Het systeem geeft aan dat een speler is toegevoegd.
Alternate paths Bewerken van bestaande speler:
4.1. Het systeem geeft aan dat de speler al bestaat.
5.   Het systeem vraagt of de bestaande speler moet worden aangepast.
6.   De medewerker geeft aan de speler te willen aanpassen.
7.   Het systeem geeft de aan te passen gegevens weer.
8.   De medewerker selecteert het aan te passen gegeven.
9.   Het systeem geeft mogelijkheid tot aanpassen.
10.  De medewerker past gegevens aan en bevestigt.
11.  Het systeem controleert en sluit af.
Missen van informatie:
2.1. Het systeem vraagt wie er toegevoegd moet worden.
3.   De medewerker voert voor- en/of achternaam in.
4.   Terug naar BCoE 4

4.2. Het systeem vraagt in welke acts de toe te voegen speler betrokken is.
5.   De medewerker selecteert overslaan.
6.   Terug naar BCoE 7

7.1. Het systeem vraagt aan welke kostuums de speler gebonden moet worden.
8.   De medewerker selecteert overslaan.
9.   Terug naar BCoE 9

9.1. Het systeem vraagt naar de volgende gegevens:
     (Volledige: NAW, geboortedatum, e-mailadres en telefoonnummer)
10.  De medewerker vult zo veel mogelijk in en bevestigt.
11.  Terug naar BCoE 11
Exception paths -
Preconditions Er is een nieuwe speler of er is een speler om de gegevens van te bewerken.
Postconditions Speler is toegevoegd of een speler is aangepast.
Related business rules 
*Iedere speler heeft als gegevens minimaal een naam.
*..
Author Martijn
Date 14-05-12
ORM Model SpelerToevoegen gr4 2012.JPEG
UC06 Kostuums Beheren
Use Case: UC06 Kostuums Beheren
Use case diagram Kostuums Beheren
Description Het toevoegen of bewerken van een kostuum.
Source Interview Niels Braakensiek
Version Focused
Basic course of events 
1.  De medewerker kiest in programma voor optie: Kostuum Toevoegen.
2.  Het systeem vraagt aan welke act een kostuum wordt toegevoegd.
3.  De medewerker selecteert één act en bevestigt haar keuze.
4.  Het systeem laat een overzicht van alle kostuums van de act zien.
5.  De medewerker kiest voor Toevoegen Kostuum.
6.  Het systeem vraagt om de volgende gegevens:
    *Maatrichtlijn (S/M/L)
    *Status van Kostuum (Goed/Slecht/Defect)
    *Gebonden personen (Onbeperkt aantal geschikte mensen)
7.  De medewerker geeft de gegevens en bevestigt.
8.  Het systeem vraagt of het kostuums gebonden moet zijn aan meerdere acts.
9.  De medewerker selecteert 0 of meerdere acts en bevestigt.
10. Het systeem bevestigt een nieuwe toegevoegd kostuum.
Alternate paths Kostuum Aanpassen:
5.1. De medewerker kiest voor één van de kostuums uit het overzicht.
Terug naar BCoE 6.
Preconditions Er zijn acts aanwezig.
Postconditions Een nieuw kostuum is gebonden aan een act of een kostuum is aangepast.
Related business rules 
*Het standaard aantal personen dat in één kostuum past is 1, tenzij anders aangegeven.
Author Martijn
Date 15-05-12
ORM Model KostuumToevoegen gr4 2012.JPEG
UC07 Beschikbaarheid Bewerken
Use Case: UC07 Beschikbaarheid Bewerken
Use case diagram Beschikbaarheid Bewerken
Description Bekijken van rooster en daarin de eigen beschikbaarheid aangeven.
Source Interview met Niels Braakensiek
Version Focused
Basic course of events 
1. De medewerker kiest in programma voor optie: Beschikbaarheid Aanpassen
2. Het systeem vraagt voor welke speler de beschikbaarheid moet worden aangepast.
3. De medewerker voert in om welke speler het gaat.
4. Het systeem geeft een overzicht van de huidige beschikbaarheid.
5. De medewerker kan de beschikbaarheid van de speler aanpassen.
6. Het systeem keurt de aanpassing goed.
7. De medewerker sluit af of keert terug naar BCoE 4.
Alternate paths Speler Log-In:
1. De speler logt in met een eigen account.
2. Het systeem toont een overzicht van de beschikbaarheid.
3. De speler kan de beschikbaarheid van zijn agenda aanpassen.
4. Het systeem keurt de aanpassing goed.
5. Speler sluit af of keert terug naar Alternate Path 2.
Exception paths: Fout medewerker:
6.1. Het systeem keurt de aanpassing af. 
7.   Het systeem geeft aan met welke regel de aanpassing in conflict is.
8.   De medewerker sluit af of keert terug naar BCoE 4.
Fout Speler:
4.1. Het systeem keurt de aanpassing af.
5.   Het systeem geeft aan met welke regel de aanpassing in conflict is.
6.   De speler sluit af of keert terug naar Alternate Path 2.
Preconditions De betreffende speler staat in het systeem
Postconditions De beschikbaarheid van de speler is up to date.
Related business rules 
* Iedere speler kan zichzelf niet vrij gegeven voor een geplande opdracht.
* Iedere speler kan zijn eigen beschikbaarheid niet veranderen voor een datum binnen x dagen/weken.
* ..
Author Martijn
Date 15-05-12
ORM Model BeschikbaarheidAanpassen gr4 2012.JPEG

Domain Model per Use Case

Scenarios

Aanvraag Opstellen

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Het systeem vraagt Steven om welke act(s) het gaat.
5.  Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
6.  Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
7.  Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
8.  Steven wil doorgaan naar het invoeren van de klantgegevens.
9.  Het systeem vraagt Steven naar klantgegevens.
10. Steven vult de gegevens van park Sonsbeek in.
11. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
12. Steven bevestigt de aanvraag en sluit af.

1. Steven kiest in het programma voor de optie: 'Optie plaatsen'.
2. Het systeem geeft de lijst weer met alle aanvragen.
3. Steven kiest de aanvraag van Park Sonsbeek, om hiervan een optie te maken.
4. Het systeem geeft een overzicht van de aanvraag en vraagt of beide partijen (onofficieel) akkoord zijn.
5. Steven gaat akkoord.
6. Het systeem opent de nieuwe optie met de standaard template 'speelinfo' voor een evenement.
7. Steven vult in wat hij al weet, dat zijn de data, acts en speciale verzoeken.

1. Steven kiest in het programma voor de optie: 'Optie aanvullen'.
2. Het systeem geeft een overzicht, met daarbij de huidige speelinfo.
3. Steven kiest voor het onderdeel Speciale verzoeken en vult in dat er maar beperkte ruimte beschikbaar is
4. Steven bevestigt de gewijzigde speelinfo en sluit af.

1. Steven kiest in programma voor optie: 'Wijzigen aanvraag klant'.
2. Het systeem geeft een lijst weer van alle mogelijke onderdelen die gewijzigd kunnen worden.
3. Steven kiest de datum van het evenement en veranderd deze vaan 25 en 26 April.
4. Het systeem vraagt of de wijziging correct is, het oude overzicht kan worden gearchiveerd
   en het huidige overzicht dus het nieuwe overzicht wordt.
5. Steven bevestigt de gewijzigde aanvraag en sluit af.

1. Steven kiest in het programma voor de optie: 'Offerte maken'.
2. Het systeem geeft een lijst weer van alle huidige aanvragen.
3. Steven kiest de aanvraga van Park Sonsbeek.
4. Het systeem laat een overzicht van de offerte zien en vraagt hoe de offerte moet worden uitgevoerd (mail, print, .doc, .pdf).
5. Steven selecteert de opties mail en .pdf.
6. Het systeem voert het uit en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Het systeem vraagt Steven om welke act(s) het gaat.
5.  Steven geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6.  Het systeem vraagt of het een nieuwe act is, de standaard kostuums wil wijzigen, of dat deze volledig handmatig kostuums wil toevoegen.
7.  Steven wil een nieuwe act toevoegen.
8.  Het systeem triggert 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren).
	1. ?????
9.  Het systeem komt terug uit 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren)
10. Steven wil doorgaan naar het invoeren van de klantgegevens.
11. Het systeem vraagt Steven naar klantgegevens.
12. Steven vult de gegevens van park Sonsbeek in.
13. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
14. Steven bevestigt de aanvraag en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Het systeem vraagt Steven om welke act(s) het gaat.
5.  Steven geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6.  Het systeem vraagt of het een nieuwe act is, Steven de standaard kostuums wil wijzigen,
    of dat hij volledig handmatig kostuums wil toevoegen.
7   Steven wil een nieuwe act toevoegen.
8.  Het systeem triggert 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren).
	1. ???
9.  Het systeem komt terug uit 'Nieuwe act toevoegen' (van UC: Acts toevoegen / beheren)
10. Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
11. Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
12. Steven wil doorgaan naar het invoeren van de klantgegevens.
13. Het systeem vraagt Steven naar klantgegevens.
14. Steven vult de gegevens van park Sonsbeek in.
15. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
16. Steven bevestigt de aanvraag en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Het systeem vraagt Steven om welke act(s) het gaat.
5.  Steven geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6.  Het systeem vraagt of het een nieuwe act is, Steven de standaard kostuums wil wijzigen,
    of dat hij volledig handmatig kostuums wil toevoegen.
7.  Steven wil bij de standaard kostuums van de alienact een kostuum toevoegen.
8.  Het systeem geeft de standaard kostuums bij de act weer.
9.  Steven voegt een kostuum toe aan de lijst met standaardkostuums.
10. Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
11. Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
12. Steven wil doorgaan naar het invoeren van de klantgegevens.
13. Het systeem vraagt Steven naar klantgegevens.
14. Steven vult de gegevens van park Sonsbeek in.
15. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
16. Steven bevestigt de aanvraag en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Het systeem vraagt Steven om welke act(s) het gaat.
5.  Steven geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6.  Het systeem vraagt of het een nieuwe act is, Steven de standaard kostuums wil wijzigen,
    of dat hij volledig handmatig kostuums wil toevoegen.
7.  Steven wil voor de act handmatig de kostuums toevoegen.
8.  Het systeem geeft de lijst met mogelijke kostuums.
9.  Steven geeft aan dat bij de act twee alienkostuums en een insectenkostuum horen..
10. Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
11.  Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
12.  Steven wil doorgaan naar het invoeren van de klantgegevens.
13.  Het systeem vraagt Steven naar klantgegevens.
14.  Steven vult de gegevens van park Sonsbeek in.
15.  Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
16.  Steven bevestigt de aanvraag en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Het systeem vraagt Steven om welke act(s) het gaat.
5.  Steven geeft aan dat het niet gaat om de standaard kostuums of een standaard act.
6.  Het systeem vraagt of het een nieuwe act is, Steven de standaard kostuums wil wijzigen,
    of dat hij volledig handmatig kostuums wil toevoegen.
7   Steven wil de bestaande alienact definitief wijzigen.
8.  Het systeem triggert 'Act beheren' (van UC: Acts toevoegen / beheren).
	1. ??????
9.  Het systeem komt terug uit 'Act beheren' (van UC: Acts toevoegen / beheren).
10. Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
11. Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
12. Steven wil doorgaan naar het invoeren van de klantgegevens.
13. Het systeem vraagt Steven naar klantgegevens.
14. Steven vult de gegevens van park Sonsbeek in.
15. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
16. Steven bevestigt de aanvraag en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Het systeem vraagt Steven om welke act(s) het gaat.
5.  Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
6.  Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
7.  Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
8.  Steven wil doorgaan naar het invoeren van de klantgegevens.
9.  Het systeem vraagt Steven naar klantgegevens.
10. Steven wil een bestaande klant invoeren.
11. Systeem vraagt naar naam en toont lijst van alle klanten.
12. Steven zoekt naar "Sonsbeek" en klikt dit in de lijst aan.
13. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
14. Steven bevestigt de aanvraag en sluit af.

1. Steven kiest in het programma voor "Snelle controle beschikbaarheid".
2. Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden, binnen Nederland, EU of buiten de EU.
3. Steven vult in dat het om 10 t/m 17 September gaat, in een land buiten Nederland, maar binnen de EU.
4. Het systeem vraagt Steven om een lijst op basis van beschikbaarheid (of op basis van bezetting).
5. Steven vult een lijst op basis van beschikbaarheid in.
6. Het systeem geeft aan welke acts / kostuums / spelers er wel (of niet) beschikbaar zijn.
7. Steven slaat de lijst op, print de lijst uit en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
5.  Het systeem geeft aan dat er een conflict is met een ander evenement.
6.  Het systeem laat zien welk evenement een conflict geeft, inclusief act en tijdstip.
7.  Steven wil het huidige evenement aanpassen.
8.  Het systeem vraagt Steven om welke act(s) het gaat.
9.  Steven selecteert de insectenact en geeft aan dat de standaardkostuums van toepassing zijn.
10. Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
11. Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
12. Steven wil doorgaan naar het invoeren van de klantgegevens.
13. Het systeem vraagt Steven naar klantgegevens.
14. Steven vult de gegevens van park Sonsbeek in.
15. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
16. Steven bevestigt de aanvraag en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
5.  Het systeem geeft aan dat er een conflict is met een ander evenement.
6.  Het systeem laat zien welk evenement een conflict geeft, inclusief act en tijdstip.
7   Steven wil het conflict (voor nu) negeren en doorgaan.
8.  Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
9.  Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
10. Steven wil doorgaan naar het invoeren van de klantgegevens.
11. Het systeem vraagt Steven naar klantgegevens.
12. Steven vult de gegevens van park Sonsbeek in.
13. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
14. Steven bevestigt de aanvraag en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
4.  Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
5.  Het systeem geeft aan dat er een conflict is met een ander evenement.
6.  Het systeem laat zien welk evenement een conflict geeft, inclusief act en tijdstip.
7   Steven wil het andere evenement aanpassen.
8.  Het systeem selecteert het andere evenement.
9.  Het systeem geeft een lijst weer van alle mogelijke onderdelen die gewijzigd kunnen worden.
10. Steven kiest de datum van het evenement en veranderd deze vaan 25 en 26 April.
11. Het systeem vraagt of de wijziging correct is, het oude overzicht kan worden gearchiveerd
    en het huidige overzicht dus het nieuwe overzicht wordt.
12. Steven bevestigt de gewijzigde aanvraag en sluit af.
13. Het systeem selecteert het eerste evenement.
14. Het systeem triggert 'Spelers Inplannen'.
	1. Het systeem geeft een overzicht van de beschikbare spelers voor de act van dit evenement.
	2. Steven kiest bij elke act voor Maurits, Martijn en Annika als spelers.
	3. Steven kiest na de selectie van spelers voor opslaan.
	4. Het systeem geeft aan of bij elke act het minimum aantal spelers zijn geselecteerd.
	5. Het systeem bevestigt de geselecteerde spelers voor het evenement.
	6. Steven gaat terug naar het overzicht.
15. Het systeem komt terug uit 'Spelers Inplannen' en geeft een overzicht van de nieuwe aanvraag en vraagt Steven door wil gaan.
16. Steven wil doorgaan naar het invoeren van de klantgegevens.
17. Het systeem vraagt Steven naar klantgegevens.
18. Steven vult de gegevens van park Sonsbeek in.
19. Het systeem geeft een overzicht en vraagt Steven of alle gegevens juist zijn.
14. Steven bevestigt de aanvraag en sluit af.

1.  Steven kiest in het programma voor de optie: 'Nieuwe aanvraag klant'.
2.  Het systeem vraagt Steven op welke data en waar het evenement plaats zal vinden.
3.  Steven vult de 24 en 25 April 2013 als data en Park Sonsbeek als locatie in.
5.  Steven selecteert de Alien act en geeft aan dat de standaardkostuums van toepassing zijn.
6.  Het systeem geeft aan dat er een conflict is met een ander evenement.
7.  Het systeem laat zien welk evenement een conflict geeft, inclusief act en tijdstip.
8   Steven moet het onderzoeken.
9.  Het systeem zet het huidige evenement in concepten.
10. Steven sluit af.

spelers inplannen

1.  Steven kiest in het programma voor de optie: Spelers Plannen.
2.  Het systeem geeft een overzicht van geplande evenementen.
3.  Steven kiest het evenement in park Sonsbeek.
4.  Het systeem geeft een overzicht van de geselecteerde spelers voor het evenement.
5.  Steven selecteert Maurits, die gepland staan.
6.  Steven kiest voor verwijderen van de geselecteerde speler.
7.  Het systeem bevestigt de verwijderde speler(s).
8.  Het systeem vraagt om het toevoegen van nieuwe spelers.
9.  Steven kiest ervoor om Nico aan het evenement toe te voegen.
10. Het systeem bevestigt de toegevoegde spelers.
11. Steven sluit af.

Kostuums inplannen

1. Steven kiest in programma voor optie: Kostuums Inzien.
2. Het systeem geeft een overzicht van alle aanvragen.
3. Steven kiest de aanvraag van Park Sonsbeek.
4. Het systeem geeft een overzicht van de gereserveerde kostuums voor de aanvraag, per act en het totaal.
5. Het systeem vraagt of het overzicht moet worden uitgevoerd (mail, print, .doc, .pdf).
6. Steven selecteert email en .pdf.
7. Het systeem voert uit en sluit af.

Optie bevestigen

1. Steven kiest in programma voor optie: Optie Bevestigen
2. Het systeem geeft een overzicht van alle lopende opties.
3. Steven kiest uit het overzicht de optie van park Sonsbeek.
4. Het systeem laat de optie van het evenement zien, inclusief alle cruciale elementen.
5. Steven kiest voor bevestigen en vastleggen van de optie.
6. Het systeem bevestigt dat de optie geplaatst is.
7. Het systeem stuurt een e-mail naar alle betrokkenen bij het evenement.

Spelers beheren

1.  Steven kiest in programma voor optie: Speler Toevoegen.
2.  Het systeem vraagt wie er toegevoegd moet worden.
3.  Steven voert "Wouter de Vries" in.
4.  Het systeem vraagt in welke acts de toe te voegen speler betrokken is.
5.  Steven selecteert de alien en insectenact.
6.  Steven bevestigt de gebonden act(s).
7.  Het systeem vraagt aan welke kostuums de speler gebonden moet worden.
8.  Steven selecteert een insectenpak en een alienpak in maat L.
9.  Het systeem vraagt naar de volgende gegevens:
    (Volledige: NAW, geboortedatum, e-mailadres en telefoonnummer)
10. Steven vult in:
	21-10-1982, devries_wouter@example.net, 012-3456789.
11. Het systeem vraagt om de default beschikbaarheid van de speler.
12. Steven vult de default beschikbaarheid in van de speler.
13. Het systeem geeft aan dat een speler is toegevoegd.

1.  Steven kiest in programma voor optie: Speler Toevoegen.
2.  Het systeem vraagt wie er toegevoegd moet worden.
3.  Steven voert "Maurits de Jonge" in.
4.  Het systeem geeft aan dat de speler al bestaat.
5.  Het systeem vraagt of de bestaande speler moet worden aangepast.
6.  Steven geeft aan de speler te willen aanpassen.
7.  Het systeem geeft de aan te passen gegevens weer.
8.  Steven selecteert het emailadres.
9.  Het systeem geeft mogelijkheid tot aanpassen.
10. Steven voert in: "mauritsdejonge@example.net" en bevestigt.
11. Het systeem controleert en sluit af.

Kostuums beheren

1.  Steven kiest in programma voor optie: Kostuum Toevoegen.
2.  Het systeem vraagt aan welke act een kostuum wordt toegevoegd.
3.  Steven selecteert de alienact.
4.  Het systeem laat een overzicht van alle kostuums van de act zien.
5.  Steven kiest voor Toevoegen Kostuum.
6.  Het systeem vraagt om de volgende gegevens:
    	*Maatrichtlijn (S/M/L)
    	*Status van Kostuum (Goed/Slecht/Defect)
    	*Gebonden personen (Onbeperkt aantal geschikte mensen)
7.  Steven geeft de gegevens: 
	*Maatrichtlijn: L
	*status van kostuum: Goed
	*Gebonden personen: Maurits, Wouter, Miranda
8.  Het systeem vraagt of het kostuums gebonden moet zijn aan meerdere acts.
9.  Steven selecteert de alienact.
10. Het systeem bevestigt een nieuw toegevoegd kostuum.

1.  Steven kiest in programma voor optie: Kostuum Toevoegen.
2.  Het systeem vraagt aan welke act een kostuum wordt toegevoegd.
3.  Steven selecteert de alienact.
4.  Het systeem laat een overzicht van alle kostuums van de act zien.
5.  Steven kiest voor het maat L alienpak.
6.  Het systeem vraagt om de volgende gegevens:
    	*Maatrichtlijn (S/M/L)
    	*Status van Kostuum (Goed/Slecht/Defect)
    	*Gebonden personen (Onbeperkt aantal geschikte mensen)
7.  Steven geeft de gegevens: 
	*Maatrichtlijn: L
	*status van kostuum: Defect
	*Gebonden personen: Maurits, Wouter, Miranda
8.  Het systeem vraagt of het kostuums gebonden moet zijn aan meerdere acts.
9.  Steven selecteert de alienact.
10. Het systeem bevestigt een veranderd kostuum.

Beschikbaarheid bewerken

1. Steven kiest in programma voor optie: Beschikbaarheid Aanpassen
2. Het systeem vraagt voor welke speler de beschikbaarheid moet worden aangepast.
3. Steven voert in dat het om Annika gaat.
4. Het systeem geeft een overzicht van de huidige beschikbaarheid.
5. Steven geeft aan dat Annika de tweede week van maart 2013 niet beschikbaar is.
6. Het systeem keurt de aanpassing goed.
7. Steven sluit af of kiest nog een speler om te bewerken.

1. Nico logt in met een eigen account.
2. Het systeem toont een overzicht van de beschikbaarheid.
3. De speler geeft aan dat hij de komende vier weken nit op vrijdag beschikbaar is.
4. Het systeem keurt de aanpassing goed.
5. Speler sluit af.

1. Steven kiest in programma voor optie: Beschikbaarheid Aanpassen
2. Het systeem vraagt voor welke speler de beschikbaarheid moet worden aangepast.
3. Steven voert in dat het om Annika gaat.
4. Het systeem geeft een overzicht van de huidige beschikbaarheid.
5. Steven geeft aan dat Annika komkende vrijdag niet beschikbaar is.
6. Het systeem keurt de aanpassing af. 
7. Het systeem geeft aan dat de beschikbaarheid niet aangepast mag worden voor een al geplanned evenement in de komende 7 dagen.
8. Steven sluit af.

1. Nico logt in met een eigen account.
2. Het systeem toont een overzicht van de beschikbaarheid.
3. De speler geeft aan dat hij de komende vier weken niet op vrijdag beschikbaar is.
4. Het systeem keurt de aanpassing af.
5. Het systeem geeft aan dat hij zijn beschikbaarheid niet mag veranderen voor de komende vrijdag, omdat  dat over 3 dagen is.
6. Nico sluit af.

Non-functional Requirements

Hieronder zijn de non functional requirements opgesomd die worden verwacht bij het nieuwe systeem. Bij elke requirement is beknopt toegelicht waarom deze voor het nieuwe systeem van Close Act van toegevoegde waarde is.


Authorization:
Middels een gebruikersnaam en wachtwoord krijgt bevoegd personeel toegang tot het systeem.


Authentication:
Alleen medewerkers van Close Act en externe personen die hier voorafgaand permissie voor hebben gekregen, mogen toegang hebben tot het systeem. Voorts dient het systeem beperkte toegang te kunnen bieden aan de verschillende betrokken partijen. Denk hierbij aan de mogelijkheden om als speler het profiel van een medespeler te kunnen inzien.


Availability: Het is van belang dat het systeem zoveel mogelijk up and running is.
Het systeem dient een zeer beperkte down time period te kennen. Met name tijdens werktijden van Close Act dient het systeem zelden een down time te kennen.


Data integrity:
Persoonlijke profielinformatie mag niet gewijzigd kunnen worden door derden of verloren gaan.


Operability:
Voor de planners dient de mogelijkheid te bestaan om eventuele beperkingsregels in te stellen. Denk aan een act waarbij de planner zo spoedig mogelijk dient te weten wie er zeker beschikbaar is voor deelname. Zo kan de planner een deadline opgeven waarbinnen de spelers dienen te reageren.


Privacy:
De spelers dienen de mogelijkheid te hebben om verschillende onderdelen van hun profiel te kunnen verbergen. Dit zodat deze onderdelen bijvoorbeeld niet kunnen worden bekeken door medespelers. Echter, personeel die verantwoordelijk is voor het onderhouden van het systeem mag dit ook niet inzien. De planner dient relevante data uiteraard wel te kunnen zien.


Reliability:
Een gebrek aan betrouwbaarheid is één van de problemen van het voorgaande systeem geweest door foutgevoeligheid. Data kon door een fout verloren gaan. Dit moet in het vervolg niet meer mogelijk zijn doordat iedere veld wordt bewaard zodra het is bijgewerkt en de gebruiker het betreffende veld heeft verlaten.


Security:
Medewerkers kunnen verborgen gegevens niet benaderen. Dit dient dusdanig te worden beveiligd dat het kopiëren van een link naar de betreffende gegevens, niet resulteert in het inzien van die gegevens.

Addendum

Integrated Domainmodel

Integrated Domainmodel gr4 2012.JPEG

Business Rules Catalogue

No. Rule definition Type of Rule Static/Dynamic
001 Een evenement kan maximaal 2 jaar van tevoren worden ingepland. Action restricting Static
002 Een evenement moet minimaal 1 week (7 kalenderdagen) van tevoren definitief worden. Action restricting Static
003 Wanneer een speler al is ingepland voor een definitief optreden, dient deze niet te worden ingepland bij een andere evenement met overlappende data (inclusief vervoer heen en terug). Action triggering Dynamic
004 Wanneer een kostuum al is ingepland voor een definitief optreden, dient deze niet te worden ingepland bij een andere evenement met overlappende data (inclusief vervoer heen en terug). Action restricting Dynamic
005 Wanneer er geen alternatieven zijn voor botsende evenementen (d.w.z. een speler is niet te vervangen door andere speler(s), zodanig dat er geen conflicten meer optreden), zal het management hierover beslissen. Action restricting Dynamic
006 Wanneer er geen alternatieven zijn voor botsende evenementen (d.w.z. een speler is niet te vervangen door andere speler(s), zodanig dat er geen conflicten meer optreden), zal het management hierover beslissen. Action triggering Dynamic
007 Wanneer een speler / kostuum al is ingepland voor een mogelijk optreden (dus nog niet definitief), dient deze niet te worden ingepland bij een ander evenement met overlappende data, tenzij dit niet anders kan (d.w.z. er zijn geen alternatieve spelers / kostuums inzetbaar voor dit evenement, of het botsende evenement / de botsende evenementen). Action restricting Dynamic
008 Een speler / kostuum kan alleen met toestemming van het management op een ander evenement worden ingepland als deze al voor een mogelijk optreden staat ingepland. Structural facts Static
009 Bij bevestiging van een aanvraag (stap 12 BCoE, stap 5 Alt Path: 'Aanvraag bewerken'), worden (wanneer mogelijk) de statussen van de spelers, kostuums en de agenda gewijzigd in een mogelijk evenement (let op, dit is nog géén optie!). Action restricting Dynamic
010 Spelers / ateliermedewerkers / kantoormedewerkers / klanten worden, bij élke wijziging dat direct op hun van invloed is, schriftelijk op de hoogte gesteld (mail is schriftelijk). Structural facts Static
011 Als er geen datum bekend is voor een evenement, terwijl de aanvraag wel is bevestigd, zullen de statussen pas worden veranderd bij invoering. Structural facts Static
012 Wanneer er geen locatie bekend is, zal het de agenda binnen Nederland 5 transportdagen rekenen, buiten Nederland 28 transportdagen, zowel voor heen- als terugreis. Structural facts Static
013 Een act hoeft niet per se een kostuum te bevatten en we spreken al van een act bij een optreden van één persoon. Structural facts Static
014 Als er meerdere kostuums beschikbaar zijn met verschillende maten, wordt de juiste maat pas geselecteerd op het moment dat de daarbij behorende speler wordt geselecteerd in de planning. Action restricting Dynamic
015 Als een kostuum tegelijkertijd door meerdere spelers moet worden gedragen, moeten de spelers dezelfde maten hebben als het kostuum. Alle combinaties van spelers moeten daarbij te selecteren zijn. Action restricting Static
016 Wijzigingen moeten te allen tijde kunnen worden teruggedraaid, de gegevens mogen nooit verloren gaan en er moet kunnen worden achterhaald wie wat heeft gewijzigd en wanneer. Structural facts Static
017 Een template 'speelinfo' bij een optie, haalt de standaard informatie (d.d., plaats, act etc.) uit de originele aanvraag. Als deze standaard informatie wordt gewijzigd (dit kan alleen na een extra handeling), moet er (door het systeem) worden nagegaan of er geen conflicten optreden. Action restricting Static
018 Een speler kan niet worden ingepland als hij of zij al op een andere optie is ingepland. Action restricting Static
019 Een speler kan niet worden ingepland als hij of zij niet geschikt is voor de specifieke act. Action restricting Static
020 Wanneer het minimum aantal spelers voor een act niet is bereikt, kan een aanvraag geen optie worden. Action restricting Static
021 Een kostuum kan niet ingepland worden als het defect is. Action restricting Static
022 Een kostuum kan niet ingepland worden als het al gepland staat op een ander evenement. Action restricting Static
023 Ieder definitief evenement heeft alle cruciale elementen van de planning geregeld. Action restricting Static
024 Spelers / ateliermedewerkers / kantoormedewerkers / klanten worden, bij élke wijziging dat direct op hun van invloed is, schriftelijk op de hoogte gesteld. Structural facts Dynamic
025 Iedere speler heeft als gegevens minimaal een naam. Structural facts Static
026 Het standaard aantal personen dat in één kostuum past is 1, tenzij anders aangegeven. Structural facts Static
027 Iedere speler kan zichzelf niet vrij gegeven voor een geplande opdracht Structural facts Static
028 Iedere speler kan zijn eigen beschikbaarheid niet veranderen voor een datum binnen x dagen/weken. Action restricting Dynamic
029 De prijs voor een offerte wordt gebaseerd op de lengte van de tijd waarop de specifieke spelers en kostuums weg zijn van huis, met daarnaast de prijs van de act (en eventueel de overige verwachte kosten voor vervoer en technici). Structural facts Dynamic

Terminological Definitions

Term: Betekenis:
Speler Persoon die acts speelt en ingepland kan worden
Medewerker Elke persoon binnen de gehele organisatie van CloseAct
Kantoormedewerker Medewerker die de administratie van CloseAct bijhoudt
Ateliermedewerker Verzorger van al het materiaal van de organisatie (kostuums, toebehoren, etc.)
Kostuum Kledingstuk van speler voor specifieke act
Offerte Prijsopgave van evenement
Optie Niet definitieve boeking van een evenement
Klant Opdrachtgever van een evenement
Act Deel van een evenement
Evenement Voorstelling waarbinnen zich minimaal één act afspeelt
Beschikbaarheid Vrij plekken binnen de agenda van CloseAct of in die van een Speler
Status Informatie over de voltooiing van de voorbereiding van een evenement
Redundant Overbodig / Overtollig
Contract officieel document met afspraken waaraan betrokkenen zich dienen te houden
Data Gegevens
Trigger Uitlokken / doen starten van een gebeurtenis
Template Een mal / Sjabloon
Archiveren Volgens bepaalde regels opbergen in een archief
Geïntegreerd Systeem Op een samenhangende manier opgezet geheel van computers en computerprogramma's zodat het geheel zo efficiënt en effectief mogelijk met elkaar kan samenwerken
Conflict Toestand waarbij zaken niet met elkaar samengaan
Concepten Nog niet definitief vastgelegde informatie
Overlap De mate waarin twee zaken iets gezamenlijk bedekken
Element Deel waaruit iets is opgebouwd
Default Standaardwaarde
Inloggen Je aanmelden (in dit geval in een digitale omgeving)
Account Persoonlijke toegang tot een digitale omgeving
Gebruikersnaam Reeks van letters, cijfers en tekens waarmee kan worden aangemeld
Wachtwoord geheime reeks letters, cijfers en tekens dat na de gebruikersnaam moet worden ingetypt om toegang te krijgen
Toegang Weg waarlangs men ergens kan komen
Extern (externe speler) Een persoon van buiten de organisatie
Profiel Beschrijving van eigenschappen (in het geval van CloseAct nodig voor o.a. plannen)
Up and running Dat iets volgens plan functioneert
Downtime period wachttijd doordat het systeem niet (naar behoren) functioneert
Deadline Datum waarop iets gebeurd moet zijn
Origineel (originele aanvraag) Oorspronkelijk(Oorspronkelijke aanvraag)

Bronnen

  1. ↑ De werkwijze zal verlopen middels richtlijnen van Daryl Kulak en Eamonn Guiney.
  2. ↑ 2,0 2,1 2,2 2,3 2,4 2,5 2,6 2,7 Workflow_RE_groep4.JPEG
Overgenomen van "https://lab.cs.ru.nl/algemeen/index.php?title=Requirements_Engineering/het_werk/werkstuk/2011-12/Groep_04&oldid=203307"