Requirements Engineering/het werk/werkstuk/2011-12/Groep 02
'
Werkstuk Requirements Engineering
Mirjam de Haas, Pien Walraven, Daniël van Loon, Lotus ter Haar, Merel Tombrock
Onderwijsinstituut voor Informatica en Informatiekunde
Radboud Universiteit Nijmegen
version 18 februari 2022
De inhoud is opgebouwd als volgt.
Introduction
Close-Act Theatre is een professioneel gezelschap dat bekend staat om zijn interactieve straattheater. Het gezelschap bestaat onder andere uit steltlopers, dansers, muzikanten, vuurspelers en acrobaten, die allen regelmatig samen trainen en repeteren. Het gezelschap van Close-Act reist over de hele wereld en speelt vaak op theaterfestivals en grootschalige evenementen, hierdoor is dus een goede organisatie wat betreft logistiek en planning van essentieel belang. Het kantoor regelt dit alles.
Close-Act gebruikt voor de organisatie van de acts meerdere informatiesystemen die bestaan uit een algemene (Outlook)agenda, een spelersplanner en een kostuumplanner. Helaas gebeurt het nog vaak dat er dingen misgaan bij het huidige systeem.
Het doel van dit document is om de requirements op te stellen voor één geïntegreerd systeem dat de problemen van het huidige informatiesysteem moet oplossen en een verbeterde spelersplanning moet realiseren.
Dit doen wij door middel van de volgende onderdelen:
In de ‘Case analysis’ sectie worden de betrokken stakeholders beschreven. Ook is hier wordt hier een beschrijving te vinden van wat het project moet doen, wat het eindproduct zal zijn en welke principes het project leiden.
Het belangrijkste gedeelte van ons document is de ‘Requirements’ sectie.
In deze sectie wordt een overzicht wordt gegeven van alle use cases in de documentatie.
'Indivual Use Cases’ zullen de interactie tussen het informatiesysteem van Close-Act en de actoren weergeven. Deze use cases worden hierna stuk voor stuk getest door middel van Scenario’s.
Eveneens de requirements die niets bijdragen aan de functionaliteit van het informatiesysteem van Close-Act komen aan bod in ons document in de sectie ‘Non Functionals’.
De laatste sectie van ons document is het ‘Addendum’ waarin een overzicht is te vinden van de belangrijkste termen en concepten die in dit document zijn gebruikt. Hierbij is ook een catalogus toegevoegd met alle Business Rules die van toepassing zijn op de organisatie van Close-Act.
Problem statement
Het systeem waar Close-Act nu mee werkt is inefficiënt. De planningen voor kostuums, spelers en optredens zijn onvoldoende met elkaar geintegreerd. Hierdoor is het werken met het systeem erg tijdrovend en maakt het de kans op fouten groot. Ook is de communicatie naar de spelers toe onvoldoende als er optredens afgezegd worden en kunnen de spelers niet goed zien wanneer zij ingepland zijn. Dit is gebruiksonvriendelijk tegenover de spelers.
Het nieuwe systeem zal het volgende gaan verbeteren:
- Planningen voor kostuums, spelers en optredens meer integreren
- De kans op fouten kleiner maken
- Gebruiksvriendelijker voor spelers
Case analysis
Stakeholder analysis
| Stakeholder | rol | omschrijving |
|---|---|---|
| Kantoor | Dit zijn de meest actieve gebruikers van het systeem, in de zin dat zij de meeste wijzigingen kunnen aanbrengen in het systeem (zowel in het spelersbeheer als in het kostuumbeheer) | |
| Niels | Spelers | Spelers zijn zowel actief (inschrijven voor opties) als passief (raadplegen van agenda) gebruiker |
| Atelier | Nog te vragen in een volgend interview | |
| Opslag | Nog te vragen in een volgend interview | |
| Technici | Nog te vragen in een volgend interview | |
| Niels | Close-Act | Close-Act heeft de opdracht gegeven om requirements voor een nieuw systeem te ontwikkelen, en zal tevens dit systeem financieren |
Mission and vision statement
*Mission— What the project will do (close to WHY)
Mission: Er gaan veranderingen plaatsvinden wat betreft de spelersplanning, wat moet zorgen voor verbeteringen voor zowel de mensen op kantoor als de spelers zelf. Voor de mensen op kantoor moet het duidelijker zijn welke spelers welke dag beschikbaar zijn, zodat ze makkelijker spelers kunnen inplannen en niet lang op een bevestiging van de spelers hoeven te wachten. De spelers moeten eerder meer informatie over de optredens krijgen, ze moeten een automatisch bericht krijgen als een opdracht gecanceld of bevestigd is.
*Vision— What the end product will be (close to WHAT)
Vision: Er wordt een systeem opgeleverd dat ervoor zorgt dat de spelersplanning deels wordt geautomatiseerd en in staat is de in de requirements gestelde doelen te realiseren. Het systeem moet eenvoudig in gebruik zijn zowel voor de mensen op kantoor als voor de spelers. Verder blijft de agenda een centraal punt waar alle andere planningen gekoppeld worden.
Statement of work
| Deliverable | DeliverbleType | Façade | Filled | Focused | Comment |
|---|---|---|---|---|---|
| Introduction | Contextual | Preliminary version | Preliminary version | Complete | Keep it short at first, only a sketch; nice, clear and complete at the end. |
| Status: | 100% | 100% | 100% | - | |
| Problem statement | Key deliverable | As good as possible | As good as possible | Complete | |
| Status: | 100% | 100% | 100% | - | |
| Stakeholder list/analysis | Contextual | As good as possible | As good as possible | Complete | |
| Status: | 100% | 100% | 100% | - | |
| Mission-Vision-(Values) | Contextual | Complete | Complete | Complete | |
| Status: | 100% | 100% | 100% | - | |
| Statement of Work | Contextual | Complete, and up-to-date | Complete, and up-to-date | Complete, and up-to-date | |
| Status: | 100% | 100% | 100% | - | |
| Risk Analysis | Contextual | Complete, and up-to-date | Complete, and up-to-date | Complete, and up-to-date | |
| Status: | 100% | 100% | 100% | - | |
| Use Case Survey | Key deliverable | As good as possible | Nearly complete | Complete | |
| Status: | 100% | 100% | 100% | - | |
| Integrated UC Diagram | Key deliverable | Complete (though preliminary) | Complete | Complete | One for whole project |
| Status: | 100% | 100% | 100% | - | |
| Use Cases | Key deliverable | Not yet! | "Filled" level | Complete | |
| Status: | 70% | 100% | - | ||
| Scenarios | Key deliverable | Not yet! | Several for each UC | Complete ("focused" level) | |
| Status: | 100% | 100% | - | ||
| Domain Models | Key deliverable | Not yet! | Partially complete | Complete | One for each UC |
| Status: | 100% | 100% | - | ||
| Business rules per UC | Key Deliverable | Not yet! | Partially complete | Complete | |
| Status: | 100% | 100% | - | ||
| Integrated Domain Model | Key deliverable | Not yet! | First draft | Complete | One for whole project |
| Status: | 100% | 100% | - | ||
| Busines Rules Catalogue | Key deliverable | Not yet! | Partially complete | Complete | |
| Status: | 90% | 100% | - | ||
| Non-functional Requirements | Key deliverable | Notes | Partially complete | Complete | |
| Status: | 100% | 100% | 100% | - | |
| Terminological Definitions | Key deliverable | Notes | Partially complete | Complete | |
| Status: | 100% | 100% | 100% | - | |
| Executive sponsor viewpoint | Implicit deliverable | Complete(Nederlands) | Complete | Complete | Integrated in M-V-(V)! |
| Status: | 100% | 0% | 0% | - | |
| Use case tests | Implicit deliverable | Notes | As good as possible | Complete | Integrated in scenarios; to be done, but not written down explicitly as a separate item |
| Status: | 0% | 0% | 0% | - | |
| Busienss process definitions | Optional appendix | If available / relevant | If relevant | If relevant | Use existing definitions/models or make them yourself: optional! |
| Status: | nvt | nvt | nvt | - | |
| GUI metaphors / storyboards | Optional appendix | If relevant | If relevant | If relevant | |
| Status: | nvt | nvt | nvt | - |
Risk analysis
| # | Category | Risk | Solution needed by | Status | Days lost | Expectancy factor | Risk factor |
|---|---|---|---|---|---|---|---|
| 01 | Planning | Ziekte van een groepslid | Meteen | Closed | 4 | 30 | 7 |
| 02 | Planning | Ophouden van een groepslid | Meteen | Closed | 7 | 75 | 7 |
| 03 | Planning | Inefficiënte verdeling van taken | Meteen | Closed | 3 | 30 | 5 |
| 04 | Planning | Stakeholder niet beschikbaar | Zo snel mogelijk als hij weer beschikbaar is | Closed | 8 | 25 | 8 |
| 05 | Communicatie | Misverstand tussen groep en stakeholder | Meteen | Closed | 5 | 40 | 8 |
| 06 | Communicatie | Misverstand tussen groepsleden | Meteen | Closed | 2 | 60 | 3 |
| 07 | Data | Data verlies | Zo snel mogelijk als het gebeurt | Closed | 4 | 30 | 8 |
Requirements
Use cases
Use case survey
| # | Name | Description | Initiating actor |
|---|---|---|---|
| 01 | Speler beheer | Een speler wordt toegevoegd aan of verwijderd uit de agenda en zijn spelersinfo wordt opgeslagen of veranderd. | Kantoor |
| 02 | Kostuum beheer | Het kantoor beheert hier de gegevens over het kostuumbeheer. Een attribuut kan worden toegevoegd en kan worden verwijderd uit de agenda als deze kapot of kwijt is. | Kantoor |
| 03 | Optie plaatsen | Kantoor voegt een optie toe aan de agenda, waardoor deze in de toekomst zichtbaar is voor zowel kantoor als spelers. | Kantoor |
| 04 | Optie wijzigen | Een optie gaat niet door en wordt verwijderd of is geupdate of een speler moet door omstandigheden worden uitgeschreven en wordt gewijzigd. | Kantoor |
| 05 | Contract beheer | Het kantoor kan een offerte of contract opstellen. | Kantoor |
| 06 | Optie info bekijken | Een speler of het kantoor wil de meest up-to-date gegevens van een bepaalde optie of evenement inzien. | Speler/Kantoor |
| 07 | Beschikbaarheid opgeven | Een speler kan hier zijn beschikbaarheid opgeven. | Speler |
| 08 | Inschrijven op Optie | Speler kan zich inschrijven op een optie | Speler |
Integrated use case diagram
Individual use cases
| Use Case: | Name |
|---|---|
| Name | Spelersbeheer |
| Number | 01 |
| Description | Speler wordt toegevoegd aan of verwijderd uit de agenda en zijn spelersinformatie wordt opgeslagen of veranderd. |
| Actor | Kantoor |
| Version | 7.3 |
| Triggers |
• Er moet een nieuwe speler worden toegevoegd. |
| Basic course of events | Er is een nieuwe speler. 1. Het kantoor geeft aan een speler willen te willen toevoegen |
| Alternative paths | Er moet een speler gedeactiveerd worden 1. Het kantoor geeft aan een speler te willen deactiveren |
| Exceptions | BCoE 4. Als de verplichte gegevens niet compleet ingevuld zijn geeft het systeem een waarschuwing |
| Preconditions | Geen |
| Postconditions | Het kantoor heeft een wijziging aangebracht in het spelersbeheer |
| Postconditions Alternative path | De login functie van de gedeactiveerde speler is gedeactiveerd |
| Related business rules | 03,04,08 |
| Use Case: | Name |
|---|---|
| Name | Kostuumbeheer |
| Number | 02 |
| Description | Het kantoor beheert in de kostuumbeheer de gegevens over het kostuumbeheer. Een attribuut kan worden toegevoegd en kan worden verwijderd uit de agenda als deze kapot of kwijt is. |
| Actor | Kantoor |
| Version | 4.4 |
| Triggers | • Er komt een nieuw attribuut binnen • Er is een attribuut beschadigd |
| Basic course of events | Er komt een nieuw attribuut binnen 1. Het systeem laat een overzicht van kostuumbeheer |
| Alternative paths |
Als bij stap 6 het attribuut een kostuum is Er is een attribuut beschadigd of verloren geraakt Een attribuut verwijderen Een attribuut wijzigen |
| Exceptions | Alternative Paths 2. Als de ingevoerde attribuutnaam niet te vinden is, dan geeft het systeem een waarschuwing |
| Preconditions | Geen |
| Postconditions | De medewerker heeft aanpassing aangebracht in het systeem van de kostuumplanner |
| Related business rules | 01, 05 |
| Use Case: | Name |
|---|---|
| Name | Optie plaatsen |
| Number | 03 |
| Description | Kantoor voegt een optie toe aan de agenda, waarna deze zichtbaar is voor zowel kantoor als spelers. |
| Actor | Kantoor |
| Version | 5.3 |
| Triggers | Close-Act en een betalende partij zijn in onderhandeling gegaan over een Evenement en er is een voorlopige datum of er zijn voorlopige data besproken. |
| Basic course of events | Het kantoor geeft aan een optie te willen plaatsen 1. Het systeem vraagt om optieinformatie |
| Alternative paths | Het kantoor heeft aangegeven over meer informatie te beschikken 1. Het systeem vraagt reisinformatie |
| Exceptions | Geen |
| Preconditions | Kantoor heeft voldoende voorlopige informatie om een optie aan te maken |
| Postconditions | Optie staat in de Agenda |
| Related business rules | 01,07 |
| Use Case: | Name |
|---|---|
| Name | Optie wijzigen |
| Number | 04 |
| Description | Een optie gaat niet door en wordt verwijderd of is geüpdate of een speler moet door omstandigheden worden uitgeschreven. De optie wordt dan gewijzigd. |
| Actor | Kantoor |
| Version | 4.6 |
| Triggers |
• Optie wordt geannuleerd |
| Basic course of events | Kantoor geeft aan een optie te willen wijzigen 1. Het systeem laat de optieinformatie zien en vraagt welk deel gewijzigd moet worden |
| Alternative paths | Het kantoor geeft aan dat er een optie verwijderd moet worden 1. Het systeem vraagt welke optie definitief verwijderd moet worden Het kantoor geeft aan dat er een speler verwijderd moet worden Het kantoor geeft aan dat een optie definitief is |
| Exceptions | Geen |
| Preconditions | De te wijzigen optie staat in de agenda |
| Postconditions | Optie is gewijzigd of verwijderd |
| Related business rules | 01,05,07 |
| Use Case: | Name |
|---|---|
| Name | Contractbeheer |
| Number | 05 |
| Description | Het kantoor stelt een contract of offerte op of wil een bestaande offerte of contract wijzigen |
| Actor | Kantoor |
| Version | 2.0 |
| Triggers |
• Het kantoor wil een contract maken |
| Basic course of events | Het kantoor geeft aan een contract te willen maken 1. Het systeem vraagt om contractinformatie 2. Het kantoor geeft contractinformatie |
| Alternative paths | Het kantoor geeft aan dat een contract gewijzigd moet worden 1. Het systeem vraagt welk contract gewijzigd moet worden Het kantoor geeft aan een contract te willen printen Het kantoor geeft aan dat een contract moet worden verwijderen |
| Exceptions | Als er geen contract is voor de opgegeven optie, dan vraagt het systeem of het kantoor een nieuw contract wil aanmaken of nogmaals een naam van een optie wil geven |
| Preconditions | |
| Postconditions | Een contract is aangemaakt, gewijzigd, uitgeprint of verwijderd |
| Related business rules | 02 |
| Use Case: | Name |
|---|---|
| Name | Optie/Evenement info bekijken |
| Number | 06 |
| Description | Een speler of het kantoor wil de meest up-to-date gegevens van een bepaalde optie of evenement inzien. |
| Actor | Kantoor
Speler |
| Version | 6.1 |
| Triggers | •De speler wil de gegevens van het evenement of de optie zien
•Het kantoor wil de gegevens van het evenement of de optie zien |
| Basic course of events | De speler of het kantoor wil evenement/optieinformatie bekijken 1. Het systeem laat alle geplande opties en evenementen zien |
| Alternative paths | De speler of het kantoor wil evenement/optieinformatie bekijken van een bepaalde datum
1. De speler of het kantoor kiest een datum |
| Exceptions | Geen |
| Preconditions | De speler is ingelogd |
| Postconditions | De speler of het kantoor heeft de benodigde informatie gevonden |
| Related business rules | 05,03 |
| Use Case: | Name |
|---|---|
| Name | Beschikbaarheid opgeven |
| Number | 07 |
| Description | Een speler kan hier zijn beschikbaarheid opgeven. |
| Actor | Speler |
| Version | 2.0 |
| Triggers |
• Speler wil zijn beschikbaarheid voor een aankomende periode aangeven • Speler wil zijn beschikbaarheid wijzigen |
| Basic course of events | Speler geeft aan dat hij zijn beschikbaarheid wil wijzigen 1. Het systeem laat de spelerskalender zien |
| Alternative paths | Geen |
| Exception paths | Geen |
| Preconditions | De speler is ingelogd |
| Postconditions | De beschikbaarheid van de speler is gewijzigd |
| Related business rules | 09,10,11 |
| Use Case: | Name |
|---|---|
| Name | Inschrijven optie |
| Number | 08 |
| Description | Het inschrijven voor een optie en daardoor bekend maken van interesse aan kantoor. |
| Actor | Speler |
| Version | 4.0 |
| Triggers | Speler wilt zich inschrijven |
| Basic course of events | 1. Het systeem geeft een lijst van opties 2. De speler kiest een optie |
| Alternative paths | Geen |
| Exceptions | Speler is al ingeschreven op dezelfde tijd voor een andere optie/evenement |
| Preconditions | • De optie is geen evenement
• De speler is ingelogd |
| Postconditions | Speler heeft zich ingeschreven voor een optie. |
| Related business rules | 03,05,06,07 |
Domain Model per Use Case
Spelersbeheer:
Kostuumbeheer:
Optie plaatsen:
Optie wijzigen:
Optie definitief maken (alternative path van Optie wijzigen)
Contractbeheer:
Optieinfo bekijken:
Beschikbaarheid opgeven:
Inschrijven Optie:
Scenarios
| Scenario: | Name |
|---|---|
| Name | Spelersbeheer |
| Number | 01 |
| Basic course of events | Kantoormedewerker Truus opent de agenda. 1. Truus geeft aan dat ze een speler toe wilt voegen.
4. Het systeem laat een bevestiging zien en toont een overzicht van de ingevulde spelersinfo van Piet de Groot
Adres:
Telefoonnummer:
Overige informatie:
|
| Alternative paths | Er moet een speler gedeactiveerd worden Kantoormedewerker Truus opent de agenda
4. Het systeem vraagt om het telefoonnummer van speler Koen
7. Het systeem toont een bevestiging van de deactivering
|
| Scenario: | Name |
|---|---|
| Name | Kostuumbeheer |
| Number | 02 |
| Basic course of events | Er komt een nieuw attribuut I-puppet eyes binnen Kantoormedewerker Truus opent de kostuumplanner
2. Truus voegt een attribuut i-Puppet Eyes toe
5. Het systeem vraagt of het attribuut een kostuum is
7. Het systeem laat een overzicht van de kostuuminformatie zien
|
| Alternative paths | Als bij stap 6 het attribuut een kostuum is 7. Het systeem vraagt om de maat van het kostuum i-Puppets 1
9. Het systeem laat een overzicht van de kostuuminformatie zien
Er is een attribuut beschadigd of verloren geraakt
3. Het systeem laat de beschikbare attributen die het meest overeenkomen met de gegeven naam ‘Rebels’ zien:
4. Godelieve bevestigt het juiste attribuut ‘Rebels Engine 2’
5. Het systeem laat een overzicht van de kostuuminformatie zien voor attribuut Rebels Engine 2
7. Het systeem toont een bevestiging van de wijziging aan de kostuuminformatie:
Een attribuut verwijderen
2. Hendrik geeft de naam van het attribuut:
3. Het systeem laat de beschikbare attribuutnamen die het meest overeenkomen met ‘Duivel’ op het scherm zien:
4. Hendrik bevestigt het juiste attribuut ‘Duivel drietand 1’
5. Het systeem laat een overzicht van de kostuuminformatie zien voor attribuut Duivel drietand 1:
6. Hendrik geeft aan dat het attribuut Duivel drietand 1 verwijderd moet worden.
7. Het systeem toont een bevestiging van de verwijdering van het attribuut‘Duivel drietand 1’
Een attribuut wijzigen
2. Johanna geeft de naam van het attribuut Invasion
3. Het systeem laat de beschikbare attributen die het meest overeenkomen met ‘Invasion’ op het scherm zien
4. Johanna bevestigt het juiste attribuut ‘Invasion 3’
5. Het systeem laat een overzicht van de kostuuminformatie zien van het Invasion 3:
6. Hendrik geeft aan dat het attribuut gewijzigd moet worden en past de gegevens aan.:
7. Het systeem toont een bevestiging van de gewijzigde gegevens
|
| Scenario: | Name |
|---|---|
| Name | Optie plaatsen |
| Number | 03 |
| Basic course of events | Kantoormedewerker Truus geeft aan een optie te willen plaatsen 1. Het systeem vraagt om optieinformatie
3. Het systeem laat een overzicht zien van de ingevulde informatie:
|
| Alternative paths | Kantoormedewerker Truus heeft aangegeven te beschikken over meer optieinfomatie 1. Het systeem vraagt om de optieinformatie
3. Het systeem laat een overzicht zien van de ingevulde informatie:
Kantoormederwerker Truus heeft aangegeven te beschikken over meer optieinformatie
3. Het systeem laat een overzicht zien van de ingevulde informatie:
|
| Scenario: | Name |
|---|---|
| Name | Optie wijzigen |
| Number | 04 |
| Basic course of events | Kantoormedewerker Truus geeft aan een optie ‘Tokyo Festival – Tokyo’ te willen wijzigen 1. Het systeem laat de optieinformatie van ‘Tokyo Festival – Tokyo’ zien:
2. Truus geeft aan welke deel van de optieinformatie gewijzigd moet worden:
3 Het systeem vraagt wat de nieuwe gegevens zijn
5. Het systeem toont een bevestiging van de gewijzigde gegevens
|
| Alternative paths | Kantoormedewerker Truus geeft aan dat optie ‘Tokyo Festival – Tokyo’ verwijderd moet worden 1. Het systeem vraagt welke optie definitief verwijderd moet worden
3. Het systeem toont een bevestiging van de verwijdering van de optie
3. Het systeem vraagt om het telefoonnummer van de speler
5. Het systeem laat de spelersinformatie zien.
6. Truus bevestigt het verwijderen Piet
Kantoormedewerker Truus geeft aan dat optie ‘Tokyo Festival – Tokyo’ definitief is
3. Het systeem toont een bevestiging van het definitief maken van ‘Tokyo Festival – Tokyo’ en van het versturen van de speelinformatie naar de spelers:
|
| Scenario: | Name |
|---|---|
| Name | Contractbeheer |
| Number | 05 |
| Basic course of events | Kantoormedewerker Truus geeft aan een contract te willen maken 1. Het systeem vraagt om contractinformatie
3. Het systeem laat een overzicht zien van de ingevulde informatie:
|
| Alternative paths | Kantoormedewerker Truus heeft aangegeven het contract te willen wijzigen 1. Het systeem vraagt om de contractinformatie
3. Het systeem laat een overzicht zien van de ingevulde informatie:
Kantoormederwerker Truus heeft aangegeven het contract te willen printen
3. Het systeem laat de contractinformatie zien:
3. Het systeem laat een overzicht zien van de ingevulde informatie:
Welk deel moet worden uitgeprint?: Kantoormederwerker Truus heeft aangegeven het contract te willen verwijderen
Wilt u het zeker weten verwijderen?
|
| Scenario: | Name |
|---|---|
| Name | Optie/Evenement info bekijken |
| Number | 06 |
| Basic course of events | Kantoormedewerker Hendrik wil evenement/optie-informatie bekijken 1. Het systeem laat alle geplande opties en evenementen zien:
2. Hendrik kiest de optie ‘Tokyo Festival – Tokyo’
|
| Alternative paths | Kantoormedewerker Hendrik wil evenement/optie-informatie bekijken van de datum 17-08-2012 1. Hendrik kiest de datum 17-08-2012.
|
| Scenario: | Name |
|---|---|
| Name | Beschikbaarheid opgeven |
| Number | 07 |
| Basic course of events |
Speler Jan geeft aan dat hij zijn beschikbaarheid wil wijzigen
2. Jan wijzigt zijn beschikbaarheid:
3. Het systeem vraagt om bevestiging
|
| Scenario: | Name |
|---|---|
| Name | Inschrijven optie |
| Number | 08 |
| Basic course of events |
Speler Jan wilt zich inschrijven
2. Jan kiest de optie met naam ‘Invasion – Parijs’
4. Jan bevestigt zijn inschrijving voor de optie ‘Invasion - Parijs’.
|
Non-functional Requirements
Verificatie (Authentication) (Alle UC waar spelers inkunnen) - Om het inloggen te beschermen
Autorisatie (Authorization) (Alle UC) – Niet iedereen moet de bevoegdheid hebben om dingen in de agenda te kunnen aanpassen
Bruikbaarheid/Uitvoerbaarheid (Usability /Achievebility) (Alle UC) - Het systeem moet makkelijk in gebruik zijn, zonder lange training of uitleg
Beschikbaarheid (Availability) (Alle UC) - Het systeem moet zo veel mogelijk beschikbaar zijn
Addendum
Integrated Domainmodel
Business Rules Catalogue
01. Attributen en spelers kunnen niet op hetzelfde tijdstip en datum op verschillende evenementen zijn.
02. Een contract moet één of meer contactpersonen hebben.
03. Technici mogen alleen de agenda bekijken.
04. Een speler kan alleen inloggen als zijn account is aangemaakt en geactiveerd.
05. Een optie kan 0 of meer ingeschreven spelers hebben.
06. Als een optie definitief is kunnen spelers zich niet meer inschrijven.
07. Tussen twee evenementen waarbij dezelfde speler of hetzelfde attribuut wordt gebruikt moet minimaal de reistijd tussen de twee evenementen zitten.
08. Een speler mag niet overeenkomen met een andere speler.
09. Een speler kan tot 2 jaar in het voren zijn beschikbaarheid aanpassen.
10. Een speler kan alleen zijn eigen beschikbaarheid aanpassen.
11. Een speler is standaard altijd beschikbaar.
Terminological Definitions
Adresgegevens - Bestaat uit straatnaam, nummer, postcode, plaatsnaam.
Agenda – De digitale plek waar Kantoor Opties plaatst waar Kostuums en Spelers aan gelinkt zijn.
Atelier – Afdeling van Close-Act waar Kostuums ontworpen, gemaakt en gerepareerd worden.
Attribuut - Een Kostuum of decorstuk of andere benodigdheden dat wordt of die worden gebruikt tijdens een Evenement.
Beschikbaarheid - Een Speler heeft een beschikbaarheid bestaande uit een datum en een tijdstip dat hij beschikbaar is om te spelen.
Beschikbaarheidskalender - Overzicht van de Beschikbaarheid op bepaalde data.
Betalende partij- Afdeling van een optie of evenement die de rekening vereffend.
Contactgegevens- Bestaat uit een emailadres en een Telefoonnummer.
Contract - Een schriftelijke overeenkomst tussen Close-Act en de Betalende Partij, waarin de kosten en overige afspraken staan vermeld. De contracten zijn onderling van elkaar te onderscheiden door middel van de naam van de Optie.
Contractinformatie - Informatie die opgeslagen is over een Contract of Offerte, bestaande uit naam van de Optie, plaatsgegevens, de betalende partij en data van de Optie, kosten, Betalende Partij en Overige Afspraken.
Evenement – Optie die definitief is door middel van een contract tussen Close-Act en de betalende partij.
Kantoor – Personen die werken op het kantoor van Close-Act.
Kostuum – Kledingstuk/kledingset dat wordt gebruikt tijdens een Evenement.
Kostuumbeheer - Onder kostuumbeheer verstaan wij alle attributen die worden beheerd.
Kostuuminformatie - Informatie die is opgeslagen over een Attribuut, bestaande uit de naam van het Attribuut, de rol waarbij het Attribuut behoort, vermelding of Attribuut een kostuum is, als het Attribuut een Kostuum is de maat, en eventueel de staat van het Attribuut: verloren of beschadigd.
Offerte – Een Contract dat nog niet de informatie heeft over het uiteindelijke evenement.
Opslag – Afdeling van Close-Act waar Kostuums opgeslagen liggen.
Optie – Optreden dat nog gewijzigd of gecanceld kan worden, maar wel al gereserveerd is door het Kantoor.
Optieinformatie - Informatie die opgeslagen is over een Optie, bestaande uit evenementnaam, locatienaam, het hotel waar overnacht wordt, benodigheden, honorarium, Tijden, Vervoer, Betalende partij, Speler, Attribuut.
Persoonsgegevens - Bestaat uit voornaam, voorletters, tussenvoegsels, achternaam, geslacht en geboortedatum.
Speelinformatie – Informatie die aan de Spelers wordt verstrekt als een Optie overgegaan is naar een Evenement en die dient als een soort contract tussen Speler en Close-Act voor dat specifieke Evenement.
Speler – Persoon die optreedt.
Spelersinformatie – Informatie die opgeslagen is over een bepaalde Speler, namelijk de Persoonsgegevens, Adresgegevens, bankrekening, rol, dieet, maat, Contactgegevens.
Technici - Personen vanuit een extern bedrijf die de techniek voor een evenement verzorgen.
Telefoonnummer - Dit bestaat uit een gsm-nummer en/of thuisnummer.
Tijden - Bestaat uit een begintijn, een tijdstip voor pauze te houden, een eindtijd en op bepaalde data.
Vervoer- Bestaat uit de vertrektijden van de heenreis en de vertrektijden van de terugreis en een naam van vervoersmiddel, als het een vliegtuig is staat ook het vliegveld erin.
