Brontekst bekijken van Requirements Engineering/het werk/werkstuk/2011-12/Groep 03

{{RE/Titelpagina
|titel = 
|auteurs=Jeroen Bakker, Harm de Wit, Sjoerd van Oostenbrugge, Laurens Dijk
}}


= Introduction =
Close-Act Theatre is een professioneel gezelschap met steltlopers, dansers, muzikanten, vuurspelers en acrobaten, die allen regelmatig samen trainen en repeteren. Daarnaast beschikt Close-Act over een atelier met kostuumontwerpers, beeldend kunstenaars en grafisch en industrieel ontwerpers. 
Het gezelschap van Close-act treedt op in de hele wereld en speelt vaak op  (straat)theaterfestivals en grootschalige evenementen. Door de vele optredens verspreid over de wereld en de strakke tijdsplanning is het van groot belang dat de (spelers)planning en de logistieke bijkomstigheden goed worden gecoördineerd. <ref>Close-Act http://www.closeact.nl/aboutNl.html</ref>

Momenteel wordt dit alles geregeld door het managementteam van Close-Act, vanuit het kantoor in Tilburg. Het management gebruikt hiervoor meerdere informatiesystemen, waaronder een (Outlook)agenda, een spelersplanner en een kostuumplanner.
Het probleem met de huidige informatiesystemen is dat er erg veel informatie omslachtig en op meerdere plaatsen wordt verwerkt en opgeslagen. Een bijkomend probleem is dat de spelersplanning niet naar behoren functioneert en waardoor het erg veel tijd kost om spelers bij een optreden te plannen en waardoor er onnodig veel fouten worden gemaakt.

Het doel van dit document is het beschrijven en vastleggen van de gewenste functionaliteiten van het nieuwe systeem. Deze functionaliteiten zullen worden beschreven aan de hand van use cases.
Het document wordt ingeleid met een beschrijving van de huidige problemen binnen Close-Act. Vervolgens worden de doelstellingen voor het nieuwe systeem beschreven en uiteindelijk worden de gewenste functionaliteiten in de detail uitgewerkt.


== Problem Statement ==

Close-Act gebruikt momenteel een aantal verschillende tools voor het beheren van alle informatie rond het organiseren van voorstellingen. De belangrijkste applicaties zijn:

{|class="wikitable"
! Product !! Tool
|- 
| Agenda || Outlook
|- 
| Spelersplanner || Excel
|- 
| Kostuumplanner || Excel
|- 
| Informatie Opdrachtgevers || Excel
|- 
| Opdracht informatie || Outlook + andere bestanden
|- 
| Spelers informatie || Excel + geheugen werknemers
|}

Het probleem is dat er momenteel geen voldoende geïntegreerd systeem bestaat waarmee alle organisatorische taken kunnen worden uitgevoerd. Hierdoor is het plannen van spelers omslachtig en de kans op fouten tijdens het proces groot. Daarnaast kent het huidige systeem hierdoor veel dubbel ingevoerde gegevens. Doordat in het huidige systeem de de business rules van Close-Act onvoldoende geïmplementeerd zijn, worden er veel onnodige fouten gemaakt.

Er zijn nu maar weinig kantoormedewerkers verantwoordelijk voor de management en het beheren van alle informatie. Voor nieuwe kantoormedewerkers is het erg lastig om al deze informatie te overzien. Dit kost erg veel tijd en zorgt ook weer voor fouten.

Als laatste weten de spelers niet van elkaar hoe vaak en wanneer zij optreden. Dit geeft de spelers een vertekend beeld van elkaars inzet voor Close-Act. De enige die deze informatie weet zijn degene die verantwoordelijk zijn voor de planning, de kantoormedewerkers.

Het doel van het project is het verder automatiseren en integreren van de huidige systemen in een holistische planningsapplicatie. De kern van het project zal liggen rondom de agenda en de spelersplanner.

= Case analysis =
== Stakeholder analysis ==

{|class="wikitable"
! Nummer !! Naam !! Functie !! Omschrijving
|- 
| 1. ||''Niels Braakensiek'' || Speler & opdrachtgever
| Niels Braakensiek is een speler bij Close-Act. In deze casus vertegenwoordigt hij als contactpersoon alle partijen binnen Close-Act.
|- 
| 2. ||''Kantoormedewerkers''|| Administratie, management en verkoop
| De kantoormedewerkers zijn de voornaamste gebruikers van het systeem. Zij houden alle administratieve taken bij, onderhouden relaties en managen de rest van het personeel.
|- 
| 3. ||''Spelers''|| Uitvoeren voorstellingen
| De artiesten voeren uitendelijk de voorstellingen uit. Zij zijn afhankelijk van het systeem vanwege de informatie die zij moeten krijgen. 
|- 
| 4. ||''Ateliermedewerkers''|| Onderhouden en maken kostuums
| Close-act maakt gebruik van zeer veel en uiteenlopende kostuums. De ateliermedewerkers zijn verantwoordelijk voor het onderhouden en maken van deze kostuums
|- 
| 5. ||''Hesther Melief en Tonny Aerts''|| Leiders en financiëel directeur   
| Melief en Aerts zijn de leiders en financieel directeurs van Close-Act. Zij moeten als eindverantwoordelijken toestemming geven voor het systeem. In dit project zal Niels Braakensiek echter als sponsor optreden
|}

== Mission and vision statement ==

'''Mission''' 
Doordat de organisatie Close-Act in de loop van de jaren steeds groter is geworden en steeds meer optredens verzorgt, voldoet het huidige informatiesysteem niet meer aan de wensen. Om de dagelijkse werkzaamheden beter te kunnen ondersteunen en de huidige processen beter te stroomlijnen, is het van essentieel belang dat het huidige informatiesysteem wordt vervangen door een nieuw (toekomst bestendig) informatiesysteem. 

'''Vision''' 
Het doel is om uiteindelijk een systeem te realiseren waarin alle informatie met betrekking tot de planning, spelers en optredens kan worden beheerd. Het systeem moet eenvoudig in gebruik zijn voor zowel de mensen op kantoor als voor de spelers

'''Values'''
Het is erg belangrijk dat het nieuwe informatiesysteem niet alleen verbetering voor het kantoorpersoon met zich meebrengt maar het nieuwe systeem moet ook duidelijk een toegevoegde waarde hebben voor de overige partijen, zoals de spelers. Het is dus belangrijk dat men tijdens de analyse naar alle soorten gebruikers binnen Close-Act kijkt.

== Scope ==

In dit onderdeel worden de delen aangegeven die niet onderdeel zijn van het project:

- Het resultaat wordt niet gerealiseerd
<br/>- Geen technisch ontwerp (netwerkstructuur, datastructuur)


== Statement of work ==

'''Contactgegevens'''

{|class="wikitable"
! Naam !! E-mail !! Functie
|-
| Jeroen Bakker || jeroen.bakker@student.ru.nl ||  Projectleider en contactpersoon
|-
| Sjoerd van Oostenbrugge || svan.oostenbrugge@student.ru.nl ||  -
|-
| Harm de Wit || harmdewit@gmail.com || -
|-
| Laurens van Dijk || LaurensvanDijk@student.ru.nl ||  -
|-
| Niels Braakensiek || n.braakensiek@student.ru.nl ||  Opdrachtgever
|}


=='''Werkplan'''==

{|class="wikitable"
!Deliverable !! Verantwoordelijke !! Facade iteratie (014-04-2012) !! Status !! Filled iteratie  !! Status !! Focused iteratie !! Status
|-
| Introduction || Sjoerd || Voorlopige versie || align=center|[[Bestand:vinkje.gif|14px]] || Voorlopige versie || align=center|[[Bestand:vinkje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Problem statement || Jeroen || Zo goed mogelijk || align=center|[[Bestand:vinkje.gif|14px]] || Zo goed mogelijk || align=center|[[Bestand:vinkje.gif|14px]] || Compleet || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Stakeholder analysis || Sjoerd || Zo goed mogelijk || align=center|[[Bestand:vinkje.gif|14px]] || Zo goed mogelijk || align=center|[[Bestand:vinkje.gif|14px]] || Compleet || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Mission-vision-values || Sjoerd || Compleet || align=center|[[Bestand:vinkje.gif|14px]] || Compleet || align=center|[[Bestand:vinkje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Statement of work || Groep || Compleet, en ''up-to-date'' || align=center|[[Bestand:vinkje.gif|14px]] || Compleet, en ''up-to-date'' || align=center|[[Bestand:vinkje.gif|14px]] || Compleet, en ''up-to-date''  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Risk analysis || Jeroen/Groep || Compleet, en ''up-to-date'' || align=center|[[Bestand:vinkje.gif|14px]] || Compleet, en ''up-to-date'' || align=center|[[Bestand:vinkje.gif|14px]] || Compleet, en ''up-to-date''  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Use case survery || Jeroen || Zo goed mogelijk ||  align=center|[[Bestand:vinkje.gif|14px]] || Bijna Compleet || align=center|[[Bestand:vinkje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Integrated UC diagram || Jeroen || Compleet (of voorlopig) || align=center|[[Bestand:vinkje.gif|14px]] || Compleet || align=center|[[Bestand:vinkje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Use cases || Groep || Nog niet! || align=center|[[Bestand:kruisje.gif|14px]] || Filled level || align=center|[[Bestand:vinkje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Scenarios || Groep || Nog niet! || align=center|[[Bestand:kruisje.gif|14px]] || Meerdere per UC || align=center|[[Bestand:vinkje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Domain models || Groep || Nog niet! || align=center|[[Bestand:kruisje.gif|14px]] || Gedeeltelijk compleet || align=center|[[Bestand:vinkje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Integrated domain model || Groep || Nog niet! ||align=center|[[Bestand:kruisje.gif|14px]] || Gedeeltelijk compleet || align=center|[[Bestand:vinkje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Business rules catalogue || Groep || Nog niet! ||align=center| [[Bestand:kruisje.gif|14px]] || Gedeeltelijk compleet || align=center|[[Bestand:vinkje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Non-functional requirements || Groep || Notities || align=center|[[Bestand:kruisje.gif|14px]] || Gedeeltelijk compleet || align=center|[[Bestand:vinkje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Terminological definitions || Groep || Notities || align=center|[[Bestand:kruisje.gif|14px]] || Gedeeltelijk compleet || align=center|[[Bestand:vinkje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Executive sponsor viewpoint || Groep || Niet nodig || align=center|[[Bestand:kruisje.gif|14px]] || Niet nodig || align=center|[[Bestand:kruisje.gif|14px]] || Niet nodig  || align=center|[[Bestand:kruisje.gif|14px]]
|- 
| Use case tests || - || Notities || align=center|[[Bestand:kruisje.gif|14px]] || Zo goed mogelijk || align=center|[[Bestand:kruisje.gif|14px]] || Compleet  || align=center|[[Bestand:vinkje.gif|14px]]
|-
| Business process definitions || - || Indien relevant || align=center|[[Bestand:kruisje.gif|14px]] || Indien relevant || align=center|[[Bestand:kruisje.gif|14px]] || Indien relevant  || align=center|[[Bestand:kruisje.gif|14px]]
|-
| GUI metaphors / storyboards || - || Indien relevant || align=center|[[Bestand:kruisje.gif|14px]] || Indien relevant || align=center|[[Bestand:kruisje.gif|14px]] || Indien relevant  || align=center|[[Bestand:kruisje.gif|14px]]
|}

'''Legenda'''

[[Bestand:vinkje.gif|14px]] : Voldaan.

[[Bestand:kruisje.gif|14px]] : Niet voldaan / Niet van toepassing.

[[Bestand:busy.gif|14px]] : Gestart / Wordt momenteel aan gewerkt binnen Wiki.

== Risk analysis ==

{|class="wikitable"
! # !! Category !! Risk !! Solution needed by !! Status !! Days lost !! Expectancy factor !! Risk factor(1-10)
|-
| 01 || Groepsleden/planning || Groepslid stopt of langdurige ziekte || Groep || Gesloten || - || 10% || 3
|-
| 02 || Groepsleden/planning || Onvoldoende inzet één of meerdere groepsleden || Groep || Gesloten || - || 15% || 3
|-
| 03 || Opdrachtgever/stakeholder || De stakeholder is niet tevreden met de opgeleverde stukken gedurende het project || Groep || Gesloten || - || 10% || 8
|-
| 04 || Opdrachtgever/stakeholder || Faillisement opdrachtgever || RU || Gesloten || - || 1% || 10
|-
| 05 || Dataverlies || Dataverlies bijvoorbeeld veroorzaakt door een crash van de wiki server of systeem van groepslid || Groep/RU || Gesloten || - || 5% || 7
|-
| 06 || Opdrachtgever/stakeholder || Communicatieproblemen tussen groep en stakeholder || Groep/Stakeholder || Gesloten || - || 10% || 5
|}

= Requirements =
== Use cases ==

=== Use case survey ===
{|class="wikitable"
! # !! Name !! Description !! Initiating actor
|-
| 01 || Toevoegen opdrachten || De kantoormedewerker voegt opdrachten toe aan de agenda. || Kantoormedewerker
|-
| 02 || Beheren medewerkers || De kantoormedewerker voegt medewerkers toe/verwijderd spelers en koppelt mits van toepassing rollen/kostuums aan medewerkers. || Kantoormedewerker
|-
| 03 || Beheren kostuums || De kantoormedewerker of ateliermedewerker voegt nieuwe kostuums toe/verwijderd kostuums of past kostuums aan. || Kantoormedewerker/Ateliermedewerker
|-
| 04 || Beheren agenda || Inzien van de agenda met alle aanwezige opdrachten, opdrachten verwijderen/aanpassen. || Kantoormedewerker
|-
| 05 || Beheren beschikbaarheid || De beschikbaarheid van een speler aanpassen door speler zelf of kantoormedewerker. || Speler/Kantoormedewerker
|-
| 06 || Beheren relaties || De kantoormedewerker kan de informatie over een opdrachtgever inzien/aanpassen. || Kantoormedewerker
|-
| 07 || Beheren producties || De kantoormedewerker of ateliermedewerker kan de informatie van een productie inzien/aanpassen. || Kantoormedewerker/Ateliermedewerker
|- 
|}

=== Integrated use case diagram ===

[[Bestand:Req_Groep3_2012_UCdiagram1_v2.jpg]]

=== Individual use cases ===


====Beheren Medewerkers====

{|class="wikitable"
! Use Case: !! Beheren medewerkers
|-
| Use case diagram || [[Bestand:Req_Groep3_2012_UC_BM_v2.jpg]]
|-
| Description || Medewerkers toevoegen, verwijderen of bewerken.
|-
| Source || Interview
|-
| Version || 1.0
|-
| Basic course of events 
|
1. De kantoormedewerker opent het medewerkersbeheer scherm.
<br/>2. Het systeem vraagt om de benodigde gegevens om een nieuwe medewerker toe te voegen.
<br/>3. De medewerker voert de benodigde gegevens in.
<br/>4. De medewerker kiest voor opslaan van de gegevens.
<br/>5. Het systeem bevestigt de toevoeging van de nieuwe medewerker.
|-
| Alternate paths 
|
1a. De kantoormedewerker opent de gegevens van de betreffende medewerker.
<br/>2a. Het systeem toont de gegevens van de geselecteerde medewerker.
<br/>3a. De kantoormedewerker wijzigt een of meerdere gegevens van de medewerker.
<br/>4a. De kantoormedewerker kiest voor opslaan van de gegevens.
<br/>5a. Het systeem bevestigt de wijziging van de gegevens.

1b. De kantoormedewerker opent de gegevens van de betreffende medewerker.
<br/>2b. Het systeem toont de gegevens van de geselecteerde medewerker.
<br/>3b. De kantoormedewerker kiest voor verwijderen van medewerker.
<br/>4b. Het systeem bevestigt het verwijderen van de medewerker.
|-
| Exception paths
|
5. De medewerker is al aanwezig in het systeem, het systeem geeft een foutmelding.
|-
| Preconditions 
| 
De kantoormedewerker is ingelogd in het systeem
|-
| Postconditions 
|
De eventuele wijzigingen zijn in het systeem aangebracht
|-
| Related business rules
|
*BM:01. Van een medewerker moet minimaal de voornaam, achternaam en geboortedatum bekend zijn.
|}

=====Domain Model=====

[[Bestand:Req_Groep3_2012_domainmodel_beherenmedewerkers_v1.jpg]]

=====Scenarios=====
{| class="wikitable"
|+
! Use Case: Beheren medewerkers
|-
|
* Kantoormedewerker Jan Janssen navigeert naar 'Medewerkersbeheer'
* Het systeem toont een overzicht van aanwezige medewerkers en mogelijke acties
 - Niels
 - Robin
 - Paul
 - Irene
* Jan Janssen kiest voor toevoegen van nieuwe medewerker
* Het systeem vraagt om de benodigde informatie
* Jan Janssen vult in:
** Voornaam : Jeroen
** Achternaam : Bakker
** Geboortedatum : 03-02-1989
** Functie : Speler
** Straatnaam : Juno
** Huisnummer : 46
** Postcode : 6661JD
** Woonplaats : Elst
** Email : jbakker@mail.nl
** Telefoon : 0612345678
* Jan Janssen kiest voor opslaan
* Het systeem bevestigt de toevoeging van een nieuwe medewerker
|}

{| class="wikitable"
|+
! Use Case:Beheren medewerkers (Alternative path 1)
|-
|
* Kantoormedewerker Jan Janssen navigeert naar 'Medewerkersbeheer'
* Het systeem toont een overzicht van aanwezige medewerkers en mogelijke acties
 - Niels
 - Robin
 - Paul
 - Irene
* Jan Janssen kiest de medewerker die aangepast dient te worden
* Het systeem toont de gegevens van de betreffende medewerker
** Voornaam : Jeroen
** Achternaam : Bakker
** Geboortedatum : 03-02-1989
** Functie : Speler
** Straatnaam : Juno
** Huisnummer : 46
** Postcode : 6661JD
** Woonplaats : Elst
** Email : jbakker@mail.nl
** Telefoon : 0612345678
* Jan Janssen wijzigt het telefoonnummer in 0609876543 en bevestigt de nieuwe gegevens
* Het systeem bevestigt de wijziging van de gegevens
|}

{| class="wikitable"
|+
! Use Case: Beheren medewerkers (Alternative path 2)
|-
|
* Jan Janssen navigeert naar 'Medewerkersbeheer'
* Het systeem toont een overzicht van aanwezige medewerkers en mogelijke acties
 - Niels
 - Robin
 - Paul
 - Irene
* Jan Janssen kiest de medewerker die verwijderd dient te worden
* Het systeem vraagt of de speler daadwerkelijk verwijderd dient te worden
* Jan Janssen kiest voor 'ja'
* Het systeem bevestigt het verwijderen van de speler
|}

====Toevoegen Opdrachten====

{|class="wikitable"
! Use Case: !! Toevoegen opdrachten
|-
| Use case diagram || [[Bestand:Req_Groep3_2012_UC_TO_V2.jpg]]
|-
| Description || Opdrachten toevoegen aan de agenda.
|-
| Source || Interview
|-
| Version || 1.0
|-
| Basic course of events 
|
1. De medewerker opent het toevoegen opdracht scherm.
<br/>2. Het systeem toont de opdrachtplanner en mogelijkheden.
<br/>3. De medewerker kiest voor het toevoegen van een opdracht.
<br/>4. Het systeem vraagt om de benodigde gegevens voor het toevoegen van een nieuwe opdracht.
<br/>5. De medewerker voert de benodigde gegevens in.
<br/>6. Het systeem bevestigt de aanpassing en toont de planner.
|-
| Alternate paths 
|
7a. De medewerker voegt nog een opdracht toe.
<br/>Terug naar BCoE stap 2

|-
| Exception paths
|
6a. Er bestaat al een identieke opdracht, het systeem geeft een foutmelding.
<br/>Terug naar BCoE stap 2
|-
| Preconditions 
| 
De medewerker is ingelogd in het systeem.
|-
| Postconditions 
|
Eventuele wijzigingen zijn opgeslagen.
|-
| Related business rules
|
*BO:01. Aan een opdracht kan te allen tijden informatie worden toegevoegd.
|}

=====Domain Model=====

[[Bestand:Req_Groep3_2012_ORM_OPTIES.jpg]]

=====Scenarios=====

{| class="wikitable"
|+
! Use Case:  Toevoegen opdrachten, BCOE
|-
|
* De kantoormedewerker Niels Braakensiek opent het opdrachten toevoegen scherm.
* Het systeem toont de beschikbare opties aan de kantoormedewerker.
* De kantoormedewerker kiest de optie 'Opdracht toevoegen'.
* Het systeem vraagt om de benodigde informatie.
* De kantoormedewerker vult in:
 - Datum: 09-08-2012
 - Opdracht: Saurus
 - Spelerslijst: Jos Bruiningen, [..]
 - Materiaallijst: Saurus
 - Locatie: Nijmegen
 - Optie/Definitief : Optie
* De kantoormedewerker bevestigt zijn keuze.
* Het systeem bevestigt de wijziging en toont de planner.
* De kantoormedewerker sluit het systeem.
|}

====Beheren Agenda====

{| class="wikitable"
! Use Case: !! Beheren agenda
|-
| Use case diagram || [[Bestand:Req_Groep3_2012_UC_BA_V4.jpg]]
|-
| Description || Overzicht van aanwezige opdrachten bekijken/aanpassen/verwijderen.
|-
| Source || Interview
|-
| Version || 1.0
|-
| Basic course of events
|
1. De medewerker opent de agenda.
<br/>2. Het systeem toont de opdrachtplanner.
<br/>3. De medewerker filtert de resultaten.
<br/>4. De medewerker kiest een opdracht.
<br/>5. Het systeem toont de opdrachtinformatie.
|-
| Alternate paths
|
1a. De medewerker opent de agenda.
<br/>2a. Het systeem toont de opdrachtplanner.
<br/>3a. De medewerker filtert de resultaten.
<br/>4a. De medewerker kiest een opdracht.
<br/>5a. Het systeem toont de opdrachtinformatie.
<br/>6a. De medewerker kiest voor aanpassen opdracht.
<br/>7a. Het systeem toont de opdrachtinformatie
<br/>8a. De medewerker past de gegevens aan en kiest voor opslaan
<br/>9a. Het systeem bevestigt de wijziging van de opdracht

6b. De medewerker kiest voor het verwijderen van een opdracht.
<br/>7b. Het systeem vraagt om een bevestiging.
<br/>8b. De medewerker bevestigt de keuze.
<br/>9b. Het systeem bevestigt het verwijderen van de opdracht en keert terug naar de agenda.

|-
| Exception paths
|
7b. De te verwijderen opdracht is al verwijderd, het systeem geeft een foutmelding
<br/>Terug naar BCoE stap 2

9a. Niet alle gegevens zijn ingevuld, het systeem geeft een foutmelding.
<br/>Terug naar BCoE stap 5
|-
| Preconditions
|
De medewerker is ingelogd in het systeem.
|-
| Postconditions
|
De eventuele wijzigingen zijn in het systeem aangebracht
|-
| Related business rules

| 
*BA:01. Alleen kantoormedewerkers mogen opdrachtgegevens aanpassen. 

|}

=====Domain Model=====

[[Bestand:Req_Groep3_2012_ORM_AGENDA.jpg]]

=====Scenarios=====

{| class="wikitable"
|+
! Use Case:  Beheren Agenda, BCOE
|-
|
* De kantoormedewerker Jan Janssen opent de agenda.
* Het systeem toont de opdrachtplanner.
* Jan Janssen filtert de resultaten op 16 juni t/m 20 juni.
* Jan Janssen kiest de opdracht 'Saurus'.
* Het systeem toont getdetailleerde informatie over de opdracht 'Saurus'.
|}

{| class="wikitable"
|+
! Use Case:  Beheren Agenda opdracht wijzigen
|-
|
* De kantoormedewerker Niels Braakensiek opent de agenda.
* Het systeem toont de opdrachtplanner
* Niels Braakensiek filtert de resultaten op 16 juni t/m 20 juni.
* Niels Braakensiek kiest de opdracht 'Saurus'
* Het systeem toont getdetailleerde informatie over de opdracht 'Saurus'.
* Niels Braakensiek kiest voor de optie 'aanpassen opdracht'
* Niels Braakensiek voegt informatie toe aan de opdracht 'Saurus'.
* Het systeem bevestigt de wijziging van de opdracht en toont de opdrachtplanner.
|}

{| class="wikitable"
|+
! Use Case:  Beheren Agenda, verwijderen opdracht.
|-
|
* De kantoormedewerker Niels Braakensiek opent de agenda.
* Niels Braakensiek filtert de resultaten op 16 juni t/m 20 juni.
* Niels Braakensiek kiest de opdracht 'Saurus'.
* Het systeem toont getdetailleerde informatie over de opdracht 'Saurus'.
* Niels Braakensiek verwijderd de opdracht 'Saurus'.
* Het systeem vraagt of de opdracht daadwerkelijk verwijderd dient te worden.
* Niels Braakensiek  kiest voor 'ja' .
* Het systeem bevestigt het verwijderen van de opdracht en toont de agenda. 
|}

====Beheren beschikbaarheid====

{|class="wikitable"
! Use Case: !! Beheren beschikbaarheid
|-
| Use case diagram || [[Bestand:Req_Groep3_2012_UC_BB_V3.jpg]]
|-
| Description || Beschikbaarheid van de speler opgeven of wijzigen.
|-
| Source || Interview
|-
| Version || 1.0
|-
| Basic course of events 
|
1. De Speler opent het beschikbaarheidsbeheer scherm.
<br/>2. Het systeem toont een kalenderoverzicht inclusief de geplande opdrachten. 
<br/>3. De speler selecteert de data waarop hij/zij beschikbaar is.
<br/>4. Het systeem  controleert de ingevoerde data en geeft een bevestiging.
<br/>5. Het systeem toont de informatie over de geplande optredens.
|-
| Alternate paths 
|
3a. De speler wijzigt de data waarop hij/zij beschikbaar is.
<br/>Terug naar BCoE stap 4
<br/>
<br/>1b. De kantoormedewerker wilt de beschikbaarheid van een speler aanpassen.
<br/>2b. Het systeem toont een kalenderoverzicht inclusief de geplande opdrachten. 
<br/>3b. De kantoormedewerker selecteert de gewenste speler.
<br/>4b. De kantoormedewerker past de beschikbaarheid van de speler aan.
<br/>Terug naar BCoE stap 4.
|-
| Exception paths
|
4. Het wijzigen van de beschikbaarheid is buiten de termijn van 3 weken en dus niet meer mogelijk.
|-
| Preconditions 
| De medewerker is ingelogd in het systeem
|-
| Postconditions 
|
De eventuele wijzigingen zijn in de beschikbaarheidsplanning aangebracht
|-
| Related business rules
|
*BBS:01. Spelers mogen zich altijd 'automatisch' (1 week voor de speeldatum) aanmelden voor een act.
*BBS:02. Spelers mogen hun beschikbaarheid binnen een termijn van 3 weken voor het optreden, niet meer 'automatisch' wijzigen. Het wijzigen binnen dit termijn kan alleen gedaan worden door kantoormedewerkers van Close-Act.
*BBS:03 .Spelers mogen hun beschikbaarheid in het verleden niet wijzigen. 

|}

=====Domain Model=====
[[Bestand:s4159713-DM Beschikbaarheid opgeven.jpg]]

=====Scenarios=====
{| class="wikitable"
|+
! Use Case:  Beheren beschikbaarheid
|-
|
* De speler Jos Bruiningen opent op 23 mei 2012 het 'beschikbaarheidsbeheer'
* Het systeem toont een agenda van het huidige kwartaal met hierbij de geplande optredens:
 - 26 juni: festival Zeeland 
 - 27 t/m 30 juni: straatfeest Barcelona
 - 1 augustus: Appelpop Tiel
* Jos Bruiningen schrijft zich in voor het festival in Zeeland op 26 juni.
* Het systeem controleert de ingevulde beschikbaarheid en geeft een notificatie dat het opgeven van de beschikbaarheid is gelukt.
* Het systeem toont (gedetailleerde) informatie over de geplande opdracht.
|}

{| class="wikitable"
|+
! Use Case:  Beheren beschikbaarheid (Alternative  path 1)
|-
|
* De speler Peter Vermeer opent op 10 juni 2012 het 'beschikbaarheidsbeheer'
* Het systeem toont een agenda van het huidige kwartaal met hierbij de geplande optredens:
 - 26 juni: festival Zeeland '''(Peter Vermeer is hier al ingepland door Close-Act)'''
 - 27 t/m 30 juni: straatfeest Barcelona
 - 1 augustus: Appelpop Tiel
* Jos Bruiningen is helaas verhinderd op 26 juni en wilt zijn beschikbaarheid wijzigen.
* Het systeem controleert de ingevulde beschikbaarheid en geeft een notificatie dat het wijzigen van de beschikbaarheid, binnen een termijn van 3 weken voor het optreden niet meer 'automatisch' mogelijk is.
* Het systeem toont weer het kwartaaloverzicht.
|}

{| class="wikitable"
|+
! Use Case:  Beheren beschikbaarheid (Alternative  path 2)
|-
|
* De kantoormedewerker Adri van Houwelingen opent op 22 juni 2012 het 'beschikbaarheidsbeheer'
* Het systeem toont een agenda van het huidige kwartaal met hierbij de geplande optredens:
 - 26 juni: festival Zeeland '''(Peter Vermeer is hier al ingepland door Close-Act)'''
 - 27 t/m 30 juni: straatfeest Barcelona
 - 1 augustus: Appelpop Tiel
* Via de telefoon heeft Adri van Houwelingen te horen gekregen dat Jos Bruiningen is verhinderd op 26 juni en wilt zijn beschikbaarheid wijzigen.
* Adri van Houwelingen past de beschikbaarheid van Peter Vermeer aan.
* Het systeem controleert de ingevulde beschikbaarheid en geeft toont een bevestiging.
* Het systeem toont (gedetailleerde) informatie over de geplande opdracht.
|}

====Beheren Kostuums====

{|class="wikitable"
! Use Case: !! Beheren kostuums
|-
| Use case diagram || [[Bestand:Req_Groep3_2012_UC_BK_V2.jpg]]
|-
| Description || Kostuums toevoegen, bewerken en verwijderen
|-
| Source || Interview
|-
| Version || 1.0
|-
| Basic course of events 
| 
1. De medewerker opent het kostuumbeheer scherm
<br/>2. Het systeem toont een overzicht van de kostuums
<br/>3. De medewerker kiest voor het toevoegen van een nieuw kostuum
<br/>4. Het systeem vraagt om de benodigde informatie
<br/>5. De medewerker voert de nieuwe informatie in
<br/>6. De medewerker slaat het nieuwe kostuum op
<br/>7. Het systeem geeft een notificatie dat het kostuum is opgeslagen
<br/>8. Het systeem toont een overzicht van de kostuums
|-
| Alternate paths 
|
3a. De medewerker geeft aan een kostuum te willen bewerken
<br/>4a. Het systeem toont de gegevens van het kostuum
<br/>5a. De medewerker bewerkt de gegevens
<br/>6a. De medewerker slaat het gewijzigde kostuum op
<br/>7a. Het systeem geeft een notificatie dat het kostuum is aangepast
<br/>8a. Het systeem toont het kostuum
<br/>
<br/>3b. De medewerker geeft aan het kostuum te willen verwijderen
<br/>4b. Het systeem vraagt om een bevestiging
<br/>5b. De medewerker bevestigt
<br/>6b. Het systeem geeft een notificatie dat het kostuum is verwijderd 
<br/>7b. Het systeem toont een overzicht van kostuums
|-
| Exception Paths
|
6, 6a. Het kostuum bestaat reeds, het systeem geeft een foutmelding
<br/>Terug naar stap 5, 5a
<br/>
<br/>6, 6a. Er ontbreken gegevens, het systeem geeft een foutmelding
<br/>Terug naar stap 5, 5a
|-
| Preconditions 
|
De medewerker is ingelogd in het systeem
|-
| Postconditions 
|
De eventuele wijzigingen in het systeem zijn aangebracht
|-
| Related business rules
|
* BK:01. Identieke kostuums mogen niet bestaan bestaan maar moeten worden vermeld in het aantal
* BK:02. Een kostuum moet minimaal de volgende informatie bevatten: naam, beschrijving, thema en aantal
|}

=====Domain Model=====
[[Image:harmdewit_kostuum_domein_model.jpg| ]]

=====Scenarios=====

{|class="wikitable"
! Use Case: Beheren Kostuums
|-
|
# Ateliermedewerker Diana Buren navigeert naar de kostuumbeheer pagina
# Diana Buren  drukt op de knop nieuw kostuum
# Er wordt een leeg formulier voor het toevoegen van een kostuum getoond
# Diana Buren vult het formulier in met de onderstaande gegevens:
#* Naam: Sirene
#* Beschrijving: Half-vrouw, half-vis op stelten
#* Aantal: 2
#* Maat: M
#* Het systeem toont de volgende mogelijke thema's
#** Malayan
#** Greek Myths
#** Aliens
#** Xo
#* Diana Buren kiest "Greek Myths"
# Diana Buren drukt op opslaan
# Het systeem bevestigt de actie met de melding "Het kostuum is opgeslagen."
# Het systeem toont een nieuwe pagina met de details van het kostuum
|}

{|class="wikitable"
! Use Case: Beheren Kostuums (Alternative path wijzigen kostuum)
|-
|
# Ateliermedewerker Diana Buren Stuum navigeert naar de kostuumbeheerpagina
# Het systeem toont een overzicht van aanwezige kostuums en mogelijke acties
#* White wings
#* Saurus
#* Duivel
#* Rebel
# Diana Buren kiest voor Rebel
# Het systeem toont een overzicht van de kostuumgegevens
#* Naam: Rebel
#* Maat: M
#* Aantal: 1
# Diana Buren wijzigt het aantal in 4
# Diana Buren klikt op opslaan
# Het systeem bevestigt de wijziging van het kostuum
# Het systeem toont de pagina van het kostuum
|}

{| class="wikitable"
|+
! Use Case: Beheren kostuums (Alternative path verwijderen kostuum)
|-
|
# Diana Buren navigeert naar 'kostuumbeheer'
# Het systeem toont een overzicht van aanwezige kostuums en mogelijke acties
#* White wings
#* Saurus
#* Duivel
#* Rebel
# Diana Buren kiest het kostuum dat verwijderd dient te worden
# Het systeem vraagt of het kostuum daadwerkelijk verwijderd dient te worden
# Diana Buren kiest voor 'ja'
# Het systeem bevestigt het verwijderen van het kostuum
|}

====Beheren relaties====

{|class="wikitable"
! Use Case: !! Beheren relaties
|-
| Use case diagram || [[Bestand:Req_Groep3_2012_UC_BR_V2.jpg]]
|-
| Description || Relaties toevoegen, bewerken en verwijderen
|-
| Source || Interview
|-
| Version || 1.0
|-
| Basic course of events 
| 
1. De medewerker opent het relatiebeheer scherm
<br/>2. Het systeem toont een een overzicht van de aanwezige relaties
<br/>3. De medewerker kiest voor het toevoegen van een nieuwe relatie
<br/>4. Het systeem vraagt om de benodigde informatie om een relatie toe te voegen
<br/>5. De medewerker voert de benodigde gegevens in
<br/>6. De medewerker slaat de nieuwe relatie op
<br/>7. Het systeem geeft een notificatie dat de relatie is opgeslagen
<br/>8. Het systeem toont de relatie
|-
| Alternate paths 
|
3a. De medewerker geeft aan een relatie te willen bewerken
<br/>4a. Het systeem toont de gegevens van de relatie
<br/>5a. De medewerker bewerkt de informatie
<br/>6a. De medewerker slaat de gewijzigde relatie op
<br/>7a. Het systeem geeft een notificatie dat de relatie is bewerkt
<br/>8a. Het systeem toont de relatie
<br/>
<br/>3b. De medewerker geeft aan de relatie te willen verwijderen
<br/>4b. Het systeem vraagt om een bevestiging
<br/>5b. De medewerker geeft een bevestiging
<br/>6b. Het systeem geeft een notificatie dat de relatie is verwijderd 
<br/>7b. Het systeem toont een overzicht van relaties
|-
| Exception Paths
|
6, 6a. De relatie bestaat reeds, het systeem geeft een foutmelding
<br/>Terug naar stap 5, 5a
<br/>
<br/>6, 6a. Er ontbreken gegevens, het systeem geeft een foutmelding
<br/>Terug naar stap 5, 5a
|-
| Preconditions 
|
De medewerker is ingelogd in het systeem
|-
| Postconditions 
|
De eventuele wijzigingen in het systeem zijn aangebracht
|-
| Related business rules
|
* BR:01. Identieke relaties mogen niet bestaan
|}

=====Domain Model=====

[[Image:harmdewit_relatie_domein_model.jpg| ]]

=====Scenarios=====
{|class="wikitable"
! Use Case: Beheren Relaties
|-
|
# Een medewerker navigeert naar de relatiebeheer pagina
# De medewerker drukt op de knop nieuwe relatie
# Er wordt een leeg formulier voor een relatie getoond
# De medewerker vult het formulier in met de onderstaande details:
#* Voornaam: Harm 
#* Achternaam: de Wit
#* Bedrijf: City Events B.V.
#* Telefoon nr.: 06 221 43776
#* Email: harmdewit@gmail.com
#* Adres: Pater Tulpstraat 11A Ysselsteyn
#* Postcode: 5813 CD
# De medewerker drukt op opslaan
# Het systeem geeft een bevestiging met de melding "De relatie is opgeslagen"
# Het syteem toont een nieuwe pagina met de bovenstaande details
|}

{|class="wikitable"
! Use Case: Beheren Relaties (Alternative path wijzigen relatie)
|-
|
# Een medewerker navigeert naar de relatiebeheer pagina
# De medewerker drukt op de relatie met de naam "Harm de Wit"
# Het systeem toont de relatie met de onderstaande details:
#* Voornaam: Harm 
#* Achternaam: de Wit
#* Bedrijf: City Events B.V.
#* Telefoon nr.: 06 221 43776
#* Email: harmdewit@gmail.com
#* Adres: Pater Tulpstraat 11A Ysselsteyn
#* Postcode: 5813 CD
# De medewerker drukt op wijzigen
# De medewerker verandert in het formulier de waarde van email adres naar "Veenmos 3 Ysstelsteyn"
# De medewerker drukt op opslaan
# Het systeem geeft een bevestiging met de melding "De relatie is opgeslagen"
# Het syteem toont de relatie met de bovenstaande details
|}

{| class="wikitable"
|+
! Use Case: Beheren relaties (Alternative path verwijderen relatie)
|-
|
# Marja navigeert naar 'relatiebeheer'
# Het systeem toont een overzicht van aanwezige relaties en mogelijke acties
#* City Events
#* Stichting Muziekstad
#* Stichting vrienden van Elst
#* Gemeente Arnhem
# Marja kiest de relatie die verwijderd dient te worden
# Het systeem vraagt of de relatie daadwerkelijk verwijderd dient te worden
# Marja kiest voor 'ja'
# Het systeem bevestigt het verwijderen van de relatie
|}

====Beheren Producties====

{|class="wikitable"
! Use Case: !! Beheren producties
|-
| Use case diagram || [[Bestand:Req_Groep3_2012_UC_BP_V1.jpg]]
|-
| Description || Producties toevoegen, bewerken en verwijderen
|-
| Source || Interview
|-
| Version || 1.0
|-
| Basic course of events 
| 
1. De medewerker opent het productiebeheer scherm
<br/>2. Het systeem toont een overzicht van de producties
<br/>3. De medewerker kiest voor het toevoegen van een nieuwe productie
<br/>4. Het systeem vraagt om de benodigde informatie
<br/>5. De medewerker voert de nieuwe informatie in
<br/>6. De medewerker slaat de nieuwe productie op
<br/>7. Het systeem geeft een notificatie dat de productie is opgeslagen
<br/>8. Het systeem toont een overzicht van de producties
|-
| Alternate paths 
|
3a. De medewerker geeft aan een productie te willen bewerken
<br/>4a. Het systeem toont de gegevens van de productie
<br/>5a. De medewerker bewerkt de gegevens
<br/>6a. De medewerker slaat de gewijzigde productie op
<br/>7a. Het systeem geeft een notificatie dat de productie is aangepast
<br/>8a. Het systeem toont de productie
<br/>
<br/>3b. De medewerker geeft aan een productie te willen verwijderen
<br/>4b. Het systeem vraagt om een bevestiging
<br/>5b. De medewerker geeft een bevestiging
<br/>6b. Het systeem geeft een notificatie dat de productie is verwijderd 
<br/>7b. Het systeem toont een overzicht van de producties
|-
| Exception Paths
|
6, 6a. De kostuum bestaat reeds, het systeem geeft een foutmelding
<br/>Terug naar stap 5, 5a
<br/>
<br/>6, 6a. Er ontbreken gegevens, het systeem geeft een foutmelding
<br/>Terug naar stap 5, 5a
|-
| Preconditions 
|
De medewerker is ingelogd in het systeem
|-
| Postconditions 
|
De eventuele wijzigingen in het systeem zijn aangebracht
|-
| Related business rules
|
* BP:01. Een productie heeft ten minste één rol
|}

=====Domain Model=====
[[Image:req2012_groep3_domeinmodel_producties.jpg| ]]

=====Scenarios=====


{|class="wikitable"
! Use Case: Beheren Producties
|-
|
# Kantoormedewerker Diana Buren navigeert naar de productiebeheer pagina
# Diana Buren drukt op de knop nieuwe productie
# Er wordt een leeg formulier voor het toevoegen van een nieuwe productie getoond
# Diana Buren vult het formulier in met de onderstaande gegevens:
#* Naam: Malayan Aliens
#* Beschrijving: Het nieuwe spektakel van close-act Malayan Aliens
#* Spelerslijst: -
#* Materiaallijst: Ufo
# Diana Buren drukt op opslaan
# Het systeem bevestigt de actie met de melding "De productie is opgeslagen."
# Het systeem toont een nieuwe pagina met de details de productie
|}

{| class="wikitable"
|+
! Use Case:  Beheren producties (Alternative path 1)
|-
|
# Kantoormedewerker Diana Buren navigeert naar 'productiebeheer'
# Het systeem toont een overzicht van aanwezige producties en mogelijke acties
#* Malaya
#* XO
#* Greek Myths
#* Aliens
# Diana Buren kiest de productie die aangepast dient te worden
# Het systeem toont de gegevens van de betreffende productie
#* Naam : Malaya
#* Omschrijving : Bakker
#* Spelerslijst : Niels Braakensiek, x, y
#* Materiaallijst : 
# Diana Buren wijzigt de spelerslijst in Niels Braakensiek, Jeroen Bakker, Sjoerd van Oostenbrugge en bevestigt de nieuwe gegevens
# Het systeem bevestigt de wijziging van de gegevens
|}

{| class="wikitable"
|+
! Use Case:  01 Beheren producties (Alternative path 2)
|-
|
# Kantoormedewerker Diana Buren navigeert naar 'Productiebeheer'
# Het systeem toont een overzicht van aanwezige producties en mogelijke acties
#* Malaya
#* XO
#* Greek Myths
#* Aliens
# Diana Buren kiest de productie die verwijderd dient te worden
# Het systeem vraagt of de productie daadwerkelijk verwijderd dient te worden
# Diana Buren kiest voor 'ja'
# Het systeem bevestigt het verwijderen van de productie
|}

== Non-functional Requirements ==

'''Availlability'''

Het belangrijkste is dat het systeem tijdens de kantooruren beschikbaar is. Close-Act hecht niet zozeer waarde aan een 99% uptime garantie als hier veel hogere kosten tegenover staan. Onderhoud en updates zullen dus wel zoveel mogelijk buiten reguliere kantooruren moeten plaatsvinden.

'''Integrity'''

Omdat er persoonsgegevens van medewerkers in het systeem worden opgeslagen moet hier zorgvuldig mee om worden gegaan. Voor de opslag van persoonsgegevens van de medewerkers zijn verschillende wetten van belang waaraan het systeem moet voldoen. Het gaat hier met name om de wet bescherming persoonsgegevens/telecommunicatiewet.

'''Security / Accessibility'''

Omdat het voor spelers mogelijk is het systeem van buitenaf te benaderen is het van belang dat er verschillende 'lagen' in het systeem zitten. Het moet niet mogelijk zijn om bijvoorbeeld NAW-gegevens van medewerkers van buitenaf te benaderen. Dit kan leiden tot verlies, diefstal of manipulatie van de data.

= Addendum =
== Integrated Domainmodel ==

[[Image:req2012_groep3_integrated_domainmodel_v1.jpg| ]]

== Business Rules Catalogue ==

'''Beheren Medewerkers'''
*BM:01. Van een medewerker moet minimaal de voornaam, achternaam en geboortedatum bekend zijn.

'''Beheren opties'''
*BO:01. Aan een optie kan te allen tijden informatie worden toegevoegd. 

'''Beheren Agenda''' 
*BA:01. Alleen kantoormedewerkers mogen opdrachtgegevens aanpassen.

'''Beheren Beschikbaarheid'''
*BBS:01. Spelers mogen zich altijd 'automatisch' (1 week voor de speeldatum) aanmelden voor een act.
*BBS:02. Spelers mogen hun beschikbaarheid binnen een termijn van 3 weken voor het optreden, niet meer 'automatisch' wijzigen. Het wijzigen binnen dit termijn kan alleen gedaan worden door * kantoormedewerkers van Close-Act.
*BBS:03 .Spelers mogen hun beschikbaarheid in het verleden niet wijzigen. 

'''Beheren Kostuums''' 
* BK:01. Identieke kostuums mogen niet bestaan bestaan maar moeten worden vermeld in het aantal.
* BK:02. Een kostuum moet minimaal de volgende informatie bevatten: naam, beschrijving, thema en aantal.

'''Beheren relaties'''
* BR:01. Identieke relaties mogen niet bestaan.

'''Beheren producties'''
* BP:01. Een productie heeft ten minste één rol.

== Terminological Definitions ==
* Productie: Een themavoorstelling van Close Act zoals bijvoorbeeld Malaya.
* Opdracht: Een opdracht is een ingeplande productie in de agenda, een opdracht kan definitief zijn of niet.
* Opdrachtgever: Een bedrijf dat de opdracht geeft voor een voorstelling.
* Kostuum: Kledingset die toebehoort aan een rol.
* Medewerker: Een persoon die werkzaam is bij Close-Act.
* Ateliermedewerker: Een persoon die kostuums en rekwisieten beheert.
* Speler: Een acteur die één of meerdere rollen speelt.
* Kantoormedewerker: Een medewerker die werkzaam is op het kantoor van Close-Act.
* Rekwisieten: Onderdelen van een act welke niet onder het kostuum vallen.

====Bronnen====
<references/>