Requirements Engineering/het werk/werkstuk/2011-12/Groep 01
Close-Act | Requirements Engineering
Werkstuk Requirements Engineering
Sjors Clabbers, Chris Kleine Staarman, Dré Hendrinks, Mats Ouborg, Simon Brugman
Onderwijsinstituut voor Informatica en Informatiekunde
Radboud Universiteit Nijmegen
version 18 februari 2022
Inhoud
- 1 Introduction
- 2 Case analysis
- 3 Requirements
- 3.1 Use cases
- 3.2 Scenarios
- 3.3 Non-functional Requirements
- 4 Addendum
Introduction
Close-Act is een professionele theatergroep die spectaculaire optredens verzorgt over de hele wereld. De optredens kunnen bestaan uit dans, muziek, acrobatiek en stunts. Hierbij wordt gebruik gemaakt van speciaal ontworpen kostuums en (groot) materieel. Het gezelschap bestaat uit 42 personen die binnen de organisatie verschillende functies en rollen bekleden.
Het op een adequaat plannen van organisatorische en logistieke aspecten van een optreden is erg belangrijk. De planning van spelers, kostuums en vervoer wordt op dit moment in Excel bijgehouden en de voor de agenda wordt Outlook gebruikt. Deze werkwijze wordt door de gebruikers als niet prettig ervaren en maakt het mogelijk dat er geregeld fouten kunnen worden gemaakt.
Het doel van de opdracht is het ontwikkelen van een geïntegreerd informatiesysteem waarmee het bijhouden van deze administratie beter doorlopen kan worden. De scope van deze case beperkt zich tot het uitwerken van de requirements voor het informatiesysteem. Daadwerkelijke implementatie en ontwerp vallen hierbuiten.
Dit document beschrijft de requirements van een te ontwikkelen informatiesysteem voor Close-Act Street Theater V.O.F. De opbouw van het document is als volgt:
Er wordt gestart met een analyse van de case. Hierin worden de huidige knelpunten en problemen beschreven en alle belanghebbenden binnen de case gedefinieerd. Vervolgens worden missie en visie van de opdrachtgever met betrekking tot het informatiesysteem beschreven.
De opdracht is in projectvorm uitgevoerd waarbij drie iteraties zijn doorlopen om de systeemrequirements te ontwikkelen. De iteraties worden aangeduid met: ‘facade’, ‘filled’ en ‘focussed’, welke incrementeel een bijdrage leveren aan de volwassenheid van de requirements en de projectmatige aanpak structureren. De projectmijlpalen en activiteiten met bijbehorende status binnen de verschillende iteraties, zijn gedurende het project vastgelegd en bijgehouden in de ‘statement of work’. Tevens is een project risicoanalyse opgesteld om eventuele risico’s in kaart te brengen.
Voor het definiëren van de systeemrequirements is gebruik gemaakt van Use Cases, welke ieder zijn aangevuld met een bijbehorend domeinmodel. Alle uitgewerkte Use Cases en domeinmodellen staan beschreven in de sectie ‘requirements’. Binnen deze sectie wordt gestart met een overzicht van alle Use Cases in de vorm van een Use Case Survey en een geïntegreerd Use Case diagram. Vervolgens worden alle individuele Use Cases beschreven waarbij tevens voor iedere Use Case diverse scenario’s zijn opgesteld.
De requirements van het systeem worden aangevuld met een opsomming van niet-functionele requirements waaraan het systeem zal moeten voldoen. De verschillende business rules (waar vanuit de Use Cases naar wordt gerefereerd) zijn genummerd en samengevoegd in een overzichtelijke tabel binnen de sectie ‘Business Rules Catalogue’.
Tot slot is in de bijlagen een geïntegreerd domeinmodel en een verklarende woordenlijst opgenomen.
Problem statement
We zijn de volgende problemen tegengekomen:
- Lastige legenda voor de agenda; Spelers kunnen moeilijk zijn hoe de data in elkaar steekt.
- Beschikbaarheid intrekken gaat niet makkelijk; Het moest omslachtig via de telefoon.
- Veel verschillende programma's, leidt tot frustratie bij gebruikers; De outlook agenda werd niet als handig beschouwt.
- Sommige spelers hadden de behoefte om hun concurrentie te bekijken, of het werk wel eerlijk verdeeld is.
- Communicatie is vaak slecht; Gebruikers moeten zelf initiatief nemen om de planning-status te bekijken en zijn hierdoor vaak laat op de hoogte van wijzigingen.
- Voor iedere actie worden verschillende systemen gebruikt; de spelers hebben een eigen agenda, en de beheerders hebben een losse agenda waar de opties in staan. Ze willen een nieuw systeem.
We concluderen uit deze problemen dat de spelerplanner nodig moet worden aangepast en dat er een overzichtelijk eenduidig systeem moet komen, waar geen ingewikkelde legenda's voor nodig zijn.
Case analysis
Stakeholder analysis
Hieronder volgt een overzicht van de soorten stakeholders die betrokken zijn bij dit project, dit is op type niveau:
| # | Naam | Functiebelangen |
|---|---|---|
| 01 | Speler | Spelers vinden het belangrijk dat ze de planning van andere spelers kunnen inzien. Dit in verband met onderlinge concurrentiestrijd. Spelers vinden het ook belangrijk dat ze zelf hun beschikbaarheid kunnen opgeven en weer ongedaan maken. |
| 02 | Kantoormedewerker | Kantoormedewerkers hebben er belang bij overal controle over te hebben. Zij moeten in ieder onderdeel van het systeem gegevens kunnen bekijken en veranderen. |
| 03 | Ateliermedewerker | Ateliermedewerkers hebben er belang bij dat ze weten waar ieder kostuum zich bevind, zodat ze het kunnen repareren wanneer dit nodig is. |
Binnen deze case hebben we één persoon die communicatie namens alle stakeholders verzorgt, zie de volgende tabel, dit is op instantie niveau:
| # | Naam | Functiebelangen |
|---|---|---|
| 01 | Niels Braakensiek | Niels verzorgt alle communicatie namens Close-Act. Hij representeert dus de 'spelers', maar ook de 'kantoormedewerkers' en 'ateliermedewerkers' die met het uiteindelijke systeem in aanraking komen. |
Mission and vision statement
Mission (purpose)
Het project zal het gebruikersgemak van het systeem moeten verbeteren. Hierbij moet vooral gedacht worden aan de agenda, spelersplanning, kostuumplanning en een standaard wijze om offertes op te stellen.
Vision (future)
Het project zal een systeem opleveren waarmee de agenda buiten outlook wordt gehaald en waarbij het gebruikersgemak en de overzichtelijkheid sterk verbeterd worden. Ook zal het systeem de planningen van spelers en kostuums onder zijn hoede nemen. Ten slotte zal het systeem een template van een offerte bevatten wat standaard naar potentiële klanten gestuurd kan worden. Allesomvattend gaat het systeem werk exacter en gebruiksvriendelijker doen dan het huidige systeem.
Statement of work
Deadlines
- Facade iteratie: 19 april
- Filled iteratie: 24 mei
- Focused iteratie: 21 juni
Statussen
| Code | Betekenis | Uitleg |
|---|---|---|
| V | Voltooid | Deliverable is nagekeken door minstens 1 teamlid en is klaar om ingeleverd te worden. |
| C | Controleren | Deliverable is gemaakt door de verantwoordelijk en dient te worden gecontroleerd/verbeterd door een groepslid. |
| B | Bezig | Deliverable is in de maak op de wiki. |
| NG | Niet gestart | Het maken van deze deliverable is nog niet (op de wiki, voor deze facade) gestart. |
| NV | Niet vereist | Deliverable is (in deze iteratie) niet vereist. |
Status deliverables
| Deliverable | Verantwoordelijke | Facade iteratie | Status | Filled iteratie | Status | Focused iteratie | Status |
|---|---|---|---|---|---|---|---|
| Introduction | Groep | Preliminary version | V | Preliminary version | V | Complete | V |
| Problem statement | Groep | As good as possible | V | As good as possible | V | Complete | V |
| Stakeholder analysis | Groep | As good as possible | V | As good as possible | V | Complete | V |
| Mission-vision-values | Groep | Complete | V | Complete | V | Complete | V |
| Statement of work | Tim | Complete, and up-to-date | C | Complete, and up-to-date | V | Complete, and up-to-date | V |
| Risk analysis | Groep | Complete, and up-to-date | V | Complete, and up-to-date | V | Complete, and up-to-date | V |
| Use case survery | Groep | As good as possible | V | Nearly complete | V | Complete, and up-to-date | V |
| Integrated UC diagram | Groep | Complete (though preliminary) | V | Complete | V | Complete | V |
| Use cases | Groep | Not yet! | NV | "Filled" level | V | Complete | V |
| Scenarios | Groep | Not yet! | NV | Several for each UC | V | Complete ("focused" level) | V |
| Domain models | Groep | Not yet! | NV | Partially complete | V | Complete | V |
| Integrated domain model | Groep | Not yet! | NV | Partially complete | V | Complete | V |
| Business rules catalogue | Groep | Not yet! | NV | Partially complete | V | Complete | V |
| Non-functional requirements | Groep | Notes | V | Partially complete | V | Complete | V |
| Terminological definitions | Groep | Notes | V | Partially complete | V | Complete | V |
| Executive sponsor viewpoint | Groep | Complete (integrated in M-V-V!) | V | Complete (integrated in M-V-V!) | V | Complete (integrated in M-V-V!) | V |
| Use case tests | Groep | Notes | V | As good as possible | V | Complete | V |
| Business process definitions | Groep | If available / relevant | NV | If relevant | NV | If relevant | NV |
| GUI metaphors / storyboards | Groep | If relevant | NV | If relevant | NV | If relevant | NV |
Risk analysis
| # | Category | Risk | Solution needed by | Status | Days lost | Expectancy factor | Risk factor |
|---|---|---|---|---|---|---|---|
| 01 | Team | Een of meerdere teamleden worden ziek/overlijden/stoppen met studie of zijn om een andere reden (tijdelijk) niet een staat om het project voort te zetten | - | - | 5 | 20% | 1 |
| 02 | Stakeholder | De stakeholder wordt ziek/overlijdt/neemt ontslag of is om een andere reden (tijdelijk) niet in staat een bijdrage te leveren aan het project | - | - | 10 | 5% | 2 |
| 03 | Opslag | De inhoud van het project gaat (ondanks vele kopieën) verloren door opslagproblemen en we zullen het project opnieuw moeten starten | - | - | 14 | 1% | 1 |
| 04 | Stakeholder tevredenheid | De stakeholder is niet tevreden met de uitkomst/voortgang van het project. Er zal een deel opnieuw gedaan moeten worden of moet worden aangevuld. | - | - | 7 | 50% | 4 |
| 05 | Ontbrekende informatie | Er ontbreekt bij ons essentiële informatie, die nodig is verder te gaan met een (deel) van het project. Deze informatie moet worden achterhaald via de stakeholder (Niels). | - | - | 1 | 25% | 4 |
Requirements
Use cases
Use case survey
| # | Naam | Beschrijving | Initiërende actor |
|---|---|---|---|
| 01 | Optie beheren | Deze Use Case stelt de gebruiker in staat om een item toe te voegen in de agenda, te bewerken en te verwijderen | Kantoormedewerker |
| 02 | Kostuumreservering beheren | Deze Use Case stelt de gebruiker in staat om kostuums voor een bepaalde datum te reserveren, een reservering te bewerken en te verwijderen | Kantoormedewerker & Ateliermedewerker |
| 03 | Kostuumplanner bekijken | Deze Use Case stelt de gebruiker in staat om in de kostuumplanning te kijken | Kantoormedewerker & Ateliermedewerker |
| 04 | Beschikbaarheid opgeven | Deze Use Case stelt de gebruiker in staat om op te geven wanneer hij/zij beschikbaar is om te spelen | Speler & Kantoormedewerker |
| 05 | Beschikbaarheid intrekken | Deze Use Case stelt de gebruiker in staat om een reeds opgegeven datum, waarvoor hij/zij heeft aangegeven te kunnen spelen en niet is ingepland, deze beschikbaarheid in te trekken. | Speler & Kantoormedewerker |
| 06 | Speler inplannen | Deze Use Case stelt de gebruiker in staat een speler aan een optie te koppelen en hem op deze wijze vast te zetten voor een bepaalde datum. | Kantoormedewerker |
| 07 | Spelersplanner bekijken | Deze Use Case stelt de gebruiker in staat om de spelersplanning te bekijken | Speler & Kantoormedewerker |
| 08 | Medewerker beheren | Deze Use Case stelt de gebruiker in staat een medewerker toe te voegen, te bewerken en te verwijderen. | Kantoormedewerker |
| 09 | Logistiekplanner bekijken | Deze Use Case stelt de gebruiker in staat de logistiekplanning te bekijken | Kantoormedewerker |
Integrated use case diagram
Individual use cases
Optie beheren
| Use Case | Optie beheren | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | Deze Use Case stelt de gebruiker in staat om wijzigingen aan te brengen aan een optie in de agenda (toevoegen, bewerken, verwijderen) | ||||||||||
| Trigger | Kantoormedewerker wil een optie toevoegen, bekijken, bewerken of verwijderen | ||||||||||
| Version | 1.3 | ||||||||||
| BCoE |
1) gebruiker- geeft aan optie te willen toevoegen, bewerken of te verwijderen 2) systeem- toont huidige agenda en vraagt om welke optie het gaat 3) gebruiker- geeft aan om welke optie het gaat 4) systeem- toont optie en bijbehorende informatie en vraagt om de informatie aan te passen 5) gebruiker- voert wijzigingen in 6) systeem- toont overzicht en vraagt om bevestiging 7) gebruiker- geeft bevestiging | ||||||||||
| Alternate paths |
| ||||||||||
| Preconditions | - gebruiker heeft zich geauthenticeerd bij het systeem | ||||||||||
| Postcondition | - optie is aangepast | ||||||||||
| Related business rules | B03, B04 | ||||||||||
| Author | Dré | ||||||||||
| Date | 29-05-2012 |
Domein Model:
Kostuumreservering beheren
| Use Case | Kostuumreservering beheren | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Description | Deze Use Case stelt de gebruiker in staat om kostuums voor een bepaalde datum te reserveren of een huidige reservering aan te passen | ||||||||
| Trigger | Kantoormedewerker wil een kostuum reserveren
Ateliermedewerker wil een kostuum reserveren voor onderhoud. | ||||||||
| Version | 1.22 | ||||||||
| BCoE |
1) gebruiker- geeft aan een kostuumreservering te willen bewerken 2) systeem- vraagt welke reservering de gebruiker wil bewerken 3) gebruiker- geeft aan welke kostuumreservering hij wil aanpassen 4) systeem- toont huidige informatie en vraagt om de wijzigingen 5) gebruiker- wijzigt de reservering 6) systeem- toont nieuwe informatie en vraagt om bevestiging 7) gebruiker- geeft bevestiging | ||||||||
| Alternate paths |
| ||||||||
| Preconditions | - gebruiker heeft zich geauthenticeerd bij het systeem | ||||||||
| Postcondition | - de reservering heeft nieuwe informatie | ||||||||
| Related business rules | B05, B06 | ||||||||
| Author | Dré | ||||||||
| Date | 11-05-2012 |
Domein Model:
Kostuumplanning bekijken
| Use Case | Kostuumplanner bekijken |
|---|---|
| Description | Deze Use Case stelt de gebruiker in staat om de kostuumplanning in te zien |
| Trigger | Kantoormedewerker wil de kostuumsplanner inzien
Ateliermedewerker wil de kostuumsplanner inzien |
| Version | 1.2 |
| BCoE |
1) gebruiker- geeft aan de kostuumplanning te willen bekijken 2) systeem- toont huidige kostuumplanning |
| Alternate paths | - |
| Preconditions | - gebruiker heeft zich geauthenticeerd bij het systeem |
| Postcondition | - |
| Related business rules | B06 |
| Author | Dré |
| Date | 11-05-2012 |
Domein Model:
Beschikbaarheid opgeven
| Use Case | Beschikbaarheid opgeven | ||||
|---|---|---|---|---|---|
| Description | Deze Use Case stelt de gebruiker in staat om op te geven wanneer hij/zij beschikbaar is om te spelen | ||||
| Trigger | Speler wil zijn beschikbaarheid opgeven | ||||
| Version | 1.00 | ||||
| BCoE |
1) gebruiker- geeft aan de beschikbaarheid op te willen geven 2) systeem- toont spelersplanning 3) gebruiker- geeft aan wanneer hij/zij beschikbaar is 4) systeem- vraagt om bevestiging 5) gebruiker - geeft bevestiging | ||||
| Alternate paths |
| ||||
| Preconditions | - er is een spelersplanning
- gebruiker heeft zich geauthenticeerd bij het systeem | ||||
| Postcondition | beschikbaarheid is aangepast in de spelers planning | ||||
| Related business rules | B01, B02, B09 | ||||
| Author | Dré | ||||
| Date | 11-05-2012 |
Domein Model:
Beschikbaarheid intrekken
| Use Case | Beschikbaarheid intrekken | ||||
|---|---|---|---|---|---|
| Description | Deze Use Case stelt de gebruiker in staat om een reeds opgegeven datum, waarvoor hij/zij heeft aangegeven te kunnen spelen en niet is ingepland, deze beschikbaarheid in te trekken. | ||||
| Trigger | Een speler wil zijn/haar beschikbaarheid intrekken. Een kantoormedewerker wil de beschikbaarheid van een speler intrekken. | ||||
| Version | 1.20 | ||||
| BCoE |
1) systeem- toont huidige persoonlijke agenda 2) gebruiker- geeft aan welke beschikbaarheid hij/zij wil intrekken 3) systeem- vraagt om bevestiging 4) gebruiker- geeft bevestiging | ||||
| Alternate paths |
| ||||
| Preconditions | - gebruiker heeft zich geauthenticeerd bij het systeem | ||||
| Postcondition | -beschikbaarheid is ingetrokken | ||||
| Related business rules | B02, B09 | ||||
| Author | Dré | ||||
| Date | 11-05-2012 |
Domein Model:
Speler inplannen
| Use Case | Speler inplannen | ||||
|---|---|---|---|---|---|
| Description | Deze Use Case stelt de gebruiker in staat om een speler die beschikbaar is tijdens het te plannen evenement in te plannen voor dit evenement. | ||||
| Trigger | Kantoormedewerker wil een speler inplannen | ||||
| Version | 1.20 | ||||
| BCoE |
1) gebruiker- geeft aan een speler te willen inplannen 2) systeem- vraagt om nodige informatie 3) gebruiker- geeft nodige informatie 4) systeem- vraagt om bevestiging 5) gebruiker- geeft bevestiging | ||||
| Alternate paths |
| ||||
| Preconditions | - gebruiker heeft zich geauthenticeerd bij het systeem | ||||
| Postcondition | -speler is ingepland | ||||
| Related business rules | B02, B09, B10 | ||||
| Author | Dré | ||||
| Date | 11-05-2012 |
Domein Model:
Spelersplanning bekijken
| Use Case | Spelersplanner bekijken | ||||
|---|---|---|---|---|---|
| Description | Deze Use Case stelt de gebruiker in staat om de spelersplanning te bekijken | ||||
| Trigger | Een speler of kantoormedewerker wil de spelersplanner inzien | ||||
| Version | 1.21 | ||||
| BCoE |
1) systeem- vraagt: persoonlijke spelersplanning of die van iedereen 2) gebruiker- kiest persoonlijke spelersplanning 3) systeem- toont persoonlijk overzicht | ||||
| Alternate paths |
| ||||
| Preconditions | - gebruiker heeft zich geauthenticeerd bij het systeem | ||||
| Postcondition | - | ||||
| Related business rules | B02, B07, B11 | ||||
| Author | Dré | ||||
| Date | 11-05-2012 |
Domein Model
Medewerker beheren
| Use Case | Medewerker beheren | |||
|---|---|---|---|---|
| Description | Deze Use Case stelt de gebruiker in staat om een medewerker te bewerken en/of toe te voegen | |||
| Trigger | Kantoormedewerker wil de gegevens van een medewerker veranderen of aanmaken | |||
| Version | 1.00 | |||
| BCoE |
1) gebruiker kiest Medewerker beheren 2) systeem- toont huidige medewerkers en een optie om een medewerker toe te voegen 3) gebruiker- maakt een keuze 4) systeem- toont (ingevulde) informatie 5) gebruiker- bewerkt/vult de informatie (aan) 6) systeem- toont informatie en vraagt om bevestiging 7) gebruiker- geeft bevestiging | |||
| Alternate paths |
| |||
| Preconditions | - gebruiker heeft zich geauthenticeerd bij het systeem | |||
| Postcondition | - gegevens van een medewerker zijn (eventueel) aangepast | |||
| Related business rules | B14 | |||
| Author | Dré | |||
| Date | 11-05-2012 |
Domein Model:
Logistiekplanning bekijken
| Use Case | Logistiekplanner bekijken |
|---|---|
| Description | Deze Use Case stelt de gebruiker in staat om de logistiekplanning te bekijken |
| Trigger | Kantoormedewerker wil op de hoogte zijn van de logistiekplanner |
| Version | 1.00 |
| BCoE |
1) gebruiker- geeft aan logistiekplanning te willen bekijken 2) systeem- toont logistiekplanning |
| Alternate paths | - |
| Preconditions | - gebruiker heeft zich geauthenticeerd bij het systeem |
| Postcondition | - |
| Related business rules | B12, B13 |
| Author | Dré |
| Date | 11-05-2012 |
Domein Model:
Scenarios
Optie beheren
Scenario 1 - BCoE
1) Fritz - geeft aan optie te willen bewerken.
2) Systeem - toont huidige optieplanner en vraagt om welke optie het gaat
3) Fritz - geeft aan het optie van 25 mei 2013 Amsterdam.
4) Systeem - toont van de optie 25 mei 2013 de resultaten en vraagt of je de informatie van de optie wilt wijzigen.
5) Fritz - verandert de speler toon in de speler sjaak
6) Systeem - toont overzicht en vraagt om bevestiging
7) Fritz - geeft bevestiging
Scenario 2 - Alternate Path 1
1) Henk - geeft aan optie te willen toevoegen.
2) Systeem - toont een "lege" optie en vraagt om de informatie in te vullen
3) Henk - Kiest als naam Denemarken 20 mei 2014, vult als spelers Sjaak en Daniel in, als kostuums Saurus 4 en Saurus 5.
4) Systeem - toont overzicht en vraagt om bevestiging
5) Henk - geeft bevestiging
Scenario 3 - Alternate Path 2
1) Henk - geeft aan optie te willen verwijderen.
2) Systeem - toont huidige optieplanner en vraagt om welke optie het gaat.
3) Henk - geeft aan om de optie Düsseldorf 1 januari 2013 gaat.
4) Systeem - vraagt bevestiging
5) Henk - geeft bevestiging
Scenario 4 - Alternate Path 3
1) Jan - geeft aan een optie te willen bekijken
2) Systeem - toont optie planner.
Scenario 5 - Alternate Path 4
7) Henk - geeft geen bestiging
8) Systeem - gaat terug naar stap 4
Kostuumreservering beheren
Scenario 1 - BCoE
1) Sjaak - geeft aan een kostuumreservering te willen bewerken
2) Systeem - vraagt welke reservering de gebruiker wil bewerken.
3) Sjaak - geeft aan dat hij Saurus 3 wil bewerken
4) Systeem - toont dat het kostuum stuk is en gerepareerd wordt.
5) Sjaak - wijzigt kostuum Saurus 3 van is kapot ja naar is kapot nee.
6) Systeem - toont Saurus 3 is gerepareerd
7) Sjaak - geeft bevestiging
Scenario 2 - Alternate Path 1
1) Henk - geeft aan een kostuumreservering te willen toevoegen
4) Systeem - toont "lege" reservering en vraagt om die in te vullen
5) Henk - vult in dat het kostuum saurus 4 stuk is en dat het gerepareerd wordt van 15 mei 2013 tot 20 mei 2013
6) Systeem - toont nieuwe informatie en vraagt om bevestiging
7) Henk - geeft bevestiging
Scenario 3 - Alternate Path 2
5) Henk - geeft aan dat hij het kostuum saurus 5 van3 mei tot 10 mei 2013 wil reserveren
6) Systeem - geeft aan dat het kostuum gereserveerd is en gaat daarna terug naar stap 4. '
Scenario 4 - Alternate Path 3
7) Sjaak - geeft geen bevestiging
8) Ga terug naar stap 5.
Kostuumplanner bekijken
Scenario 1 - BCoE
1) Sjaak - geeft aan de kostuumplanning te willen bekijken
2) Systeem - toont huidige kostuumplanning
Beschikbaarheid opgeven
Scenario 1 - BCoE
1) Jaap - opent de spelersplanning.
2) Jaap - geeft aan dat hij nieuwe beschikbaarheid wil aangeven.
3) Jaap - geeft aan dat hij van 14 tot 30 april beschikbaar is.
4) Systeem - vraagt om bevestiging.
5) Jaap - bevestigt.
Scenario 2 - Alternate Path 1
5) Sjaak - geeft geen bevestiging
6) Systeem - sluit af
Beschikbaarheid intrekken
Scenario 1 - BCoE
1) Henk - wil zijn beschikbaar voor 19-11-2012 intrekken omdat hij graag een dag eerder op vakantie wil.
2) Systeem - toont huidige persoonlijke agenda
3) Henk - geeft aan dat hij de beschikbaarheid van 19-11-2012 wil intrekken
4) Systeem - vraagt om bevestiging
5) Henk - geeft bevestiging
Scenario 2 - Alternate Path 1
4) Systeem - zegt dat hij al in ingepland en dat het dus niet mogelijk is.
5) Systeem - laat het persoonlijke rooster zien.
Speler inplannen
Scenario 1 - BCoE
1) Henk - geeft aan een speler te willen inplannen
2) Systeem - vraagt om nodige informatie
3) Henk - vult het volgende in Speler: Jaap, Optie: Den Bosch 18-05-2012, begindatum: 18-05-2012, einddatum: 20-05-2012.
4) Systeem - toont ingevulde informatie en vraagt bevestiging
5) Henk - bevestigt zijn bewerking.
Scenario 2 - Alternate Path 1
1) Henk - geeft aan een speler te willen inplannen
2) Systeem - vraagt om nodige informatie
3) Henk - vult het volgende in Speler: Jaap, Optie: Den Bosch 18-05-2012, begindatum: 18-05-2012, einddatum: 20-05-2012.
4) Systeem - toont ingevulde informatie en vraagt bevestiging
5) Henk - ziet dat hij een typfout heeft gemaakt en geeft geen bevestiging. Hij komt dan terug bij de ingevulde velden. Daar wijzigt hij de typfout.
6) Systeem - toont ingevulde informatie en vraagt bevestiging
7) Henk - bevestigt
Spelersplanner bekijken
Scenario 1 - BCoE
1) Henk - geeft aan zijn rooster te willen bekijken.
2) Systeem - vraagt "persoonlijke spelersplanning" of "spelersplanning van iedereen".
3) Henk - geeft aan dat hij zijn persoonlijke spelersplanning wil bekijken.
4) Systeem - toont persoonlijk overzicht.
Scenario 2 - Alternate Path 1
1) Henk - geeft aan zijn rooster te willen bekijken.
2) Systeem - vraagt "persoonlijke spelersplanning" of "spelersplanning van iedereen".
3) Henk - geeft aan dat hij het overzicht van iedereeen wil bekijken.
4) Systeem - toont overzicht alle spelers.
Medewerker beheren
Scenario 1 - BCoE
1) Sjaak - kiest Medewerker beheren
2) Systeem - toont huidige medewerkers en een optie om een medewerker toe te voegen
3) Sjaak - maakt een keuze
4) Systeem - toont (ingevulde) informatie
5) Sjaak - bewerkt/vult de informatie (aan)
6) Systeem - toont informatie en vraagt om bevestiging
7) Sjaak - geeft bevestiging
Scenario 2 - Alternate Path 1
7) Sjaak - geeft geen bevestiging
8) Systeem - stopt
Logistiekplanner bekijken
Scenario 1 - BCoE
1) Sjaak - geeft aan logistiekplanning te willen bekijken
2) Systeem - toont logistiekplanning
Non-functional Requirements
| Authenticatie | Gebruikers moeten ingelogd zijn om het systeem te gebruiken; Voor Close-Act is dit van belang omdat je hiermee voorkomt dat buitenstaanders toegang tot het systeem krijgen en hierdoor onrechtmatig info verkrijgen. |
| Autorisatie | Gebruikers moeten rechten hebben om bepaalde functionaliteit te kunnen gebruiken; Voor Close-Act is dit van belang omdat het niet wenselijk is dat spelers bijvoorbeeld opties kunnen wijzigen. Verder voorkom je hiermee dat iedereen in privacy gevoelige info van de klant kan bekijken, denk hierbij aan betaalinformatie, adresgegevens etc. |
| Beschikbaarheid | Systeem moet een beschikbaarheid hebben van 95%; voor Close-Act is dit van belang omdat een speler dan op ieder moment zijn/haar beschikbaarheid kan opgeven/intrekken. Voor kantoormedewerkers kan dit van belang zijn omdat er vanuit het buitenland altijd (dus ook 's nachts) een berichtgeving gedaan kan worden ten behoeve van de act. Deze informatie dient direct in het systeem verwerkt kunnen worden. |
| Gebruiksvriendelijkheid | Systeem moet gebruikt kunnen worden zonder dat daarvoor training vereist is; in een organisatie kunnen er medewerkers komen en gaan. Het is voor die mensen belangrijk dat ze direct aan de slag kunnen en niet eerst op een cursus moeten om het systeem te kunnen doorgronden. |
| Compatibiliteit | Systeem moet toegankelijk zijn voor de volgende besturingssystemen: Windows, Mac en Linux; Voor Close-Act is dit belangrijk omdat met name de spelers op hun eigen systeem de beschikbaarheid opgeven. Het zou zeer inefficiënt zijn als ze dit niet kunnen doen omdat hun besturingssysteem niet (goed) wordt ondersteund. |
Addendum
Integrated Domainmodel
Business Rules Catalogue
Business Rules
| # | Business Rule |
|---|---|
| B01 | Spelers geven zichzelf op wanneer zij beschikbaar zijn voor activiteiten. |
| B02 | Bewerkingen op spelers beschikbaarheid kunnen alleen gedaan worden door kantoormedewerkers en de desbetreffende speler. |
| B03 | Alleen kantoormedewerkers mogen opties plaatsen en opties beheren in de agenda. |
| B04 | Bij het plaatsen van een optie in de agenda worden direct kostuums vrijgehouden en de spelers ingepland voor die optie. |
| B05 | Ateliermedewerkers maken modificaties aan of repareren kostuums. Wanneer een kostuum in onderhoud is kan deze niet worden ingepland. |
| B06 | Alleen kantoormedewerkers en ateliermedewerkers beheren gezamenlijk de kostuumplanner. |
| B07 | Kantoormedewerkers en spelers hebben inzicht in de opties die zijn opgenomen in de agenda. |
| B08 | Opties zijn alleen voor spelers via de spelersplanning zichtbaar. |
| B09 | Wanneer een act is ingepland kan de speler zijn beschikbaarheid niet meer intrekken. Dit kan eventueel in overleg met administratief medewerkers. |
| B10 | Het is alleen de taak van kantoormedewerkers om spelers in te plannen. |
| B11 | Spelers en kantoormedewerkers moeten beiden inzicht hebben in de spelersplanning. |
| B12 | Medewerkers met logistieke taken moeten inzicht hebben in de logistieke planning. |
| B13 | Alleen kantoormedewerkers beheren de planning m.b.t. logistieke activiteiten. |
| B14 | Alleen kantoormedewerkers beheren de gebruikers van het systeem. |
Terminological Definitions
| Term | Beschrijving |
|---|---|
| Speler | Een speler is een persoon die kan optreden in een show van Close-Act. |
| Kantoormedewerker | Een kantoormedewerker is een persoon die alle administratieve bevoegdheden binnen Close-Act heeft. |
| Klant | Een klant is een persoon of een bedrijf die een product (show) van Close-Act wil afnemen. |
| Ateliermedewerker | Een ateliermedewerker is een persoon die werkzaam is op de kostuumafdeling van Close-Act. |
| Kostuum | Een kostuum is een kledingstuk dat gebruikt kan worden bij een show van Close-Act. |
| Kostuumplanner | Een kostuumplanner is een planner/agenda waarin op datum gesorteerd staat waar elk kostuum zich bevind en of het kapot is. |
| Kostuumreservering | Een kostuum reservering is een reservering die is toegevoegd op de kostuumplanner waarin iemand een beschikbaar kostuum voor een bepaalde tijd (ook toekomst) in bruikleen neemt. |
| Spelersplanner | Een spelersplanner is een planner/agenda waarin op datum gesorteerd staat waar elke speler moet optreden en waar in staat of hij/zij beschikbaar is op een bepaalde datum. |
| Optieplanner | Een optieplanner is een planner/agenda waarin op datum gesorteerd alle opties staan. |
| Optie | Een optie is een verzameling van speelinfo en contractgegevens. |
| Speelinfo | Een speelinfo is een verzameling van gegevens die voor een optreden van Close-act van belang zijn. |
| ContactpersoonClose-act | Een ContactpersoonClose-act is de vertegenwoordiger namens Close-act voor een bepaalde optie. |
| Opdrachtgever | Een opdrachtgever is een verzameling van gegevens over een klant van Close-act. |
| Contactpersoon | Een contactpersoon is een klant die informatie voor een bepaalde optie levert. |
| Info | Een info is een bestand met informatie over een bepaald onderdeel. |
| Logistiekplanner | Een logistiekplanner is een planner/agenda waarin op datum gesorteerd alle logistiekeitems staan en op welke plaats ze zich bevinden. |
| Logistiekitem | Een logistiekitem is een bouwonderdeel of vervoersmiddel van Close-Act. |
| Plaats | Een plaats is een locatie waar een optreden/show van Close-Act zich afspeelt. |
| Taak | Een taak is een functie (drummer, acteur etc.) die een speler kan hebben binnen Close-Act. |
| Datum | Een datum is een tijdsaanduiding in uur ddmmjjjj. |
| Naam | Een naam is een identificatiemiddel van een persoon, klant of kostuum. |
| Telefoonnummer | Een telefoonnummer is een 10 cijferig telefoonnummer waarop een persoon kan worden opgeroepen. |
| KapotKostuum | Een kapotKostuum is een kostuum dat gerepareerd moet worden door een ateliermedewerker (die het kostuum beheerd) en gedurende die tijd niet gebruikt kan worden voor een show/optreden. |
| Beheer van kostuum | Een beheer van kostuum is een functie van een ateliermedewerker die 1 of meerdere kostuums als vaste reparatie heeft. |
| Betaalinfo | Een betaalinfo bestaat uit alle gegevens die nodig zijn voor een succesvolle betaling. |
| Betaling | De transactie van geld naar een andere rekening. |
| Adres | Adres is een gegevensverzameling van straat, huisnummer, plaats |
| Postcode | Een postcode is een identificatiereeks voor een straat of regio. |
