Requirements Engineering/het werk/werkstuk/2010-11/Groep 06
Inhoud
- 1 Introduction
- 2 Problem statement
- 3 Stakeholder list/analysis
- 4 Mission-Vision-(Values)
- 5 Statement of Work
- 6 Risk Analysis
- 7 Use case survey
- 8 Use cases
- 9 Scenario's
- 10 Business rule catalogue
- 11 Integrated domain model
- 12 Integrated UC diagram
- 13 Non-functional Requirements
- 14 Terminological Definitions
Introduction
Deze wiki pagina is de werkplaats van groep 6 ten behoeve van het vak requirements engineering. Op deze pagina werken we gezamenlijk, volgens de drie iteraties uit Kulak and Guiney - Use cases (2004), naar de requirements voor de casus "Close Act". Het document beschrijft de eisen waaraan een nieuw computersysteem voor het bedrijf Close Act er uit zou moeten komen te zien.
Close Act is een bedrijf in de entertainment industrie dat zich heeft gespecialiseerd het verzorgen van complete voorstellingen en mobiele acts op festivals en evenementen over de hele wereld. Hierbij wordt gebruik gemaakt van steltlopers, muzikanten, dansers, vuurspelers en acrobaten. Het bedrijf organiseert jaarlijks tientallen acts wereldwijd, dit verreist veel organisatie omtrent de logistiek, materiaal en spelers. Close Act regelt dit alles vanuit het kantoor in Tilburg, hier werkt het personeel aan het realiseren van acts voor tal van opdrachtgevers.
Om de organisatie van de acts in goede banen te leiden maakt het bedrijf momenteel gebruik van een systeem wat onder andere bestaat uit de volgende drie belangrijkste componenten: een algemene agenda, een speler-planner en een kostuum-planner. In het systeem staat cruciale informatie over opdrachten opgeslagen, vanaf de eerste aanvraag tot aan een uiteindelijk contract. Het is van belang dat iedere werknemer op het kantoor deze informatie kan inzien en informatie kan toevoegen over lopende aanvragen.
Gezien de complexiteit van het systeem en de organisatie van de opdrachten ontstaan er nu regelmatig fouten in de organisatie; zo worden spelers/kostuums dubbel geboekt of zijn paklijsten voor transport niet compleet. Verder komt het voor dat bepaalde informatie over spelers of opdrachten niet in het systeem is opgenomen maar enkel als kennis bij bepaalde werknemers bekend is. Hierdoor is het onmogelijk om werkzaamheden over te dragen tussen werknemers en hebben werknemers bepaalde taken en/of opdrachten waar zijn persoonlijk aan werken. Aangezien een aantal kantoor medewerkers parttime werken zorgt dit nog weleens voor problemen in de communicatie met opdrachtgevers.
Problem statement
Het huidige computersysteem voldoet niet meer, er werken veel mensen samen op een systeem dat daar eigenlijk niet geschikt voor is, hierdoor worden er onnodig fouten gemaakt. Het is voor kantoormedewerkers niet eenvoudig te zien welke opdrachten en opties voor opdrachten met de bijbehorende kostuums, spelers en technische middelen er op de planning staan. Verschillende gegevens staan in verschillende bestanden of systemen en sommige informatie is alleen bij de medewerkers zelf aanwezig, hierdoor komt het voor dat attributen en/of spelers dubbel ingepland worden wat een vervelende situatie voor het bedrijf en vooral de klanten oplevert. Close Act is zodoende toe aan een nieuw computersysteem dat dit soort fouten in de toekomst weet te beperken en informatie over spelers en opdrachten deelt met alle werknemers waardoor zij breder inzetbaar zijn en tijd besparen.
Stakeholder list/analysis
Stakeholders zijn zowel binnen als buiten het bedrijf te vinden, het kunnen ook klanten of zelfs andere bedrijven zijn.
Stakeholders zijn onder te verdelen in primaire stakeholders, secundaire stakeholders en key-stakeholders. Primair zijn die stakeholders die direct geraakt wordt in positieve danwel negatieve zin door de veranderingen die staan te gebeuren. Vaak zin dit gebruikers. Secundaire stakeholders worden indirect geraakt en de sleutel personen ofwel de key-stakeholders zijn over het algemeen de beslissers of de personen met veel invloed binnen een organisatie.
Het bedrijf Closeact is een klein bedrijf met een platte structuur. Al heeft de directeur het echt voor het zeggen, de overige mensen op kantoor spelen een vitale rol en zijn allen primaire stakeholders. Iedere wijziging in het systeem is direct van grote invloed op hun dagelijks werk. Het bestaat overigens geen twijfel over het feit dat de directeur een key-stakeholder is. Externe stakeholders zijn in dit geval niet aanwezig. Al hebben klanten een indirect belang bij het succesvol plannen van gebeurtenissen, een klant heeft geen interactie met het systeem en kan dus ook niet bijdragen aan het succes van het systeem.
Stakeholder lijst:
Key stakeholders:
- Niels Braakensiek
- Directeur Closeact
Primaire stakeholders:
- Kantoorpersoneel Closeact
Secundaire stakeholders:
- Acteurs Closeact
Mission-Vision-(Values)
Missie van het project
Een missie creëer je door jezelf de volgende vragen te stellen:
- waartoe en waarom bestaat onze organisatie/project
- wat is onze identiteit
- wat is onze primaire functie
- voor wie bestaan we
- in welke fundamentele behoefte wordt door ons voorzien
Het project bestaat om Closeact te helpen de verhoogde vraag en daarbij behorende problemen op het gebied van logistiek, planning en administratieve complexiteit beter het hoofd te kunnen bieden. Wij doen dit op integere wijze waarbij de wensen van de stakeholders leidend zijn.
Visie van het project
Een visie creëer je door jezelf te vragen:
- wat is ons toekomstbeeld. Ambities (lange termijn) en wat willen we bereiken
- wat is het gemeenschappelijke beeld van van de gewenst en haalbaar geachte toekomstige situatie
- waar staan we voor, wat verbindt ons, wie willen we zijn en wat is dan essentieel in onze houding
Wij willen een systeem creëren waarmee Closeact nu en in de toekomst op betrouwbare en flexibele wijze administratie kan voeren, evenementen kan plannen en kan communiceren met klanten, waarbij iedere gebruiker van het systeem altijd over de meest recente informatie beschikt en waarbij de flexibiliteit en overige kwaliteiten van het huidige systeem richtinggevend zijn voor het nieuw te ontwerpen systeem.
Values
- Als een requirement vragen oproept, stel deze dan
- Houdt goede ideeën niet voor jezelf maar bespreek deze met je omgeving en de projectleiding
- Als requirements bijstelling behoeven, verloopt dit op een centrale gecoördineerde wijze
- We streven naar het optimale
- Kwaliteit is pas kwaliteit als de klant dat zo ervaart
- Neem niets zomaar aan, zoek altijd bevestiging
- Fouten maken overkomt iedereen, het verzwijgen ervan is kwalijk
- Wij werken samen aan het realiseren van dit project. Dit vereist samenwerking.
- Openheid, eerlijkheid en fatsoenlijkheid zijn kernwaarden.
- Wij werken volgens de nieuwste bewezen technieken en inzichten. Iedere vrijdagmiddag bier.
Statement of Work
Scope and Objectives
Op dit moment heeft het bedrijf close-act verschillende planningssystemen voor acts en kostuums, en er is een apart order systeem. Doordat deze systemen los van elkaar gedraaid en gebruikt worden levert dit nu soms nog veel problemen op. Het is onze taak om te zorgen dat deze problemen worden opgelost. Hiervoor zijn twee opties. De eerste optie is het aanpassen van de huidige systemen, maar doordat dit veelal in programma's zoals Microsoft Excel gebeurt kunnen wij hier niet veel aan veranderen, omdat wij dit programma niet kunnen aanpassen. De tweede, betere optie, is om een nieuwe applicatie te bouwen waarin de verschillende systemen bij elkaar komen. Het doel van deze applicatie is dat alle informatie met elkaar in verband staat. Wanneer er dan bijvoorbeeld iemand probeert een act te plannen, terwijl de kostuums dan niet beschikbaar zijn, kan dit systeem automatisch hierover een bericht geven, wat bij de huidige losse systemen niet mogelijk is.
Het programma dat wij maken zal draaien op windows systemen met een database die op een server van het bedrijf staat. In deze database zal alle relevante informatie worden opgeslagen die vervolgens wordt gekoppeld aan de applicatie.
Uiteindelijk zal het werk bestaan uit verschillende onderdelen, die ook in de volgende volgorde worden uitgevoerd.
- Het verzamelen en opstellen van de requirements, zowel in een lijst als bijbehorende use cases
- Het ontwerpen van het programma en de database
- Het implementeren van de applicatie en de database
- Het testen van de applicatie met de database
- Hierna volgt het invoeren en bijhouden van het systeem, maar dit hoort vooralsnog niet bij onze taak
Overview of the application/User demography
De uiteindelijke applicatie zal simpelweg een programma zijn om de informatie in de database zinvol weer te geven en zal de gebruiker de mogelijkheid bieden om informatie in de database via een intuïtieve interface aan te passen. De verschillende onderdelen van de applicatie zullen bestaan uit het weergeven van een planning over een bepaalde tijd, het inplannen van een nieuwe act, informatie inzien over de planning van kostuums (deze zal gekoppeld zijn aan de planning van de acts) en deze eventueel aanpassen, het toevoegen/verwijderen/aanpassen van een werknemer en het zal de mogelijkheid bieden om orders in te zien of toe te voegen. Ook zal het natuurlijk mogelijk zijn om de status van een order te veranderen van bijvoorbeeld optie naar bevestigt of orders te verwijderen.
Over het algemeen zal het een eenvoudige applicatie worden die veel onderdelen van de huidige systemen overneemt, met name wat betreft interface. De reden hiervoor is dat de gebruikers van het systeem over het algemeen weinig van computers af weten. Als de nieuwe applicatie te ingewikkeld is of de gebruiker teveel de wil van de applicatie op legt zal de applicatie waarschijnlijk weinig of niet gebruikt worden. Het is dus essentieel dat de applicatie eenvoudig en vertrouwd wordt.
Constraints / Assumptions / Staffing and cost
Over deze onderdelen is weinig te zeggen in ons statement of work weinig te zeggen. Door de aard van het project hebben wij geen budget of beperkingen opgelegd gekregen. Ook hebben wij op dit punt nog geen aannames gemaakt. Mocht er later toch iets dergelijks blijken te zijn, zal dit alsnog toegevoegd worden aan het statement of work.
Deliverable outlines
Onze taak voor dit project is om de requirements voor een dergelijk systeem te verzamelen. Hoewel voor zo'n project eigenlijk ook het systeem gebouwd zou worden eventueel met bijbehorende database. Zie de voortgang pagina bij ons project om de voortgang van de requirements te bekijken. Om de scope niet te groot te maken focussen we ons op de opdrachten/contracten, de spelerplanning en alleen voor een klein deel de rekwisieten planning.
Expected duration
Het hele project vanaf het verzamelen van de requirements tot het introduceren van de deliverables bij het bedrijf zou in 3-4 maanden te doen moeten zijn. De eerste 6 weken zullen worden besteed aan het verzamelen van de requirements en het maken van een functioneel ontwerp. Dit geeft precies aan wat de applicatie uiteindelijk moet kunnen. Vervolgens kan in ongeveer 5 weken een technisch ontwerp worden gemaakt. Hierin staat precies hoe het uiteindelijke systeem zijn werk zal doen, op welke besturingssystemen en platformen het systeem zal draaien en hoe de link met de database werkt. Ook wordt hierin aangegeven hoe de code voor de applicatie er uit zal zien. Hierna zijn er nog 5 weken waarin de uiteindelijke implementatie en het testen plaatsvindt. Daarna zal het systeem geschikt zijn om gebruikt te worden.
Deze planning is gebaseerd op een team van 4 man die welke week ongeveer 6-10 met het project bezig zijn. In het geval dat er meer tijd beschikbaar is per week kan het laatste gedeelte van de planning, namelijk het implementeren en ook wel het technisch ontwerp, sneller worden uitgevoerd. Het verzamelen van de requirements zal echter hoe dan ook tijd kosten, omdat soms pas in de loop van de tijd aan alle partijen duidelijk wordt wat de requirements zijn. Als deze eenmaal bekend zijn kan er mogelijk sneller worden gewerkt.
Risk Analysis
| # | Risk | Probability | Days lost | Risk rating | Action |
|---|---|---|---|---|---|
| 01 | Er is te weinig kennis onder projectleden voor het uitvoeren van de implementatie. | 25% | 14 dagen | 3,5 | Extra cursus inlassen om benodigde kennis op te doen |
| 02 | Het bedrijf heeft niet op tijd testdata beschikbaar | 50% | 14 dagen | 7 | Direct om de data vragen en zorgen dat deze snel geleverd wordt |
| 03 | Misinterpretatie over requirements | 60% | 21 dagen | 12,6 | Dit kan altijd voorkomen, als dit optreedt bij het voorleggen van de requirements aan de opdrachtgever, zullen ze opnieuw moeten worden bekeken. |
| 04 | Gebruikers te druk voor gebruikerstesten | 70% | 14 dagen | 9.8 | Opnieuw inplannen van de tests |
Use case survey
| # | Name | Description | Initiating actor |
|---|---|---|---|
| 1 | Aanvraag opdracht | Er wordt een aanvraag gedaan voor bepaalde act op een bepaalde datum en er wordt gecheckt of dit kan | Kantoorpersoneel |
| 2 | Spelers inplannen | Het inplannen van de spelers voor acts | Kantoorpersoneel |
| 3 | Contract opmaken | Contract maken / tekenen / opdracht vastleggen | Kantoorpersoneel |
| 4 | Opdracht wijzigen | Hiermee kunnen allerlei dingen in opdrachten worden gewijzigd, wanneer dit is toegestaan | Kantoorpersoneel |
| 5 | Rooster bekijken | Spelers kunnen zo hun opdrachten bekijken | Spelers |
| 6 | Beschikbaarheid speler aanpassen | Instellen wanneer een speler niet beschikbaar is | Speler, kantoormedewerker |
| 7 | Attributen | Eenvoudig per data locatie attribuut aangeven | Kantoormedewerker |
| 8 | Logistiek | Zorgen dat attributen op tijd op locatie zijn | Logistiek medewerker |
Use cases
Aanvraag opdracht
Usecase
| Use case name: | Aanvraag opdracht |
| Iteration: | Filled |
| Summary: | Deze usecase beschrijft de aanvraag van een opdracht |
| Basic course of events: |
(1) De medewerker kiest in het systeem voor aanvraag opdracht (2) De medewerker geeft een datum op, hierbij moet een begin en einddatum worden opgegeven (3) De medewerker kiest vervolgens de gewenste act (4) Het systeem presenteert andere geplande acts op die datum alsmede de mogelijkheid voor de opgegeven act (5) De medewerker zoekt in het systeem of het bedrijf wat de act aanvraagt al in het systeem staat (zo niet eerst alternative path "bedrijf nog niet in het systeem" volgen) (6) De medewerker klikt op "aanvraag act" (7) Het systeem presenteert vervolgens een scherm waarin gegevens geselecteerd kunnen worden (8) De medewerker selecteert hier het bedrijf (9) Het systeem presenteert de algemene benodigdheden bij de gevraagde act, zoals aantallen kostuums en aantallen spelers en de beschikbaarheid hiervan (10) De medewerker kan invoeren of er eten en drinken nodig is (i.v.m. speelduur van sommige acts) (11) De medewerker kan aanpassingen doen, zoals het aantal kostuums veranderen etc. (12) De medewerker vult aanvullende informatie in, zoals speciale wensen en contactpersoon (13) De medewerker kiest er vervolgens voor om de ingevulde gegevens op te slaan (14) Het systeem vraagt de gebruiker om de offerte te printen (15) De medewerker bevestigd het printen van de offerte |
| Alternative paths: |
Bedrijf nog niet in het systeem (6) De medewerker gaat naar het scherm voor het invoeren van een nieuw bedrijf (7) De medewerker voert de gevraagde bedrijfsgegevens in (8) De medewerker sluit vervolgens het scherm om verder te gaan met de aanvraag van de opdracht |
| Exception paths: | |
| Extention points: | |
| Triggers: | Iemand die belt voor aanvraag van een opdracht |
| Assumptions: |
Aangevraagde datum ligt in het mogelijke te plannen termijn Aanvrager weet de mogelijke acts |
| Preconditions: |
De medewerker zit in het agenda scherm |
| Postconditions: | Een antwoord of de aangevraagde act op de gevraagde datum kan. |
| Related business rule: | Een ingevoerde, maar niet definitieve act, wordt ook als reeds geplande act gezien tijdens het plannen van een nieuwe act. (Zodat er niet twee acts op dezelfde tijd gepland kunnen worden, omdat ze nog niet officieel vastgelegd zijn middels een contract) |
| Author: | Harm van den Brink |
| Date: |
Domainmodel
Spelers inplannen
Usecase
| Use case name: | Spelers inplannen |
| Iteration: | |
| Summary: |
De usecase beschrijft de manier waarop spelers worden ingepland bij een aangevraagde act |
| Basic course of events: |
(1) De medewerker opent het overzicht van geplande acts (2) De medewerker selecteert een act (3) De medewerker opent vervolgens de spelersplanner (4) Het systeem geeft een overzicht van beschikbare spelers (hierbij wordt rekening gehouden met de act en datum van de act) (5) De medewerker vinkt vervolgens aan welke spelers hij toe wil voegen aan de act (6) De medewerker slaat de gegevens op (7) Het systeem verstuurd vervolgens naar de ingeplande spelers de datum en tijd van de act waarvoor zij zojuist zijn ingepland |
| Alternative paths: |
Speler wisselen voor andere (1) De medewerker opent het overzicht van geplande acts (2) De medewerker selecteert een act (3) De medewerker opent vervolgens de spelersplanner (4) Het systeem geeft aan dat er spelers ingepland zijn (5) Het systeem geeft per speler de mogelijkheid om deze te wijzigen voor een ander (6) De medewerker wijzigt een speler (7) Het systeem geeft een overzicht van beschikbare spelers (hierbij wordt rekening gehouden met de act en datum van de act, de al ingeplande spelers staan niet in de lijst) (8) De medewerker selecteert een andere speler (9) Het systeem vraagt om bevestiging om de ingeplande speler te wijzigen naar de zojuist geselecteerde speler (10) De gebruiker bevestigd de wijziging (11) Het systeem verstuurd vervolgens naar de gewijzigde speler dat hij niet meer ingepland is (12) Het systeem verstuurd vervolgens naar de nieuw ingeplande speler de datum en tijd van de act waarvoor zij zojuist zijn ingepland |
| Exception paths: | |
| Extention points: | |
| Triggers: | Act is definitief en spelers moeten ingepland worden |
| Assumptions: | Spelers zijn bekend in het systeem |
| Preconditions: | Act staat in het systeem |
| Postconditions: |
De spelers zijn ingepland |
| Related business rule: | Elke speler kan ingepland worden zolang hij/zij niet heeft aangegeven niet te kunnen |
| Author: |
Harm van den Brink |
| Date: |
Domeinmodel
Contract opmaken
Use case
| Use case name: | Contract opmaken |
| Iteration: | Focussed |
| Summary: | Deze use case beschrijft het definitief vastleggen van een act in een contract. |
| Basic course of events: |
(1) Een kantoormedewerker (hierna gebruiker) opent het systeem. (2) De gebruiker zoekt in het systeem de betreffende opdracht. (3) Het systeem toont een gedetailleerd overzicht van de opdracht. (4) De gebruiker geeft aan dat er van deze opdracht een contract moet worden opgemaakt. (5) Het systeem zet de details van de opdracht in een contract template en toont deze aan de gebruiker ter controle. (6) De gebruiker bevestigd het contract. (7) Het systeem verandert de status van de act in definitief, slaat het contract op en toont het contract, de gebruiker heeft een keuze mogelijkheid om het contract af te drukken of terug te keren naar het systeem. (8) De gebruiker kiest om het contract te printen. (9) Het systeem print het contract. |
| Alternative paths: |
(8) De gebruiker kiest om het contract via email te versturen. (9) Het systeem vraagt om de juiste contactpersoon of het juiste email adres van het bedrijf te selecteren. (10) De gebruiker selecteert de juiste contactpersoon of het juiste email adres. (11) Het systeem verstuurd het contract via email en bevestigd dit aan de gebruiker. |
| Exception paths: | |
| Extention points: | |
| Triggers: | Een medewerker welke een act definitief wil vastleggen. |
| Assumptions: | Alle klant en opdrachtgegevens zijn in het systeem aanwezig. |
| Preconditions: | Er moet een opdracht met status optie zijn waaruit een contract kan worden gemaakt. |
| Postconditions: | De actie moet een contract opleveren en de act definitief in het systeem vastleggen. |
| Related business rule: | Het contract bevat een aantal regels welke voortkomen uit de business rules:
|
| Author: | Joost Hendricksen |
| Date: | 5-6-2011 |
Domeinmodel
Opdracht wijzigen
Use case
| Use case name: | Opdracht wijzigen |
| Iteration: | Focussed |
| Summary: | Beschrijft de interacties met het systeem omtrent het wijzigen van een opdracht. |
| Basic course of events: |
(1) De kantoor medewerker (hierna gebruiker) start het systeem. (2) De gebruiker kiest voor aankomende opdrachten overzicht. (3) Het systeem toont lijst met aankomende opdrachten. (4) De gebruiker kiest de aan te passen opdracht. (5) Het systeem presenteert de gegevens bij de geselecteerde act. Hierbij maakt het systeem onderscheid tussen gegevens die geen wijziging voor het contract opleveren en gegevens die wél een wijziging voor het contract opleveren. (6) De gebruiker past de details van de gekozen opdracht aan. (7) Het systeem vraagt om bevestiging van wijzigingen. (8) De gebruiker bevestigd de wijzigingen. (9) Het systeem slaat de wijzigingen op. |
| Alternative paths: |
Indien de status van een opdracht optie of definitief is zijn de interacties als volgt: (7) Het systeem meld dat er door de gemaakte wijzigingen een wijziging in de offerte dan wel het contract moet plaatsvinden en geeft de gebruiker de optie om de wijzigingen door te voeren en verder te gaan met het opstellen van een contract/offerte, of de wijzigingen te annuleren.
|
| Exception paths: | |
| Extention points: | |
| Triggers: | Een gebruiker die de details van een opdracht wil aanpassen. |
| Assumptions: | |
| Preconditions: | De medewerker is ingelogd en er is een aankomende opdracht. |
| Postconditions: | De details van een openstaande opdracht zijn aangepast. |
| Related business rule: | Regels omtrent het aanpassen van contracten en offertes. |
| Author: | Joost Hendricksen |
| Date: | 5-6-2011 |
Domeinmodel
Rooster bekijken
Use case
| Use case name: | Rooster bekijken |
| Iteration: | Filled |
| Summary: | Beschrijft de mogelijkheden voor een speler om zijn rooster in te zien. |
| Basic course of events: |
(1) De speler logt in op het systeem met een unieke login. (2) Het systeem controleert de login en laat de gebruiker toe. (3) Het systeem geeft data en tijden weer en laat zien wanneer de speler moet werken. (4) De speler vraagt details op van een opdracht. (5) Het systeem toont details zoals waar en welke act aan de speler. (6) De speler herhaalt mogelijk stappen (4) en (5). (7) De speler logt uit. |
| Alternative paths: | |
| Exception paths: |
(1) "" (2) De login is fout en de speler krijgt geen toegang (1) De speler probeert het opnieuw. |
| Extention points: | |
| Triggers: | De speler wil zijn rooster weten, om uit te vinden wanneer en waar hij/zij moet werken. |
| Assumptions: | |
| Preconditions: | De speler heeft beschikking over een computer met toegang tot het systeem. |
| Postconditions: | De speler is op de hoogte van zijn rooster. |
| Related business rules: | *Elke speler ontvangt een unieke login voor het systeem wanneer hij/zij een contract tekent bij CloseAct. |
| Author: | Anne Westerhof |
| Date: | 4-6-2011 |
Domain Model
Beschikbaarheid speler aanpassen
Use Case
| Use case name: | Beschikbaarheid speler aanpassen |
| Iteration: | Filled |
| Summary: | Beschrijft de stappen die worden genomen om de beschikbaarheid in het systeem te zetten. |
| Basic course of events: |
(1) Een kantoormedewerker geeft aan het systeem aan beschikbaarheid van een speler te willen aanpassen. (2) Het systeem vraagt om de naam van de speler en data, en of het gaat om wel of niet beschikbaar. (3) De kantoormedewerker voert in om welke speler het gaat, om welke data en of het gaat om wel of niet beschikbaar zijn. (4) Het systeem controleert of deze verandering mogelijk is. (5) Het systeem keurt de verandering goed. (6) De kantoormedewerker sluit het betreffende deel van het systeem. (7) Het systeem stuurt de betreffende speler een bevestiging als het is gelukt. |
| Alternative paths: |
(1) De speler logt in bij het systeem met een unieke login. (2) Het systeem keurt de login goed. (3) De speler geeft aan dat hij zijn beschikbaarheid wil aanpassen. (4) Het systeem geeft de mogelijkheid data in te vullen en of het gaat om wel of niet beschikbaar. (5) De speler vult de juiste data in en geeft aan of hij tijdens die data wel of niet beschikbaar is. (6) Het systeem controleert of deze verandering mogelijk is. (7) Het systeem keurt de verandering goed. (8) De speler logt uit. |
| Exception paths: |
Bij BCoE: (4 / 5) Het is niet mogelijk om de verandering door te voeren, bijvoorbeeld omdat er al een opdracht staat. |
Bij Alternative path 1: (2) De login wordt niet goed gekeurd (3) De speler herstart alternative path 1 en probeert het opnieuw. | |
Bij Alternative path 1: (7) Het systeem keurt de verandering niet goed. (8) De speler "triggered" BCoE door contact op te nemen met een kantoormedewerker om het probleem op te lossen. | |
| Extention points: | |
| Triggers: | Er is een tijd bekend bij de speler of het kantoor waarin een speler juist wel of niet beschikbaar is. |
| Assumptions: | Voor de alternatieve course of events heeft de speler zelf een computer nodig met toegang tot het systeem. |
| Preconditions: | Op een moment dat een speler niet beschikbaar is, staat er nog geen opdracht gepland. |
| Postconditions: | De speler kan op een bepaalde tijd niet meer of juist wel ingepland worden. |
| Related business rule: |
|
| Author: | Anne Westerhof |
| Date: | 4-6-2011 |
Domain Model
Attributen
Use Case
| Use case name: | Reserveren attributen | |
| Iteration: | Filled | |
| Summary: | Deze use case beschrijft de eigenschappen dat attributen gekoppeld kunnen worden aan opdrachten, zodat per datum de locatie is aangeven waar een attribuut zich zal bevinden. | |
| Basic course of events: |
(1) De gebruiker navigeert naar het onderdeel attributenbeheer (2) Het systeem toont en scherm met bovenaan ruimte om het attribuut te reserveren en daaronder de lijst met attributen. Per attribuut wordt aangegeven, de datum waarop het attribuut zich bevindt op de locatie die erbij staat. Tevens staat hier het opdrachtnummer bij indien het attribuut gereserveerd is. De lijst is in eerste instantie gesorteerd op attribuut "soort attribuut". (3) De gebruiker voert opdrachtnummer in, in het daarvoor beschikbare veld en tevens de locatie en begin- en einddatum (dat de attributen op locatie moeten zijn) in en selecteert de attributen die bij deze opdracht nodig zijn. (4) Het systeem controleert de status van de opdracht. (5) Het systeem controleert de beschikbaarheid van het attribuut op gewenste datum (6) Het systeem toont een ander scherm met de verzamelde attributen en opdrachtgegevens en vraagt de gebruiker de bevestigen of te annuleren. (7) De gebruiker bevestigt of annuleert de reservering. | |
| Alternative paths: |
(1a) De gebruiker selecteert een opdrachtnummer en verlengt de terugkeerdatum van het attribuut (2a) Het systeem controleert deze nieuwe datum met andere reserveringen van het attribuut | |
| Exception paths: |
(3) Als de gebruiker een begin en/of einddatum invoert die in het verleden ligt, weigert het systeem de datum en brengt de gebruiker op de hoogte (3) Als de gebruiker een attribuut wil koppelen wat al gekoppeld is aan een andere opdracht, weigert het systeem de koppeling en signaleert de gebruiker (4) Als de status van de opdracht niet definitief is, dan laat het systeem de gebruiker weten dat het attribuut niet gereserveerd kan worden (5) Als het gewenste attribuut al gereserveerd is voor een andere act, dan laat het systeem de gebruiker weten dat het attribuut niet gereserveerd kan worden op gewenste datum (6) Als de gebruiker het systeem wil verlaten zonder de reservering te bevestigen of te annuleren, weigert het systeem dit en signaleert de gebruiker. | |
| Extention points: | ||
| Triggers: | Een gebruiker wil attributen reserveren voor een opdracht | |
| Assumptions: |
|
|
| Preconditions: | Bij het invoeren van een aanvraag wordt een opdrachtnummer gegenereerd welke op unieke wijze de opdracht identificeert. | |
| Postconditions: | Na gebruik van deze use case is de attributenplanning bijgewerkt danwel de informatiebehoefte van de gebruiker bevredigd. | |
| Related business rule: |
| |
| Author: | Bruno van Hoek | |
| Date: | 28-6-2011 |
Domain Model
Logistiek
Use Case
| Use case name: | Logistiek |
| Iteration: | Filled |
| Summary: | Ondersteuning voor de logistieke mensen om attributen tijdig op locatie te hebben |
| Basic course of events: |
(1) De gebruiker navigeert naar het onderdeel geplande opdrachten (2) Het systeem toont een overzicht van geplande opdrachten voor de komende periode, initieel gesorteerd op datum en met vermelding van het opdrachtnummer en details act. (3) De gebruiker heeft de mogelijkheid om een opdracht te selecteren (4) Het systeem toont in geval (3) de attributen behorende bij de act. (5) Het systeem biedt de gebruiker de mogelijkheid een pakbon uit te draaien op basis van een opdracht |
| Alternative paths: | |
| Exception paths: | (2) Indien geplande acts elkaar overlappen wordt de gebruiker hierop attent gemaakt. |
| Extention points: | |
| Triggers: | De gebruiker wil weten op welke datum, welke attributen verplaatst moeten worden . |
| Assumptions: | De attributen zijn gereserveerd conform opdracht en business rules |
| Preconditions: |
|
| Postconditions: | Na gebruik van deze use case heeft de gebruiker inzcht in de attributen die mee moeten naar een bepaalde locatie ivm een uit te voeren opdracht |
| Related business rule: |
|
| Author: | Bruno van Hoek |
| Date: | 28-6-2011 |
Domain Model
Scenario's
Opdracht wijzigen
- Jaap opent de applicatie.
- Jaap klikt op lopende opdrachten.
- Jaap selecteert de opdracht van "W. Tinnenveld b.v.".
- Jaap wijzigt de naam van de klant in "H. Tinnenveld b.v."
- Jaap selecteert Opslaan om de wijzigingen door te voeren.
- Jaap sluit de applicatie.
Contract opmaken
- Daisy opent de applicatie.
- Daisy opent het venster Lopende opdrachten.
- Daisy selecteert de lopende opdracht van "Rabobank Nederland".
- In het opdracht overzicht selecteert Daisy Contract opmaken.
- Daisy controleert bevestigt het contract.
Rooster bekijken
- The Joker logt in op het systeem met zijn naam en wachtwoord rekojeht.
- Het systeem controleert de login en laat de The Joker toe.
- Het systeem geeft de aankomende week weer en laat zien dat The Joker op maandag 12:00 en op dinsdag 17:00 moet werken.
- The Joker vraagt details op van de opdracht op maandag.
- Het systeem laat zien dat hij een clown moet spelen en dat hij een clownskostuum aan moet.
- The Joker bekijkt vervolgens ook de details van de opdracht op dinsdag.
- The Joker logt uit.
Beschikbaarheid aanpassen
- Lies geeft aan het systeem aan beschikbaarheid van Catwoman te willen aanpassen.
- Het systeem vraagt om de naam van de speler en data, en of het gaat om wel of niet beschikbaar.
- Lies voert in dat het om Catwoman gaat, op volgende week maandag en dat Catwoman dan niet beschikbaar is.
- Het systeem controleert of er op die dag opdrachten zijn voor Catwoman en deze zijn er niet.
- Het systeem keurt de verandering goed.
- Lies sluit het betreffende deel van het systeem.
- Het systeem stuurt Catwoman een bevestiging.
Beschikbaarheid aanpassen
- Catwoman logt in bij het systeem met een haar naam en wachtwoord namowtac.
- Het systeem keurt de login goed.
- Catwoman geeft aan dat ze haar beschikbaarheid wil aanpassen.
- Het systeem geeft de mogelijkheid data in te vullen en of het gaat om wel of niet beschikbaar.
- Catwoman vult in "5 augustus en dat ze die dag niet beschikbaar is".
- Het systeem ziet dat de datum verder dan een week weg is en dat er dan nog geen opdrachten staan.
- Het systeem keurt de verandering goed.
- Catwoman logt uit.
Raadplegen geplande attributen
- Marga navigeert naar het scherm waarin de attributen getoond worden.
- Na het openen van het scherm laat het systeem een lijst met attributen zien die zijn gesorteerd op datum en daarbinnen op act.
- Marga selecteert de gewenste datum of een bepaald attribuut. Is de lijst langer dan 1 pagina, dan zij ernaartoe bladeren.
- Het systeem toont de opgevraagde informatie op het scherm.
- Marga neemt kennis van de informatie en verlaat de applicatie.
Reserveren attributen
- Ineke opent het systeem en navigeert naar 'attributenbeheer' met de intentie om attributen te reserveren
- Het systeem toont een scherm met een invoerdeel en daaronder de aanwezige attributen
- Ineke voert het opdrachtnummer in en de begin- en einddatum van de reservering en de locatie van de opdracht en selecteert de benodigde attributen
- Het systeem controleert de beschikbaarheid van het attribuut en koppelt het attribuut aan opdrachtnummer
- Het systeem toont een scherm met de opdrachtgegevens en de verzamelde attributen en vraagt Ineke of de reservering definitief gemaakt moet worden
- Ineke bevestigt de reservering
- Het systeem keert terug naar het invoerscherm met de aanwezige attributen
Pakbon maken
- Saskia wil een pakbon voor te verzenden attributen maken. Zij opent het systeem en navigeert naar 'Opdrachtenoverzicht'
- Het systeem toont een overzicht van de geplande opdrachten met de eerst volgende opdracht bovenaan
- Saskia selecteert de bovenste opdracht
- Het systeem toont de details van de opdracht inclusief de te gebruiken attributen en een mogelijkheid om een pakbon af te drukken of te emailen
- Saskia controleert de zending en kiest ervoor de pakbon af te drukken
- Het systeem genereert de pakbon en stuurt informatie naar een printer
Aanvraag opdracht
- Henk de Vries van het bedrijf Getronics belt naar Close Act om een aanvraag voor de act "White Wings" op 17 juni 2011 te doen
- Niels klikt in het systeem op "aanvraag opdracht"
- Niels geeft vervolgens de datum 17-06-2011 als begin én einddatum op
- Niels selecteert vervolgens de act "White Wings"
- Het systeem presenteert vervolgens de mogelijkheden en opties zoals hoeveelheid spelers (3 of 6)
- Niels zoekt in het systeem op bedrijf Getronics, dit is het geval waardoor Niels verder kan gaan met de aanvraag
- Niels klikt vervolgens op "aanvraag act"
- Het systeem presenteert een scherm waarin Niels de hoeveelheid spelers moet invullen, de gewenste kostuums (hierbij worden al suggesties gedaan)
- Niels selecteert het bedrijf Getronics en vult in dat Henk de Vries bij deze act de contactpersoon en bereikbaar is op henkdevries@getronics.com
- Niels kiest er vervolgens voor om de ingevulde gegevens op te slaan.
- Het systeem vraagt om een offerte te printen
- Niels klikt op "offerte printen", waarna de offerte geprint wordt en opgestuurd kan worden
Aanvraag opdracht
- Frits van Hekkestijn van het bedrijf Microsoft belt naar Close Act om een aanvraag voor de act "Saurus" op 24 juli 2011 te doen
- Jasper klikt in het systeem op "aanvraag opdracht"
- Jasper geeft vervolgens de datum 24-07-2011 begint en eindigt op 25-07-2011
- Jasper selecteert vervolgens de act "Saurus"
- Het systeem presenteert vervolgens de mogelijkheden en opties zoals hoeveelheid spelers (6 of 9)
- Jasper zoekt in het systeem op bedrijf Microsoft, dit bedrijf is nog niet aanwezig waardoor hij deze eerst moet invoeren
- Jasper klikt op het tabblad "bedrijf invoeren"
- Jasper vult de bedrijfsnaam Microsoft in, het adres "Evert van de Beekstraat 354, 1118CZ te Schiphol".
- Jasper klikt op opslaan en sluit het tabblad
- Jasper klikt vervolgens op "aanvraag act"
- Het systeem presenteert een scherm waarin Jasper de hoeveelheid spelers (6) moet invullen, de gewenste kostuums (hierbij worden al suggesties gedaan)
- Jasper selecteert het bedrijf Microsoft en vult in dat Frits van Hekkestijn bij deze act de contactpersoon is en bereikbaar is op FritsvanHekkestijn@microsoft.nl
- Jasper kiest er vervolgens voor om de ingevulde gegevens op te slaan.
Aanvraag opdracht
- Koen opent het overzicht van geplande act
- Koen selecteert de act "Aliens"
- Het systeem presenteert een overzicht van al dan niet ingeplande spelers.
- Het systeem geeft vervolgens aan hoeveel spelers nog benodigd zijn
- Het systeem geeft de mogelijkheid om spelers te presenteren (hierbij wordt rekening gehouden met de act en datum van de act en de beschikbaarheid van spelers)
- Koen selecteert de benodigde 3 spelers: Joost, Bruno en Harm
- Koen kiest ervoor om de gegevens op te slaan
- Het systeem stuurt een e-mail naar Joost, Bruno en Harm dat zij zijn ingepland voor de act "Aliens" op 24 juli 2011 om 15:00
Business rule catalogue
- Elke speler ontvangt een unieke login voor het systeem wanneer hij/zij een contract tekent bij CloseAct.
- Een speler kan maximaal tot een week voor een bepaalde datum de beschikbaarheid van die datum nog aanpassen.
- Als er al een opdracht staat op een dag dat een speler vrij wil, kan de beschikbaarheid voor die datum niet worden veranderd.
- Als een speler toch vrij wil of moet op die dag, moet hij zelf voor vervanging zorgen of contact opnemen met het kantoor om iets te regelen.
- Elke speler ontvangt een unieke login voor het systeem wanneer hij/zij een contract tekent bij CloseAct.
- Elke speler kan ingepland worden zolang hij/zij niet heeft aangegeven niet te kunnen.
- Een ingevoerde, maar niet definitieve act, wordt ook als act gezien tijdens het plannen van een nieuwe act.
- Attributen dienen 1 dag van tevoren op locatie te zijn.
- Attributen dienen uiterlijk 1 week voordat ze gebruikt worden bij een act gereserveerd te zijn.
- Attributen kunnen alleen gereserveerd en naar locatie van de act verzonden worden indien de bijbehorende opdracht status "definitief" heeft
- Alleen gereserveerde attributen mogen voor een opdracht verplaatst worden naar een opdracht locatie
- De opdrachtgever verplicht zich tot een aanbetaling van 10% een maand voor de datum van uitvoering van de act.
- Bij annulering/contractbreuk wordt de aanbetaling niet geretourneerd maar gezien als onkostenvergoeding.
Integrated domain model
Integrated UC diagram
Non-functional Requirements
- Het systeem moet tijdens werkuren toegankelijk zijn voor zowel de mensen op kantoor als spelers thuis. Downtime van maximaal 1%.
- Het systeem moet snel genoeg zijn om tijdens een telefoongesprek dingen te wijzigen, zonder dat men daar lang op moet wachten.
Terminological Definitions
| Term: | Omschrijving/betekenis: |
|---|---|
| Act/voorstelling | Dit is een voorstelling of loopact welke CloseAct bij de klant gaat spelen. |
| Opdracht | Dit is een opdracht van een klant voor de firma CloseAct. Dit kan een mobiele voorstelling oftewel een loopact zijn, maar ook een vaste voorstelling op een podium. |
| Status | Het betreft hier de status van een opdracht, dit kan (achtereenvolgens) zijn: optie, contract of definitief. Deze termen staan in dit hoofdstuk beschreven. |
| Optie | Als een opdracht de status optie heeft wil dit zeggen dat er een offerte naar een klant is gestuurd. |
| Contract | Als een opdracht de status contract heeft wil dit zeggen dat er een contract naar een klant is gestuurd. |
| Definitief | Als een opdracht de status definitief heeft wil dit zeggen dat het contract door de klant ondertekend is. |
| Lopende opdracht | Een lopende opdracht is een opdracht waarvoor de speeldatum nog niet verstreken is. |
| Adres | De locatie waar de klant zich bevindt. |
| Email adres | Het email adres van de contactpersoon. |
| Klant | Het bedrijf dat een act wil boeken bij CloseAct. |
| Contactpersoon | Het aanspreekpunt bij een klant. |
| Telefoonnummer | Het telefoonnummer van de contactpersoon. |
| Beschikbaarheid | Geeft aan of een speler op een bepaalde datum beschikbaar is. |
| Datum | Een dag in het jaar in de vorm dd-mm-jjjj. Wordt op verschillende plaatsen in het systeem gebruikt |
| Speler | Identificatie van een speler die werkzaam is voor CloseAct |
| Attribuut | Een attribuut is een voorwerp wat nodig is om een act/voorstelling uit te voeren. |
| Kostuum | Is een specifiek attribuut; een kledingstuk voor een speler. |
| Locatie | De plaats waar een attribuut zich bevind op een specifieke tijd. |
| Unieke Login | Een unieke identificatie van een speler. |
