Requirements Engineering/het werk/werkstuk/2010-11/Groep 04

 

Groep 04

Werkstuk Requirements Engineering

Paul Verhoeven, Edwin de Koning, Nico Nijman, Roelf Leenders

Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen

---

version 18 februari 2022

---

Subpagina's Requirements Engineering/het werk/werkstuk/2010-11/Groep 04/Openstaande vragen Requirements Engineering/het werk/werkstuk/2010-11/Groep 04/voortgang

Paul Verhoeven Edwin de Koning Nico Nijman Roelf Leenders

Introductie

Vanuit het vak "Requirements Engineering" is ons het verzoek gedaan de requirements op te stellen aangaande de theatergroep Close-Act.

Close-Act Theatre is een professioneel gezelschap bestaande uit:

• steltlopers;
• dansers;
• muzikanten;
• vuurspelers;
• acrobaten.

Tevens beschikt Close-Act over een eigen atelier met:

• kostuumontwerpers;
• beeldend kunstenaars;
• grafisch ontwerpers;
• industrieel ontwerpers.

Niet op de laatste plaats heeft Close-Act een kantoor waar de contacten met opdrachtgevers en spelers worden onderhouden.

De bezetting van Close-Act, opgericht in 1991, komt uit Nederland en België. Vanaf de oprichting heeft voor Close-Act Europa als podium gediend. Echter sinds de voorstellingen Malaya - bestaande uit de mobiele acts Saurus en White Wings - is dit zelfs uitgebreid tot de rest van de wereld.

Close-Act is altijd in beweging. Letterlijk en figuurlijk. Het gezelschap streeft ernaar iedere twee jaar een nieuwe voorstelling uit te brengen. Daarnaast worden elk jaar nieuwe mobiele acts gecreëerd. Ook reeds bestaande acts blijven altijd in ontwikkeling met vernieuwingen in kostuums, spel, muziek, dans en technische innovaties.

Probleemstelling

Sinds de oprichting van Close-Act is de omvang van de groep significant toegenomen. Helaas heeft het administratieve proces deze groei niet kunnen bijbenen. Hierdoor is het plannen en het samenstellen van de diverse Close-Act voorstellingen tot een ware uitdaging geworden. Gevolg hiervan is dat het kan gebeuren dat ofwel acts dubbel worden geboekt, ofwel transport dubbel wordt geboekt. In het ergste geval kan de situatie onstaan dat niet de juiste kostuums met de act worden meegestuurd.

De expertises van de spelers ligt niet centraal vast. Concreet wil dat zeggen dat het niet mogelijk is spelers aan kostuums te koppelen. Eventuele reparaties van kostuums zijn niet in te plannen. Het komt zelfs voor dat op het laatste moment de diverse onderdelen van acts bij elkaar gezocht moeten worden omdat deze voor onderhoud verspreid door het atelier liggen. Het grootste probleem is dat het merendeel van alle kennis in hoofden van mensen zit. De bulk van de kennis is zelfs voornamelijk bij één persoon bekend. Mocht deze persoon iets overkomen dan wordt de theatergroep jaren teruggeworpen en zal alle kennis weer moeizaam vergaard moeten worden.

Aanvulling

Het idee van de projectgroep 'Groep 04' is om alle losse onderdelen te beschrijven en aan elkaar te koppelen. Bijvoorbeeld:

• Een voorstelling bestaat uit meerdere acts
• Een act bestaat uit meerdere rollen/kostuums/rekwisieten
• Een act is in onderhoud/besproken/transport
• Een acteur kan voor meerdere rollen/kostuums/rekwisieten worden ingezet
• Acteurs kunnen aangeven of en wanneer ze beschikbaar zijn. Beschikbaarheid van acteurs kan alleen worden gewijzigd als deze nog niet daadwerkelijk is ingepland. Alleen in speciale gevallen (bijvoorbeeld een overlijdensgeval) kan een acteur van een ingeplande voorstelling losgekoppeld worden.

Als een voorstelling definitief wordt is middels de koppelingen eenvoudig te zien wat de mogelijkheden zijn.

Gezien het feit dat de volledige invulling van deze specificatie door projectgroep 'Groep 04' een dermate grote hoeveelheid werk met zich mee gaat brengen en gezien de beperkte grootte van de universitaire opdracht is het niet mogelijk om zo'n volledige invulling uit te werken. Deze invulling zou later in opdracht van 'Close-Act' gerealiseerd kunnen worden als uitbreiding op onze huidige requirements voor het benodigde systeem.

Case analysis

Stakeholder list/analysis

#	Omschrijving	Hoe betrokken
01	Administratief medewerkers	Gebruiken het systeem op dagelijkse basis
02	Ateliermedewerkers(kostuum makers/ontwerpers)	Gebruiken het systeem voor planning en statusinformatie van rekwisieten
03	Acteurs	Kijken zo nu en dan in (de planning van) het systeem voor hun beschikbaarheid

Mission-Vision-(Values)

Mission

De case waarvoor we deze requirements opstellen betreft de theatergroep "Close-Act". Deze theatergroep verzorgt in zowel binnen- als buitenland "stelt-loop-theater-acts". In beginsel bestond "Close-Act" uit slechts 3 personen. Gedurende de daaropvolgende 20 jaar heeft de populariteit van deze theatergroep een enorme vlucht genomen en dientengevolge is de bezetting uitgegroeid tot 30, voornamelijk freelance, medewerkers. De focus van de theatergroep richte zich grotendeels op het creatieve deel van de organisatie. Helaas heeft het administratieve proces deze vlucht niet kunnen bijhouden. Gevolg hiervan is dat de administratie middels een wirwar van losse toepassingen wordt onderhouden. Alle relaties tussen de diverse administratieve onderdelen dienen handmatig te worden bijgewerkt. Dit is een buitengewoon tijdrovende en risicovolle onderneming. Het doel van deze casus is het administratieve proces dusdanig te professionaliseren dat nu en in de toekomst de aandacht weer volledig op het theaterspel kan worden gericht.

Vision

Daar de synchronisatie van de administratie nu een handmatig proces betreft, loopt de organisatie grote risico's. Als gevolg komt het met regelmaat voor dat kostuums en transport dubbel wordt geboekt. Ook het op orde houden van de acteur-administratie is een buitengewoon grote uitdaging. Het is dan ook zaak dat de requirements voorzien in het beheer van:

• Aanvragen;
• Offerte;
• Spelers;
• Materiaal;
• Logistiek;
• Onderhoud;
• Planning;

Risk Analysis

#	Categorie	Risico	Oplossing verwacht d.d.	Status	Dagen verloren	Verwachtingsfactor	Risicofactor
01	Missen deadlines	10	Direct	Open	30	100%	30
02	Teamleden die geen bijdrage leveren	10	Facade overleg	Open	0	100%	0
03	Geen communicatie binnen het team	7	7 April	Open	5	35%	2
04	Vergrootte werkdruk betaald werk	4	7 April	Open	30	25%	8
05	Incorrect documentatie van informatie	3	Facade overleg	Open	10	50%	5
06	Blind spots	2	Facade overleg	Open	90	5%	4

Requirements

Use Case Survey

#	Name	Omschrijving	Actor die de use case start
01	Aanvragen beheren	De administratief medewerker voert nieuwe informatie over een aanvraag in in het systeem. Tijdens het bespreken van een aanvraag met de opdrachtgever kan tevens worden gekeken of de wensen van de opdrachtgever beschikbaar zijn, op basis hiervan kunnen adviezen worden gegeven voor een nog op te stellen offerte.	Administratief medewerker
02	Offerte beheren	Het opstellen, het uitbrengen en het bijhouden van de status van offertes.	Administratief medewerker
03	Mensen inplannen	Administratief medewerkers kunnen spelers voor een voorstelling in- en uitplannen.	Administratief medewerker
04	Reparatie rekwisieten beheren	Rekwisieten worden onderhouden en de status van dit onderhoud wordt bijgehouden.	Ateliermedewerker
05	Logistiek regelen	De administratief medewerker gaat transportaanvragen doen bij verschillende externe vervoerders en tevens plant hij de vervoersmiddelen van Close-Act zelf in. De transportinformatie van de externe vervoerders wordt vastgelegd in het systeem zodat bij daadwerkelijk transport deze gegevens gebruikt kunnen worden door een logistiek medewerker. Voordat het daadwerkelijke transport plaats vindt kan de administratief medewerker voor in het magazijn een picklijst afdrukken van de rekwisieten die onder de aanvraag vallen.	Administratief medewerker
06	Rekwisieten beheren	Overzicht maken van de benodigde materialen Materialen kunnen worden ingepland ofwel voor een voorstelling ofwel voor onderhoud.	Administratief medewerker
07	Beschikbaarheid beheren	Een speler geeft aan wanneer hij beschikbaar is en wanneer hij/zij zou kunnen optreden.	Acteur

Integrated UC Diagram

Use Cases

Aanvragen beheren

Use Case	UC_01
Use case diagram	Aanvragen beheren
Iteratie	Focused
Description	De administratief medewerker voert nieuwe informatie over een aanvraag in in het systeem. Tijdens het bespreken van een aanvraag met de opdrachtgever kan tevens worden gekeken of de wensen van de opdrachtgever beschikbaar zijn, op basis hiervan kunnen adviezen worden gegeven voor een nog op te stellen offerte.
Trigger
Source
Version	Focused
Basic course of events	De administratief medewerker kiest vanuit het hoofdmenu voor "Aanvragen" Het systeem toont een scherm met een overzicht van bestaande aanvragen met optie om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken. De administratief medewerker kiest om een nieuwe aanvraag aan te maken Het systeem toont blanco "Aanvraag detail" scherm De administratief medewerker geeft aan de opdrachtgever te willen bepalen Het systeem toont scherm met overzicht van bestaande opdrachtgevers met optie om een nieuwe opdrachtgever aan te maken of een bestaande opdrachtgever te selecteren. De administratief medewerker geeft aan een nieuwe opdrachtgever aan te willen maken. Het systeem geeft invulvelden voor de opdrachtgevergegevens. De administratief medewerker vult gegevens in en geeft aan te willen opslaan. Het systeem bevestigt dat opdrachtgevergegevens zijn opgeslagen en gekoppelt zijn aan de aanvraag. Het systeem keert terug "Aanvraag detail" scherm De administratief medewerker geeft aan voorstellingsgegevens te willen invullen Het systeem geeft invulvelden voor de voorstellingsgegevens. De administratief medewerker vult gegevens in en geeft aan te willen opslaan. Het systeem bevestigt dat de voorstellingsgegevens voor deze aanvraag zijn opgeslagen. Het systeem keert terug naar het "Aanvraag detail" scherm De administratief medewerker is klaar en kiest om het scherm te sluiten Het systeem keert terug naar het hoofdmenu
Alternate paths	Reeds bestaande aanvraag bewerken De administratief medewerker kiest een reeds bestaande aanvraag uit de lijst. Het systeem toont "Aanvraag detail" scherm van geselecteerde aanvraag Keer terug naar 12 in BCoE. Reeds bestaande opdrachtgever selecteren De administratief medewerker kiest een reeds bestaande opdrachtgever uit de lijst. Het systeem bevestigd dat opdrachtgever gekoppeld is aan de aanvraag Keer terug naar 11 in BCoE. Voorstelling gegevens bewerken Het systeem toont reeds ingevulde voorstellinggegevens. De administratief medewerker bewerkt de gegevens en kiest geeft aan te willen opslaan. Keer terug naar 15 in BCoE. Reeds bestaande aanvraag annuleren(kan altijd vanuit "Aanvraag detail" scherm worden gekozen) De administratief medewerker selecteert een aanvraag en kiest om deze te annuleren Het systeem vraagt of de aanvraag echt geannuleerd moet worden De administratief medewerker bevestigt de annulering en verwijdert de aanvraag Keer terug naar 18 in BCoE.
Preconditions	De administratief medewerker is aangemeld bij het systeem en bevindt zich in het hoofdmenu.
Postconditions	De actuele gegevens van de aanvraag zijn voor iedereen die deze nodig kan hebben beschikbaar.
Related business rules	De datum voor een aanvraag ligt altijd in de toekomst.

Domain Model
ORM datamodel behorende bij bovenstaande Use Case:

Offerte beheren

Use Case	UC_02
Use case diagram	Offertes beheren
Iteratie	Focused
Description	Het opstellen, het uitbrengen en het bijhouden van de status van offertes.
Trigger
Source
Version	Focused
Basic course of events	Aanmaken offerte De administratief medewerker kiest vanuit het hoofdmenu voor "Aanvragen" Het systeem toont scherm met overzicht van bestaande aanvragen met optie om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken. De administratief medewerker selecteert een reeds bestaande aanvraag Het systeem toont het "Aanvraag detail" scherm van de geselecteerde aanvraag De administratief medewerker kiest vanuit het "Aanvraag detail" voor "Offertes" Het systeem toont scherm met overzicht van bestaande offertes onder deze aanvraag met een optie om een nieuwe offerte aan te maken of een bestaande offerte te selecteren. De administratief medewerker geeft aan een nieuwe offerte aan te willen maken. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met blance invulvelden voor de nieuwe offerte gegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen De administratief medewerker selecteert de benodigde rollen en rekwisieten voor de offerte en raamt de kosten hiervan in. Het systeem berekent een totaalprijs voor de hele offerte en toont deze op het scherm De administratief medewerker is klaar en geeft aan te willen opslaan. Het systeem bevestigd dat offerte is opgeslagen. Het systeem keert terug naar het "Aanvraag detail" scherm De administratief medewerker is klaar en kiest om scherm te sluiten Het systeem keert terug hoofdmenu
Alternate paths	Offerte verwijderen De administratief medewerker selecteert een reeds gemaakte offerte. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen De administratief medewerker kiest voor offerte verwijderen. Het systeem bevestigde dat de offerte is verwijderd en keert terug naar het "Aanvraag detail" scherm. Keer terug naar 14 in BCoE. Offerte bewerken De administratief medewerker selecteert een reeds gemaakte offerte. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen De administratief medewerker bewerkte de offerte gegevens en geeft aan te willen opslaan. Het systeem bevestigde dat de offerte is opgeslagen en keert terug naar het "Aanvraag detail" scherm. Keer terug naar 14 in BCoE. Offerte afdrukken De administratief medewerker selecteert een reeds gemaakte offerte. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen De administratief medewerker kiest voor offerte afdrukken. Het systeem drukt de offerte af en keert terug naar het "Aanvraag detail" scherm. Keer terug naar 14 in BCoE. Optie nemen De administratief medewerker selecteert een reeds gemaakte offerte. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen De administratief medewerker kiest voor optie nemen op offerte. Het systeem bevestigde dat er een optie op de offerte is genomen keert terug naar het "Aanvraag detail" scherm. Keer terug naar 14 in BCoE. Optie annuleren De administratief medewerker selecteert een reeds gemaakte offerte waarop een optie is genomen. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om te optie te annuleren en de offerte af te drukken De administratief medewerker kiest ervoor de optie te annuleren. Het systeem toont invoervelden om de optie te kunnen annuleren. De administratief medewerker past de gegevens aan(annuleringskosten, reden van canceling). De administratief medewerker bevestigt de gegevens om de optie te annuleren. Het systeem print een annuleringsbevestiging met annuleringskosten. Het systeem bevestigd de annulering van de optie en verwijdering van de offerte en keert terug naar het "Aanvraag detail" scherm. Keer terug naar 14 in BCoE.
Preconditions	Informatie over de locatie is beschikbaar. Informatie over de gewenste acts is beschikbaar. Informatie over de gewenste of mogelijke tijsdstippen is beschikbaar. De administratief medewerker is aangemeld bij het systeem.
Postconditions	De gemaakte wijzigingen zijn opgeslagen in het systeem.
Related business rules	De prijs op een offerte mag niet negatief zijn. Een offerte mag niet gewijzigd worden nadat hier een optie op is genomen.

Domain Model
ORM datamodel behorende bij bovenstaande Use Case:

Mensen inplannen

Use Case	UC_03
Use case diagram	Mensen inplannen
Iteratie	Focused
Description	Administratief medewerkers kunnen spelers voor een voorstelling in- en uitplannen.
Trigger
Source
Version	Focused
Basic course of events	De administratief medewerker kiest Acteursplanning in het hoofdmenu. Het systeem toont een overzicht van de opdrachten. De administratief medewerker selecteert de opdracht waarvoor spelers gepland zullen worden. Het systeem toont een overzicht van alle acts met acteurs. De administratief medewerker selecteert de spelers waarvoor hij de wijzigingen wil doorgeven en bevestigt de selectie. Het systeem toont planningsgegevens de geselecteerde spelers. De administratief medewerker maakt de gewenste wijzigingen in de getoonde gegevens. De administratief medewerker bevestigt de gemaakte wijzigingen. Het systeem stuurt een e-mail naar de spelers wier planningsgegevens zijn gewijzigd. Het systeem geeft een melding dat de wijzigingen in de planning zijn opgeslagen. De administratief medewerker keert terug naar het hoofdmenu.
Alternate paths	Administratief medewerker breekt de bewerking af Het systeem geeft een waarschuwing en vraagt de administratief medewerker wat er met de niet bevestigde wijzigingen moet gebeuren. De administratief medewerker geeft aan of de wijzigingen opgeslagen of geannuleerd moeten worden. Keer terug naar 11 in BCoE.
Preconditions	De administratief medewerker is aangemeld bij het systeem en ziet het hoofdmenu. Per speler is bekend wat gespeeld kan worden. Er is bekend welke spelers voor een rol de voorkeur krijgen. De speler heeft zo volledig mogelijk zijn eigen planning ingevuld.
Postconditions	Spelerplanning is geupdate om wijzigingen weer te geven. Speler is op de hoogte gesteld van zijn inzet. De administratief medewerker ziet het hoofdmenu
Related business rules	Als een acteur heeft aangegeven dat hij niet beschikbaar is op een bepaalde datum, mag hij daarop niet ingepland worden. Een acteur mag niet ingepland worden voor een act die hij (nog) niet kan spelen. Een acteur mag niet ingepland worden voor een act waarvoor geen passend kostuum beschikbaar is. Een acteur mag niet ingepland worden op een datum in het verleden. Een acteur mag niet ingepland worden voordat de klant een optie heeft genomen voor de act. Een acteur mag niet ingepland worden als hij op het speelmoment al voor een andere voorstelling is ingepland.

Domain Model
ORM datamodel behorende bij bovenstaande Use Case:

Reparatie rekwisieten beheren

Use Case	UC_04
Use case diagram	Reparatie rekwisieten beheren
Iteratie	Focused
Description	Rekwisieten worden onderhouden en de status van dit onderhoud wordt bijgehouden.
Trigger
Source
Version	Focused
Basic course of events	De ateliermedewerker kiest in het hoofdmenu voor rekwisietenbeheer. Het systeem toont een overzicht van gemelde beschadigingen, gevraagde aanpassingen en geplande onderhoudsbeurten aan de rekwisieten en wanneer ze weer nodig/bruikbaar moeten zijn. De ateliermedewerker kiest het te bewerken rekwisiet in het overzichtsscherm. Het systeem toont invoer/bewerkingsvelden met de status en gegevens van dit rekwisiet. De ateliermedewerker wijzigt de status en gegevens van het rekwisiet. De ateliermedewerker bevestigt deze handelingen/veranderingen aan het systeem. Het systeem bevestigt dat de veranderingen verwerkt zijn en toont het hoofdmenu.
Alternate paths	Bewerking wordt afgebroken Het systeem geeft een waarschuwing en vraagt de klant wat met de niet bevestigde wijzigingen moet gebeuren. De ateliermedewerker geeft aan of de wijzigingen opgeslagen of geannuleerd moeten worden. Het systeem bevestigd dat die opdracht uitgevoerd is en toont het hoofdmenu. Keer terug naar 7 in BCoE.
Preconditions	De medewerker is aangemeld bij het systeem en ziet het hoofdmenu Alle rekwisieten zijn in het systeem ingevoerd Opgemerkte mankementen zijn gemeld en geregistreerd.
Postconditions	De medewerker ziet het hoofdmenu Van alle rekwisieten is de onderhoudsstatus bekend.
Related business rules	Een reparatie mag niet ingepland worden als een kostuum op dat moment voor een act is gereserveerd. Reparatie van een kostuum dat is gereserveerd voor een act heeft hogere prioriteit. Als iemand een mankement aan een rekwisiet opmerkt moet hij dit melden en in het systeem (laten) registreren.

Domain Model
ORM datamodel behorende bij bovenstaande Use Case:

Logistiek regelen

Use Case	UC_05
Use case diagram	Logistiek regelen
Iteratie	Focused
Description	De administratief medewerker gaat transportaanvragen doen bij verschillende externe vervoerders en tevens plant hij de vervoersmiddelen van Close-Act zelf in. De transportinformatie van de externe vervoerders wordt vastgelegd in het systeem zodat bij daadwerkelijk transport deze gegevens gebruikt kunnen worden door een logistiek medewerker. Voordat het daadwerkelijke transport plaats vindt kan de administratief medewerker voor in het magazijn een picklijst afdrukken van de rekwisieten die onder de aanvraag vallen.
Trigger
Source
Version	Focused
Basic course of events	De administratief medewerker gaat naar het aanvragenoverzicht. Het systeem toont een overzicht van alle aanvragen met hun statussen(aanvraag, offerte, optie). De administratief medewerker selecteert een aanvraag en kiest ervoor het vervoer hiervan te bewerken. Het systeem geeft een overzicht van de huidige transportgegevens voor de geselecteerde aanvraag. De administratief medewerker kiest ervoor nieuwe transportgegevens van een eigen vervoersmiddel toe te voegen. Het systeem geeft te bewerken velden weer met de transportgegevens. De administratief medewerker voert gegevens in over transportmiddel, datum, plaats, te vervoeren middelen(rekwisieten, spelers) en prijs. De administratief medewerker bevestigt de informatie aan het systeem. Het systeem bevestigt de veranderingen aan de administratief medewerker. Het systeem keert terug naar het hoofdmenu.
Alternate paths	Externe vervoerder toevoegen De administratief medewerker kiest ervoor nieuwe transportgegevens van een externe vervoerder toe te voegen. De administratief medewerker voert gegevens in over vervoerder, contactgegevens, datum, te vervoeren middelen(rekwisieten, spelers), plaats en prijs. Keer terug naar 8 in BCoE. Picklijst uitprinten De administratief medewerker selecteert een set transportgegevens en kiest ervoor een picklijst af te drukken. Keer terug naar 10 in BCoE.
Preconditions	Alle benodigde rekwisieten van een aanvraag zijn ingepland in het systeem. De medewerker is aangemeld bij het systeem en ziet het hoofdmenu
Postconditions	Er zijn transporten ingepland voor het vervoeren van alle benodigde rekwisieten van een aanvraag. Tevens is er een picklijst afgedrukt waarmee de logistiek medewerker de benodigde rekwisieten kan verzamelen.
Related business rules

Domain Model
ORM datamodel behorende bij bovenstaande Use Case:

Rekwisieten beheren

Use Case	UC_06
Use case diagram	Rekwisieten beheren
Iteratie	Focused
Description	Rekwisieten (materialen en kostuuns) kunnen worden beheerd. De rekwisieten kunnen worden ingepland, er kan schade worden gemeld, en ze kunnen worden bewerkt.
Trigger
Source
Version	Focused
Basic course of events	Rekwisiet inplannen De administratief medewerker kiest voor Rekwisieten beheer. Het systeem toont het rekwisieten overzicht. De administratief medewerker selecteert een reeds bestaande rekwisiet Het systeem toont het rekwisiet detail scherm met de eigenschappen, het planningsoverzicht en de mogelijkheid om het rekwisiet in te plannen, en beschadigingen te melden De administratief medewerker kiest om het rekwisiet in te plannen. Het systeem toont een aanvragen overzicht met reeds bestaande aanvragen De administratief medewerker selecteert een aanvraag waarvoor het rekwisiet moet worden ingepland en kiest voor bevestigen Het systeem bevestigd dat het rekwisiet is ingepland voor de geselecteerde aanvraag en keert terug naar het rekwisiet detail scherm De administratief medewerker is klaar en kiest om het scherm te sluiten Het systeem keert terug naar het hoofdmenu
Alternate paths	Rekwisiet bewerken De administratief medewerker bewerkt de rekwisiet gegevens en kiest bevestigen. Het systeem bevestigd dat het rekwisiet is bewerkt en opgeslagen en keert terug naar het rekwisiet detail scherm Keer terug naar 9 in BCoE. Rekwisiet schade melden De administratief medewerker kiest voor schade melden. Het systeem toont de invulvelden voor de omschrijving van de schade De administratief medewerker vult de omschrijving van de schade en kiest voor bevestigen</i> Het systeem bevestigd dat de schade omschrijving is opgeslagen en keert terug naar het rekwisiet detail scherm </ol> Keer terug naar 9 in BCoE.
Exception paths	Rekwisiet is al ingepland voor een andere aanvraag die overlapt met de geselecteerde aanvraag Het systeem geeft de melding dat het rekwisiet al is ingepland voor een andere aanvraag die overlapt met de geselecteerde aanvraag Het systeem keert terug naar rekwisiet detail scherm Keer terug naar 4 in BCoE.
Preconditions	Van iedere act is ingevoerd welke rekwisieten erbij nodig zijn en hoe ze vervoerd kunnen worden. De administratief medewerker is aangemeld bij het systeem en ziet het hoofdmenu.
Postconditions	De beschikbaarheid van rekwisieten is inzichtelijk, zodat dubbele boekingen of problemen met transport voorkomen kunnen worden. De administratief medewerker ziet het hoofdmenu.
Related business rules	Rekwisieten mogen niet ingepland worden als reparatie nodig is. Rekwisieten mogen niet ingepland worden op een datum in het verleden. Rekwisieten mogen niet ingepland worden als ze op dat moment al voor een andere voorstelling zijn ingepland.

Domain Model
ORM datamodel behorende bij bovenstaande Use Case:

Beschikbaarheid beheren

Use Case	UC_07
Use case diagram	Beschikbaarheid beheren
Iteratie	Focused
Description	Een acteur geeft aan wanneer hij beschikbaar is en wanneer hij/zij zou kunnen optreden.
Trigger
Source
Version	Focused
Basic course of events	De acteur meldt zich aan bij het systeem. Het systeem toont een kalenderoverzicht waarin beschikbaarheid kan worden aangegeven. Openstaande acts worden hierin weergegeven. De acteur update zijn beschikbaarheid in het overzicht door in te tekenen voor dagen en specifieke acts. De acteur bevestigt zijn ingevulde beschikbaarheid aan het systeem. Het systeem verwerkt de wijzigingen en toont de aangepaste acteursplanning. De acteur meldt zich af bij het systeem.
Alternate paths	Beschikbaarheid annuleren De acteur update zijn beschikbaarheid door zich van eerder als beschikbare opgegeven dagen uit te schrijven. Keer terug naar 4 in BCoE.
Preconditions	Een acteur die bekend is bij Close-Act.
Postconditions	De beschikheid van de acteur is hem bekend.
Related business rules	Acteurs mogen zich ten alle tijde(voor de speeldatum) aanmelden voor een act. Acteurs mogen hun beschikbaarheid in het verleden niet wijzigen. Acteurs mogen hun beschikbaarheid tot twee weken in de toekomst zelf niet intrekken. Acteurs mogen hun beschikbaarheid zelf niet intrekken als ze al in een opdracht ingepland zijn.

Domain Model
ORM datamodel behorende bij bovenstaande Use Case:

Scenarios

Use Case 1: Aanvragen beheren

BCoE
Nieuwe aanvraag aanmaken
Albert Janssen van AppMedia wil graag vieren dat ze een nieuwe Android applicatie in de markt zetten. Hiertoe belt hij Close-Act en krijgt administratief medewerker Vivian aan de lijn. Van Albert krijgt ze gegevens over een nieuwe opdracht en -gever. Albert geeft via de telefoon aan dat hij een vuurspuwer act in de kantine van het kantoorpand van zijn bedrijf wilt hebben. Het kantoor bevindt zich op aan de Industrieweg 12 in Nijmegen. De datum is nog niet bekend daar belt hij nog over terug.

1. Vivian kiest vanuit het hoofdmenu voor "Aanvragen"
2. Het systeem toont een scherm met een overzicht van bestaande aanvragen met optie om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken.
3. Vivian kiest om een nieuw aanvraag aan te maken
4. Het systeem toont blanco "Aanvraag detail" scherm
5. Vivian geeft aan een opdrachtgever te willen kiezen
6. Het systeem toont scherm met overzicht van bestaande opdrachtgevers met optie om een nieuwe opdrachtgever aan te maken of een bestaande opdrachtgever te selecteren.
7. Vivian geeft aan een nieuwe opdrachtgever aan te willen maken.
8. Het systeem geeft blanco invulvelden voor nieuwe opdrachtgevergegevens.
9. Vivian vult in dat de opdrachtgever "AppMedia" is en geeft aan dat het contact persoon van dit bedrijf "Albert Janssen" is, daarna geeft ze aan te willen opslaan.
10. Het systeem bevestigt dat opdrachtgevergegevens zijn opgeslagen en gekoppelt zijn aan de aanvraag.
11. Het systeem keert terug "Aanvraag detail" scherm
12. Vivian geeft aan voorstellingsgegevens te willen invullen
13. Het systeem geeft blanco invulvelden voor nieuwe voorstellingsgegevens.
14. Vivian vult als adres "Industrieweg 12 in Nijmegen" in en in de omschrijving zet ze dat er een wens is voor een vuurspuw act in de kantine van het kantoor gebouw. Hierna geeft ze aan te willen opslaan.
15. Het systeem bevestigt dat voorstellingsgegevens voor deze aanvraag zijn opgeslagen.
16. Het systeem keert terug "Aanvraag detail" scherm
17. Vivian is klaar en kiest om het scherm te sluiten
18. Het systeem keert terug Hoofdmenu

Alternate Paths
Reeds bestaande aanvraag bewerken & Voorstelling gegevens bewerken
Albert Janssen van AppMedia belt weer over zijn aanvraag en krijgt Vivian aan de lijn. Na navraag bij de facilitaire dienst van het bedrijf krijgt hij geen goedkeuring voor een vuurspuw act in de kantine van het gebouw, hij wil de act daarom verplaatsen naar het parkeerterrein buiten. De datum van de act is trouwens ook bekend, als alles volgens planning loopt zal het lanceerfeestje op 15 juni plaatsen vinden. Vivian zoekt de aanvraag op in het systeem en bewerkt de gegevens.

1. Vivian kiest vanuit het hoofdmenu voor "Aanvragen"
2. Het systeem toont een scherm met overzicht van bestaande aanvragen met de keuze om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken.
3. Vivian zoekt in het aanvragen overzicht naar de aanvraag van AppMedia en selecteert deze vervolgens
4. Het systeem toont het "Aanvraag detail" scherm van de aanvraag
5. Vivian geeft aan voorstelling gegevens te willen bijwerken
6. Het systeem geeft de reeds ingevulde voorstellinggegevens weer.
7. Vivian vult 15-06-2011 als datum voor de act in en verwerkt de verplaatsing van de act naar het parkeerterrein in de omschrijving van de voorstelling. Hierna geeft ze aan te willen opslaan.
8. Het systeem bevestigt dat voorstellingsgegevens voor deze aanvraag zijn opgeslagen
9. Het systeem keert terug "Aanvraag detail" scherm
10. Vivian is klaar en kiest om scherm te sluiten
11. Het systeem keert terug Hoofdmenu

Nieuwe aanvraag aanmaken & reeds bestaande opdrachtgever selecteren
Omdat de vuurspuw act goed is bevallen belt Albert Janssen van AppMedia opnieuw naar Close-Act voor een lanceerfeestje van de nieuwe iPhone applicatie. Albert krijgt Vivian weer aan de lijn, en ze kan zich nog Albert als klant nog herinneren. Albert geeft via de telefoon aan dat hij dit keer een Saurus act door het afdeling van de ontwikkelaars wil laten lopen. Vivian opent het systeem om de nieuwe aanvraag in te voeren.

1. Vivian kiest vanuit het hoofdmenu voor "Aanvragen"
2. Het systeem toont een scherm met overzicht van bestaande aanvragen met de keuze om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken.
3. Vivian kiest om nieuw aanvraag aan te maken
4. Het systeem toont blanco "Aanvraag detail" scherm
5. Vivian geeft aan een opdrachtgever te willen kiezen
6. Het systeem toont scherm met overzicht van bestaande opdrachtgevers met optie om een nieuwe opdrachtgever aan te maken of een bestaande opdrachtgever te selecteren.
7. Vivian selecteert "AppMedia" uit de lijst met opdrachtgevers en geeft aan te willen opslaan.
8. Het systeem bevestigt dat opdrachtgevergegevens zijn opgeslagen en gekoppeld zijn aan de aanvraag
9. Het systeem keert terug "Aanvraag detail" scherm

Vivian registreert de rest van de aanvraaggegegevens op dezelfde manier als onder de BCoE.

Reeds bestaande aanvraag annuleren(kan altijd vanuit "Aanvraag detail" scherm worden gekozen")
Albert Janssen van AppMedia belt opnieuw naar Cloas-Act. De Saurus act op de ontwikkelafdeling vond hij toch niet zo'n goed idee gezien de beperkte ruimte, hij wil daarom afzien van de aanvraag. Vivian opent het systeem om de aanvraag te annuleren.

1. Vivian kiest vanuit het hoofdmenu voor "Aanvragen"
2. Het systeem toont scherm met overzicht van bestaande aanvragen met optie om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken.
3. Vivian zoekt in het aanvragen overzicht naar de aanvraag van AppMedia en selecteert de aanvraag voor de Saurus act uit de lijst
4. Het systeem toont het "Aanvraag detail" scherm van de aanvraag
5. Vivian kiest voor "Aanvraag annuleren"
6. Het systeem vraagt of de aanvraag echt geannuleerd moet worden
7. Vivian bevestigt haar keuze
8. Het systeem bevestigt annulering en keert terug naar het hoofdmenu

Use case 2: Offerte beheren

BCoE
Offerte aanmaken
Hans, een medewerker van de Radboud Universiteit, geeft de laatste benodigde gegevens over een voorstelling die hij graag tijdens de introductie zou willen hebben. Hans wil graag voor de voorstelling 2 Saurussen en een vuurspuw act. Vivian voert deze gegevens in in het systeem:

1. Vivian kiest vanuit het hoofdmenu voor "Aanvragen"
2. Het systeem toont een scherm met een overzicht van bestaande aanvragen de keuze om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken.
3. Vivian zoekt de aanvraag van de Radboud Universiteit en selecteert deze aanvraag
4. Het systeem toont het "Aanvraag detail" scherm van de geselecteerde aanvraag
5. Vivian kiest vanuit het "Aanvraag detail" voor "Offertes"
6. Het systeem toont scherm met overzicht van de offertes van deze opdrachtgever met een optie om een nieuwe offerte aan te maken of een bestaande offerte te selecteren.
7. Vivian geeft aan een nieuwe offerte aan te willen maken.
8. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met blanco invulvelden voor de nieuwe offertegegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen
9. Vivian voegt het volgende 3 aanvraagonderdelen toe: 2 x Sauruspakken, 1 x Vuurspuwkostuum en 3 spelers en raamt van elk onderdeel de kosten in.
10. Het systeem berekent een totaalprijs voor de hele offerte en toont deze tijdens de raming op het scherm
11. Vivian is klaar en geeft aan te willen opslaan.
12. Het systeem bevestigd dat offerte is opgeslagen.
13. Het systeem keert terug naar het "Aanvraag detail" scherm
14. Vivian is klaar en kiest om scherm te sluiten
15. Het systeem keert terug hoofdmenu

Alternate paths
Offerte afdrukken
De offerte voor Hans is vandaag aangemaakt door Vivian. Vivian wil aan het einde van de dag de offerte uitprinten en opsturen naar Hans. Ze gaat in het systeem om de offerte af te drukken

1. Vivian kiest vanuit het hoofdmenu voor "Aanvragen"
2. Het systeem toont een scherm met een overzicht van bestaande aanvragen met de keuze om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken.
3. Vivian zoekt de aanvraag van de Radboud Universiteit en selecteert deze aanvraag
4. Het systeem toont het "Aanvraag detail" scherm van de geselecteerde aanvraag
5. Vivian kiest vanuit het "Aanvraag detail" voor "Offertes"
6. Het systeem toont scherm met overzicht van de offertes van deze opdrachtgever met een optie om een nieuwe offerte aan te maken of een bestaande offerte te selecteren.
7. Vivian zoekt de offerte op van Hans en selecteert deze.
8. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen
9. Vivian kiest voor offerte afdrukken.
10. Het systeem drukt de offerte af en keert terug naar het "Aanvraag detail" scherm.
11. Vivian is klaar en kiest om scherm te sluiten
12. Het systeem keert terug naar het hoofdmenu

Offerte bewerken
Hans belt op en verteld Vivian dat hij de offerte heeft ontvangen maar dat hij het toch een beetje te duur vind. Hij wil graag de vuurspuwer weglaten en een nieuwe offerte hiervoor ontvangen. Vivian gaat in het systeem om de offerte te bewerken

1. Vivian kiest vanuit het hoofdmenu voor "Aanvragen"
2. Het systeem toont een scherm met een overzicht van bestaande aanvragen met de keuze om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken.
3. Vivian zoekt de aanvraag van de Radboud Universiteit en selecteert deze aanvraag
4. Het systeem toont het "Aanvraag detail" scherm van de geselecteerde aanvraag
5. Vivian kiest vanuit het "Aanvraag detail" voor "Offertes"
6. Het systeem toont scherm met overzicht van bestaande offertes van deze opdrachtgever met een optie om een nieuwe offerte aan te maken of een bestaande offerte te selecteren.
7. Vivian zoekt de bewuste offerte op en selecteert deze.
8. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen
9. Vivian haalt de offerteregel voor de vuurspuwer weg en kiest voor opslaan
10. Het systeem bevestigd dat de offerte is opgeslagen en keert terug naar het "Aanvraag detail" scherm.
11. Vivian is klaar en kiest om scherm te sluiten
12. Het systeem keert terug naar het hoofdmenu

Offerte verwijderen
Vivian heeft per ongeluk de offerte voor de Radboud Universiteit aangemaakt onder de aanvraag van de Universiteit Utrecht. Vivian gaat in het systeem om de verkeerde aangemaakt offerte te verwijderen

1. Vivian kiest vanuit het hoofdmenu voor "Aanvragen"
2. Het systeem toont scherm met overzicht van bestaande aanvragen met optie om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken.
3. Vivian zoekt de aanvraag van de Universiteit Utrecht en selecteert deze aanvraag
4. Het systeem toont het "Aanvraag detail" scherm van de geselecteerde aanvraag
5. Vivian kiest vanuit het "Aanvraag detail" voor "Offertes"
6. Het systeem toont scherm met overzicht van bestaande offertes onder deze aanvraag met een optie om een nieuwe offerte aan te maken of een bestaande offerte te selecteren.
7. Vivian zoekt de offerte op die bestemd was voor de Radboud Universiteit en selecteert deze.
8. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen
9. Vivian kiest voor offerte verwijderen
10. Het systeem bevestigd dat de offerte wordt verwijderd en keert terug naar het "Aanvraag detail" scherm.
11. Vivian is klaar en kiest om scherm te sluiten
12. Het systeem keert terug naar het hoofdmenu

Optie nemen
Hans belt op en geeft aan de laatste offerte voor de aanvraag van de Radboud Universiteit accepteerd. Vivian start het systeem op en zet de offerte in optie. Vanaf nu kunnen de rekwisieten en spelers worden ingeplant voor deze aanvraag.

1. Vivian kiest vanuit het hoofdmenu voor "Aanvragen"
2. Het systeem toont een scherm met een overzicht van bestaande aanvragen met de keuze om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken.
3. Vivian zoekt de aanvraag van de Radboud Universiteit en selecteert deze aanvraag
4. Het systeem toont het "Aanvraag detail" scherm van de geselecteerde aanvraag
5. Vivian kiest vanuit het "Aanvraag detail" voor "Offertes"
6. Het systeem toont scherm met overzicht van bestaande offertes van deze opdrachtgever met een optie om een nieuwe offerte aan te maken of een bestaande offerte te selecteren.
7. Vivian zoekt de offerte op die bestemd was voor de Radboud Universiteit en selecteert deze.
8. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen
9. Vivian selecteert de laatste opgestuurde offerte.
10. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen
11. Vivian kiest er voor om een optie te nemen op de offerte.
12. Het systeem bevestigt dat er een optie op de offerte is genomen keert terug naar het "Aanvraag detail" scherm.
13. Vivian is klaar en kiest om het scherm te sluiten
14. Het systeem keert terug naar het hoofdmenu

Optie annuleren
Hans belt 2 weken nadat hij een optie heeft genomen op en vertelt Vivian dat hij helaas van zijn baas te horen heeft gekregen dat er op het budget van de introductie moet worden gekort omdat bepaalde kosten duurder uitvielen dan gedacht. Vivian vindt het jammer dat de in optie genomen offerte niet door kan gaan en zegt tegen Hans dat dit wel annuleringskosten met zich meebrengt omdat er al kosten zijn gemaakt. Vivian start het systeem op en annuleert de optie.

1. Vivian kiest vanuit het hoofdmenu voor "Aanvragen"
2. Het systeem toont scherm met overzicht van bestaande aanvragen met optie om een nieuwe aanvraag aan te maken of een bestaande aanvraag te bewerken.
3. Vivian zoekt de aanvraag van de Universiteit Utrecht en selecteert deze aanvraag
4. Het systeem toont het "Aanvraag detail" scherm van de geselecteerde aanvraag
5. Vivian kiest vanuit het "Aanvraag detail" voor "Offertes"
6. Het systeem toont scherm met overzicht van bestaande offertes onder deze aanvraag met een optie om een nieuwe offerte aan te maken of een bestaande offerte te selecteren.
7. Vivian zoekt de offerte op die bestemt was voor de Radboud Universiteit en selecteert deze.
8. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om de offerte te verwijderen, af te drukken, en een optie te nemen
9. Vivian selecteert een de reeds gemaakte offerte waarop een optie is genomen.
10. Het systeem toont het "Offerte detail" scherm van de geselecteerde offerte, met de ingevulde offerte gegevens en de mogelijkheid om te optie te annuleren en de offerte af te drukken
11. Vivian kiest ervoor de optie te annuleren.
12. Het systeem toont invoervelden om de optie te kunnen annuleren.
13. Vivian voert als annuleringskosten het standaard tarief in (150 Euro) aangezien er nog naast administratieve kosten verder geen extra kosten zijn gemaakt. Als reden van annulering geeft ze op "Door bezuinigingen bij de Radboud Universiteit is deze optie geannuleerd"
14. Vivian bevestigt de gegevens om de optie te annuleren.
15. Het systeem print een annuleringsbevestiging met de annuleringskosten van 150 euro.
16. Het systeem bevestigd de annulering van de optie en verwijdering van de offerte en keert terug naar het "Aanvraag detail" scherm.
17. Vivian is klaar en kiest om scherm te sluiten
18. Het systeem keert terug naar het hoofdmenu

Use case 3: Mensen inplannen

BCoE
Vivian is van plan om voor de ophanden zijnde voorstellingen acteurs in te plannen. Zij start het systeem en kiest ervoor om de spelers planning voor de voorstelling van Hans, een medewerker van de Radboud universiteit, in te plannen. Zij kiest Niels Braakensiek als vuurspeler en Eefje de Groot en Esther Eenstroom als Saurus. Nadat Vivian de selectie heeft gemaakt en bevestigd worden Niels, Eefje en Esther van deze planning op de hoogte gebracht.

1. Vivian kiest Acteursplanning in het hoofdmenu.
2. Het systeem toont een overzicht van de voorstellingen.
3. Vivian selecteert de voorstelling van Hans, een medewerker van de Radboud universiteit.
4. Het systeem toont een overzicht van alle acteurs.
5. Vivian selecteert de spelers Niekls Braakensiek, Eefje de Groot en Esther Eenstroom en bevestigt de selectie.
6. Het systeem toont planningsgegevens voor Niekls Braakensiek, Eefje de Groot en Esther Eenstroom.
7. Vivian maakt de gewenste wijzigingen in de getoonde gegevens.
8. Vivian bevestigt de gemaakte wijzigingen.
9. Het systeem stuurt een e-mail naar Niekls Braakensiek, Eefje de Groot en Esther Eenstroom.
10. Het systeem geeft een melding dat de wijzigingen in de planning zijn opgeslagen.
11. Vivian keert terug naar het hoofdmenu.

Alternate Path
Vivian breekt de bewerking af

8. Het systeem geeft een waarschuwing en vraagt Vivian wat er met de niet bevestigde wijzigingen moet gebeuren.
9. De Vivian geeft aan of de wijzigingen opgeslagen of geannuleerd moeten worden.

Keer terug naar 11 in BCoE.

Use case 4: Reparaties rekwisieten beheren

BCoE
Marja werkt in het atelier van Close-Act. Wanneer ze 's ochtends in het atelier binnenkomt checkt ze in het systeem of er beschadigingen gemeld zijn.

1. Marja kiest in het hoofdmenu voor het rekwisieten-overzicht.
2. Ze ziet dat er een defect is gemeld aan een van de drie nieuwe saurussen. De mond gaat niet meer dicht.
3. Marja selecteert dit defect en kiest ervoor de informatie hiervan te wijzigen.
   1. Ze wijzigt de status van het saurus-kostuum om weer te geven dat zij er nu mee bezig is.
   2. Ze bevestigt de wijziging en het systeem neemt haar mee terug naar het rekwisieten-overzicht.
4. Ze sluit het rekwisieten-overzicht en gaat naar het hoofdmenu.

Later op de dag heeft ze de saurus gevonden en gerepareerd, en wil ze haar voortgang hierover opslaan:

1. Marja kiest in het hoofdmenu voor het rekwisieten-overzicht.
2. Ze ziet de melding van het defect aan een van de drie nieuwe saurussen
3. Marja selecteert dit defect en geeft aan dat ze de informatie wil wijzigen.
4. Het systeem geeft invoervelden om de wijzigingen in te vermelden:
   1. Marja voert in dat ze de mond heeft gerepareerd.
   2. Ze update de onderhoudsstatus naar de huidige staat van de saurus.
   3. Ze is tevreden over de wijzigingen en bevestigt deze. Het systeem keert terug naar het rekwisieten-overzicht.
5. Ze ziet dat er een ander defect is geconstateerd aan een White Wing-pak.
6. Ze selecteert dit defect en kiest ervoor de gegevens hierover te bewerken.
7. Ze verandert de status van het defect om weer te geven dat zij er nu mee bezig gaat.
8. Ze bevestigt de wijzigingen en het systeem gaat terug naar het rekwisieten-overzicht.
9. Ze sluit het rekwisieten-overzicht en gaat naar het hoofdmenu.

Aan het eind van de dag is ze nog niet klaar met de White Wing, maar voor ze weggaat update ze wel nog de status van de White Wing.

1. Marja kiest in het hoofdmenu voor het rekwisieten-overzicht.
2. Ze zoekt het betreffende defect aan de White Wing op het rekwisieten-overzicht.
3. Ze selecteert het defect en kiest ervoor de gegevens te wijzigen.
   1. Ze verandert de status van het defect om weer te geven dat ze ermee bezig is geweest.
   2. Ze voert een opmerking in over wat ze heeft gedaan en wat nog moet gebeuren.
   3. Ze bevestigt de wijzigingen en het systeem gaat terug naar het rekwisieten-overzicht.
4. Ze sluit het rekwisieten-overzicht en gaat naar het hoofdmenu.

Use case 5: Logistiek regelen

BCoE

1. Vrachtgegevens invullen

1. Vivian kiest in het hoofdmenu voor de planning.
2. Vivian ziet in het systeem dat de uitvoerdatum van de aanvraag "Damloop2011" over 2 dagen is.
3. Vivian klikt op de betreffende aanvraag en krijgt de gegevens van de aanvraag op haar scherm.
4. De aanvraag staan ingepland om te beginnen om 20:00 op locatie Stadweg 11 in Amsterdam.
5. Vivian kijkt welke benodigde rekwisieten op de dag van uitvoering aanwezig zijn op de locatie van Close-Act.
6. Naar inschatting zal er volgens Vivian één vrachtwagen nodig zijn om de spullen van Tilburg naar Amsterdam rijdt.
7. Vivian belt vervoerder DHL op en vraagt om een vrachtwagen die op de uitvoerdatum de rekwisieten kan komen ophalen op de Oude Hilvarenbeekseweg 38 in Tilburg en kan afleveren op de aanvraag locatie Stadweg 11 in Amsterdam.
8. DHL geeft een aantal ophaalmomenten aan met daarbij de verwachte aflevertijden in Amsterdam en Vivian kiest ervoor om de goederen om 16:00 op te laten halen, zodat ze om 18:00 in Amsterdam zijn.
9. DHL geeft het transportnummer en de definitieve transport tijden door aan Vivian.
10. Vivian gaat in het systeem vanuit de openstaande aanvraag naar het Logistiek regelen scherm.
11. Ze kiest vervolgens voor transport gegevens invullen en vult de vervoerder DHL in plus het ophaal en aflever moment en het vrachtnummer.
12. Wanneer ze klaar is kiest ze opslaan en gaat terug naar het hoofdmenu.

2. Eigen vervoersmiddellen inplannen.

1. Vivian kiest in het hoofdmenu voor de planning.
2. Vivian ziet in het systeem dat de uitvoerdatum van de aanvraag "Damloop2011" over 2 dagen is.
3. Vivian klikt op de betreffende aanvraag en ziet dat de act om 20:00 aanvangt in Amsterdam en dat er al een transport is gepland van de Oude Hilvarenbeekseweg 38 in Tilburg naar locatie Stadweg 11 in Amsterdam.
4. Vivian opent vanuit de aanvraag de planning van de benodigde rekwisieten.
5. Een paar van de benodigde rekwisieten bevinden zijn op de dag van de voorstelling ingepland van 12:00-15:00 voor aanvraag "Living Statues Rotterdam" welke zal plaatsvinden op locatie Dorpstraat 2 in Rotterdam.
6. Naar inschatting zal er volgens Vivian één busje nodig zijn om de rekwisieten vanuit Rotterdam naar Amsterdam te brengen.
7. Vivian gaat in het systeem naar de transport planning en ziet dat er een busje van Close-Act beschikbaar is op die dag.
8. Vivian kiest in de transport planning voor het toevoegen van een eigen vervoersmiddel.
9. Als vervoersmiddel wordt "Close-Act busje 1" gekozen.
10. Het busje wordt vanaf 15:00 tot 0:00 ingeplant voor aanvraag "Damloop2011".
11. Als ophaal locatie wordt "Close-Act" gekozen, als afgifte locatie ook "Close-Act".
12. In de omschrijving zet Vivian dat het busje naar Dorpstraat 2 in Rotterdam moet rijden om de benodigde rekwisieten op te halen en voor 18:00 naar de locatie Stadweg 11 in Amsterdam te brengen.
13. Wanneer ze klaar is kiest ze opslaan en gaat terug naar het hoofdmenu.

3. Picklijst afdrukken

1. Jasper kiest in het hoofdmenu voor het transport overzicht.
2. Jasper ziet in het transport overzicht dat er over 3 uur een transport is voor aanvraag "Damloop2011".
3. Jasper klikt de transport aan en drukt een picklijst van voor de betreffende aanvraag.
4. Jasper gaat terug naar het hoofdmenu
5. Jasper pakt de rekwisieten en zet ze klaar voor transport.

(Op papier wordt afgevinkt welke rekwisieten er mee zijn gegaan met het transport)

Use case 6: Rekwisieten beheren

Rekwisiet inplannen
Vivian maakt op verzoek van Hans een nieuwe aanvraag aan voor de introductie van de Radboud Universiteit op 23 augustus 2011. Vivian heeft al een aanvraag voor Hans aan gemaakt in het systeem en Hans heeft al een optie op de offerte genomen. Tijd om rekwisieten voor de aanvraag in te plannen. Vivian opent het systeem en wil graag de rekwisieten die in de offerte staan inplannen voor 23 augustus 2011.

1. Vivian kiest voor Rekwisieten beheer.
2. Het systeem toont het rekwisieten overzicht.
3. Vivian selecteert Sauruspak_1 uit rekwisieten lijst omdat er 2 Saurussenpakken nodig zijn volgens de geaccepteerde offerte.
4. Het systeem toont het rekwisiet detail scherm van Sauruspak_1 met de eigenschappen, het planningsoverzicht en de mogelijkheid om het rekwisiet in te plannen, en beschadigingen te melden
5. Vivian kiest om de Sauruspak_1 in te plannen.
6. Het systeem toont een aanvragen overzicht met reeds bestaande aanvragen
7. Vivian selecteert de aanvraag van de Radboud Universiteit kiest daarna voor bevestigen
8. Het systeem bevestigd dat Sauruspak_1 is ingepland voor de aanvraag van de Radboud Universiteit en keert terug naar het rekwisiet detail scherm
9. Vivian is klaar en kiest om het scherm te sluiten
10. Het systeem keert terug naar het hoofdmenu

Alternate paths
Rekwisiet bewerken
Na klachten van de acteurs over het gewicht van het Sauruspak hebben de attelier medewerkers de pakken 2 kilo lichter gemaakt door gebruik te maken van lichtere materialen. Vivian heeft tot horen gekregen van attelier medewerker "" dat Sauruspak_1 al helemaal is aangepast. Vivian gaat het systeem in om het gewicht van Sauruspak_1 te bewerken.

1. Vivian kiest voor Rekwisieten beheer.
2. Het systeem toont het rekwisieten overzicht.
3. Vivian selecteert Sauruspak_1 uit rekwisieten lijst omdat ze die wilt bewerken.
4. Het systeem toont het rekwisiet detail scherm van Sauruspak_1 met de eigenschappen, het planningsoverzicht en de mogelijkheid om het rekwisiet in te plannen, en beschadigingen te melden
5. Vivian bewerkt het gewicht van het pak en kiest bevestigen
6. Het systeem bevestigd dat Sauruspak_1 is bewerkt en opgeslagen en keert terug naar het rekwisiet detail scherm
7. Vivian is klaar en kiest om het scherm te sluiten
8. Het systeem keert terug naar het hoofdmenu

Rekwisiet schade melden
Vivian krijgt te horen dat acteur Niels met Sauruspak_1 is gevallen en dat er hierdoor schade is aan de kniestukken van het pak. Vivian gaat het systeem in om de schade aan Sauruspak_1 te melden.

1. Vivian kiest voor Rekwisieten beheer.
2. Het systeem toont het rekwisieten overzicht.
3. Vivian selecteert Sauruspak_1 uit rekwisieten lijst.
4. Het systeem toont het rekwisiet detail scherm van Sauruspak_1 met de eigenschappen, het planningsoverzicht en de mogelijkheid om het rekwisiet in te plannen, en beschadigingen te melden
5. Vivian kiest voor schade melden.
6. Het systeem toont de invulvelden voor de omschrijving van de schade
7. Vivian vult in de omschrijving van de schade de volgende tekst in: "Knie stukken beschadigd, reparatie voor begin volgende act noodzakelijk". Hierna kiest ze voor bevestigen</i>
8. Het systeem bevestigd dat de schade omschrijving is opgeslagen en keert terug naar het rekwisiet detail scherm
9. Vivian is klaar en kiest om het scherm te sluiten
10. Het systeem keert terug naar het hoofdmenu

</ol>
Rekwisiet is al ingepland voor een andere aanvraag die overlapt met de geselecteerde aanvraag
Omdat er 2 Saurussenpakken nodig zijn voor de aanvraag van de introductie van de Radboud Universiteit gaat Vivian in het systeem Sauruspak_2 inplannen.

1. Vivian kiest voor Rekwisieten beheer.
2. Het systeem toont het rekwisieten overzicht.
3. Vivian selecteert Sauruspak_2 uit rekwisieten lijst omdat er 2 Sauruspakken nodig zijn volgens de geaccepteerde offerte.
4. Het systeem toont het rekwisiet detail scherm van Sauruspak_2 met de eigenschappen, het planningsoverzicht en de mogelijkheid om het rekwisiet in te plannen, en beschadigingen te melden
5. Vivian kiest om de Sauruspak_2 in te plannen.
6. Het systeem toont een aanvragen overzicht met reeds bestaande aanvragen
7. Vivian selecteert de aanvraag van de Radboud Universiteit kiest daarna voor bevestigen
8. Het systeem geeft de melding dat het rekwisiet al is ingepland voor een de aanvraag van de introductie van de Universiteit Utrecht en dat deze aanvraag overlapt met de geselecteerde aanvraag
9. Het systeem keert terug naar rekwisiet detail scherm

Use case 7: Beschikbaarheid beheren

BCoE

1. Niels meld zich aan bij het systeem met zijn gebruikersnaam "Niels Braakensiek" en zijn wachtwoord.;
2. Niels komt in de spelersplanning;
3. Niels geeft aan op welke dagen hij is verhinderd;
4. Niels geeft aan voor welke acts hij interesse heeft;
5. Niels Braakensiek meldt zich af bij het systeem.

Alternate paths
Acteur wil zich afmelden

1. Niels meld zich aan bij het systeem met zijn gebruikersnaam "Niels Braakensiek" en zijn wachtwoord.;
2. Niels komt in de spelersplanning;
3. Niels meldt zich af voor een act waar hij interesse in had getoond;
4. Niels meldt zich af bij het systeem.


Acteur wil zich afmelden nadat hij ingepland is

1. Niels meld zich aan bij het systeem met zijn gebruikersnaam "Niels Braakensiek" en zijn wachtwoord.;
2. Niels komt in de spelersplanning;
3. Niels ziet dat hij al is ingepland voor de act waar hij zich nu voor wilde afmelden en kan zich dus niet meer zelf afmelden;
4. Niels meldt zich af bij het systeem.

(Niels neemt contact op met het kantoor om zich alsnog af te melden)

Business rules per UC

Aanvragen beheren

• De datum voor een aanvraag ligt altijd in de toekomst.


Offerte beheren

• De prijs op een offerte mag niet negatief zijn.
• Een offerte mag niet gewijzigd worden nadat hier een optie op is genomen.


Mensen inplannen

• Als een acteur heeft aangegeven dat hij niet beschikbaar is op een bepaalde datum, mag hij daarop niet ingepland worden.
• Een acteur mag niet ingepland worden voor een act die hij (nog) niet kan spelen.
• Een acteur mag niet ingepland worden voor een act waarvoor geen passend kostuum beschikbaar is.
• Een acteur mag niet ingepland worden op een datum in het verleden.
• Een acteur mag niet ingepland worden voordat de klant een optie heeft genomen voor de act.
• Een acteur mag niet ingepland worden als hij op het speelmoment al voor een andere voorstelling is ingepland.


Reparaties rekwisieten beheren

• Een reparatie mag niet ingepland worden als een kostuum op dat moment voor een act is gereserveerd.
• Reparatie van een kostuum dat is gereserveerd voor een act heeft hogere prioriteit.


Rekwisieten beheren

• Rekwisieten mogen niet ingepland worden als reparatie nodig is.
• Rekwisieten mogen niet ingepland worden op een datum in het verleden.
• Rekwisieten mogen niet ingepland worden als ze op dat moment al voor een andere voorstelling zijn ingepland.


Beschikbaarheid beheren

• Acteurs mogen zich ten alle tijde(voor de speeldatum) aanmelden voor een act.
• Acteurs mogen hun beschikbaarheid in het verleden niet wijzigen.
• Acteurs mogen hun beschikbaarheid tot twee weken in de toekomst zelf niet intrekken.
• Acteurs mogen hun beschikbaarheid zelf niet intrekken als ze al in een opdracht ingepland zijn.




Integrated Domain Model



Het domeinmodel geeft een beeld van de organisatie en structuur van de achterliggende database. De objecten in het datamodel corresponderen met de tabellen van een database, de relaties tussen objecten zijn afhankelijkheden, die op basis van de gebruikte constraints soms als velden in de betreffende tabellen worden gemodelleerd, en soms een eigen tabel moeten krijgen. Acties die in of op het systeem worden uitgevoerd worden hierin niet gemodelleerd.

In dit ORM schema hebben we ervoor gekozen om eigenschapsrelaties in het object zelf bij te voegen, zoals dat ook tijdens het vak Domeinmodellering mogelijk was. Dit betekent in onderstaand plaatje dat het object links onze representatie is van het de complete relatie rechts.



Business Rules Catalogue

Nr.	Definitie	Type	S/D	Bron
001	Aanvragen en offertes mogen enkel door geautoriseerde medewerkers achteraf worden gewijzigd	Action Restricting	...	...
002	Niet beschikbare acteurs mogen enkel in overleg met de betreffende acteur alsnog worden ingepland	Action Restricting
003	Acteurs mogen zichzelf niet als onbeschikbaar registreren nadat de voorstelling definitief staat ingepland	Action Restricting
004	Acteurs mogen enkel door geautoriseerde medewerkers uit een definitieve voorstelling laten plannen	Action Restricting
005	Als een acteur uit een definitieve voorstelling wordt gepland dan moet de reden en de geautoriseerde medewerker worden vastgelegd	...
006	Als iemand een mankement aan een rekwisiet opmerkt moet hij dit melden en in het systeem (laten) registreren.	Obligation

Non-Functional Requirements

Non-functional requirements zijn kwaliteitscriteria aan specifieke kenmerken van het systeem. Hierbij moet worden gedacht aan kenmerken als bijvoorbeeld veiligheid, betrouwbaarheid, begrijpelijkheid en bedienbaarheid. Voor een meer volledig overzicht van kenmerken verwijzen we naar ISO_9126. In het ontwerp van de requirements voor een systeem is de kwaliteit van alle hierin genoemde eigenschappen zeer relevant. Echter, omdat de ISO-standaard teveel kenmerken omvat om per stuk te behandelen moeten we hierin een focus bepalen. We zullen ons daarom in het overzicht hieronder beperken tot die kenmerken die speciale aandacht verdienen. Dit betekent uiteraard niet dat kenmerken die ongenoemd blijven worden verwaarloosd.

Flexibiliteit (flexibility)

In de nu gebruikte automatisering wordt veel informatie gemengd in grote invoervelden, bijvoorbeeld in de Outlook agenda. Onze intentie is om hier meer structuur aan te geven door de bulk op te splitsen in relevante, kleinere invoervelden. Hierdoor wordt het combineren, manipuleren en organiseren van data makkelijker. Wat met zich meebrengt dat we ervoor moeten waken volledig te zijn in het samenstellen van de verzameling kleinere, specifiekere invoervelden. Onvolledigheid hierin kan leiden tot een extra papieren administratie en in extrema afschaffing van het systeem.

We moeten er dus zorg voor dragen dat het systeem flexibel genoeg is om de volledige range van informatie die men erin kwijt wil te behappen.

Toegankelijkheid (accessibility)

Waar mensen op meerdere lokaties met een systeem werken moet het vanaf verschillende locaties benaderbaar zijn. Momenteel zijn het acteurs die vanuit huis de planning kunnen inzien en werknemers die op kantoor met het systeem werken. In een nieuw systeem zullen ook de werknemers in het atelier op locatie willen en kunnen interacteren. Het is dus zaak dat hiertoe functionaliteit geboden kan worden, zonder dat de betrouwbaarheid in het gedrang komt. Dit betekend dat iedere interactie met het systeem thread-safe moet zijn, omdat een andere gebruiker op een andere locatie op hetzelfde moment een andere wijziging kan doorvoeren.

Responsiesnelheid (time behaviour)

De structuur in de informatie in het systeem brengt met zich mee dat het voor de gebruiker mogelijk moet zijn deze informatie snel en specifiek te raadplegen. Zo willen de medewerkers in het atelier misschien weten welk kostuum het vaakst gebruikt is sinds de laatste oplapbeurt. Ook aan de telefoon met een klant moet informatie en analyse van die informatie snel beschikbaar zijn. De responsiesnelheid van het systeem kan op die manier bijdragen aan de ondersteunende rol die het systeem heeft in de kwaliteit van de communicatie met de klant.

Addendum

Terminological Definitions

• Opdrachtgever: Een bedrijf dat de opdracht geeft voor een voorstelling.
• Contactpersoon: Een persoon dat verbonden is aan de opdrachtgever dat fungeert is aanspreekpunt voor een betreffende opdracht.
• Aanvraag: Een opdracht van een opdrachtgever voor een voorstelling.
• Voorstelling: Eén of meerdere acts.
• Offerte: Een voorstel voor een aanvraag waaraan een prijs is gekoppeld.
• Optie: Goedkeuring van de opdrachtgever over de inhoud en prijs van een offerte.
• Act: Een voorstelling die wordt opgevoerd door Close-Act bestaande uit een min of meer vaste set aan rollen en rekwisieten.
• Rollen: Onderdeel van een act welke gespeeld wordt door één acteur.
• Kostuum: Pak of kledingstukken welke behoren bij een rol.
• Speler: Een acteur die één of meerdere rol speelt.
• Rekwisieten: Onderdelen van een act welke niet als kostuum kunnen worden aangeduid.
• Medewerker: Een rekwisiet als persoon die nodig is bij het uitvoeren van een act.
• Planning: Een agenda welke de beschikbaarheid van acteurs, kostuums en rekwisieten beschrijft.
• Picklijst: Een overzicht waarin staat welke materialen in welke hoeveelheden moeten worden verzameld, deze lijst heeft een unieke identificatie.

Executive Sponsor Viewpoint

Het is belangrijk op te merken dat dit rapport gemaakt wordt in opdracht van een externe partij. Hoewel Close-Act baat heeft bij dit project omdat het erop gericht is een probleem op te lossen wat daar speelt, is Close-Act zelf is niet de directe opdrachtgever. Onze opdrachtgever (Niels Braakensiek) behartigt wel de belangen van Close-Act en in die zin zullen we zijn beeld van de problemen die oorzaak zijn van dit project als viewpoint gebruiken.

Aan de hand van de volgende vragen zullen we proberen weer te geven hoe Niels' beeld van het probleem is:

• What is the problem being solved?

De oorzaak van het probleem ligt hem erin dat de schaal van het bedrijf de gebruikte automatisering is ontstegen. Dit resulteert in een gammele administratie waarin met regelmaat kostuums, acts en acteurs dubbel worden geboekt. Tevens is er informatie die niet in de huidige systemen past waardoor belangrijke bedrijfsinformatie bij medewerkers ligt. Hierdoor is er een grote afhankelijkheid van het bedrijf aan kennis en beschikbaarheid van individuele werknemers. Voor een bedrijf als Close-Act, dat kwalitatief zowel goede producten als communicatie wil leveren, is dit geen wenselijke situatie.

• Why is a system required?

Problemen als die hierboven zorgen voor misverstanden en een vergroot risico bij levering van produkten. Er ontbreken pakken of er zijn niet genoeg acteurs beschikbaar. Dit geeft een onprofessionele indruk en kan de relatie met de klant dusdanig beschadigen dat die voor een vervolgopdracht af zal zien.

• Why is a computer system required?

Een elektronisch systeem heeft verschillende voordelen boven een handmatige administratie die gewenst zijn door Close-Act. Data over optredens moet beschikbaar zijn op verschillende lokaties(acteurs, medewerkers van het atelier, de administratie zelf). Ook moet sommige informatie makkelijk gecombineerd, geordend en snel geraadpleegd kunnen worden.

• Who will be affected by the system implementation? How?

Door toegenomen flexibiliteit en snelheid in de administratie zal op het kantoor tijdswinst worden geboekt. Medewerkers zullen beter inzicht en overzicht hebben over beschikbaarheid van data, acteurs en kostuums waardoor de communicatie met de klant kwalitatief zal verbeteren. Voor medewerkers van het atelier en acteurs zal de geboden functionaliteit ongeveer gelijk blijven, al zal het overzicht over deze informatie verbeteren en zal deze actueler zijn.