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

# [[Categorie:ACCESS Jeroen Bakker]] [[Categorie:ACCESS Harm de Wit]] [[Categorie:ACCESS Sjoerd van Oostenbrugge]] [[Categorie:ACCESS Laurens van Dijk]]

== Discussie ==

17-06 Harm

''Jeroen: Use case beheren agenda en beheren opties zijn hetzelfde? Beheren agenda kan er dus uit denk ik, of iig in de huidige vorm.''

Ik denk dat de agenda wel iets verschillends is. Naar mijn mening zou het eerder een lap tekst zijn met zoiets als 8:00 Vertrek, 10:00 Lunch, 12:00 Optreden... etc. Deze agenda moet gedeeld kunnen worden met de spelers die verbonden zijn aan de opdracht wanneer de opdracht definitief is. De agenda is wel onderdeel van een opdracht, dus misschien sub-use case van optie beheren van maken?

Wat is trouwens het verschil tussen optie, opdracht en productie (zie integrated domain model)? Is het niet eenvoudiger om alles productie/opdracht te noemen het het een status te geven van definitief ja/nee?

''Jeroen: De hoofdstukken goals en result. Wie heeft deze toegevoegd en met welke reden? Niels heeft hier vraagtekens bijgezet omdat ze niet voorkomen volgens de hoofdstukken uit de template die we moesten gebruiken(zie ook discussie)''

Ik heb deze onderdelen toegevoegd en ik heb hier al eerder wat over gezegd op de discussiepagina. Ik heb deze onderdelen toegevoegd omdat deze direct aansluiten op de problem statement in de zin van: wat is er mis > wat moet er verbeterd worden > hoe wordt dit gerealiseerd.

Het onderdeel goals is volgens mij hetzelfde als de non-functional requirements, volgens mij is het wel logisch dat het op deze plek staat maar misschien beter samen te voegen en te hernoemen naar nonfunctionals.

Het onderdeel result zie ik als een inventarisatie van het op te brengen product. Het biedt wat houvast als inleiding op de verschillende onderdelen van het uiteindelijk te maken product en is niet echt vanuit een bepaald oogpunt beschreven (vanuit data (datamodel), workflow gebruikers(usecases) of vormgeving van de schermen). Het is niet een perfecte beschrijving van het uiteindelijke resultaat, de use cases zijn hier veel beter voor. Misschien hier over discussieren of het erin moet blijven of weg mag.


17-06 JB

Wat is het verschil tussen beheren opties en beheren agenda? Deze UC zijn volgenmij eigenlijk hetzelfde? Hier moeten we dus even iets mee doen

15-06 JB

Wie heeft het hoofdstuk goals erin gezet? Niels heeft hierbij een vraagteken gezet omdat het ook niet in het stramien staat zoals gegeven door Stijn. Dus ik stel voor die eruit te gooien ofwel onder te brengen bij een ander hoofdstuk als het daar van toepassing is. Hetzelfde geldt voor het hoofdstuk result.

07-06 HdW

Ik heb [http://cl.ly/0G360U3x2z2Y3v3s2F2G het commentaar] van Niels gelezen:

* Het onderdeel goals is volgens mij hetzelfde als de non-functional requirements, volgens mij is het wel logisch dat het op deze plek staat maar misschien beter samen te voegen en te hernoemen naar nonfunctionals.
* Het onderdeel result zie ik als een inventarisatie van het op te brengen product. Het biedt wat houvast als inleiding op de verschillende onderdelen van het uiteindelijk te maken product en is niet echt vanuit een bepaald oogpunt beschreven (vanuit data (datamodel), workflow gebruikers(usecases) of vormgeving van de schermen). Het is niet een perfecte beschrijving van het uiteindelijke resultaat, de use cases zijn hier veel beter voor. Misschien hier over discussieren of het erin moet blijven of weg mag.
* Bij de use cases is telkens er vanuit gegaan dat alles binnen het systeem gebeurt, maar we moeten ook andere workflows toevoegen. Niels geeft bijvoorbeeld aan dat iemand kan bellen om de beschikbaarheid te wijzigen.
* De rest lijkt me wel in orde alleen moet er nog veel meer gespecificeerd worden qua benodigde gegevens en de constraints.


24-05 SvO

Alles nog eens doorgenomen (ex usecases)
Vragen toegevoegd aan Discussiepagina

28-05  SvO

Voeg zo nog even het domeinmodel toe.

28-05 LvD

Ik zag dat 'afspraak' en 'voorstelling' bij mijn use-case ambigu zijn. Heeft iemand een second opinion voor mij over welke van de twee ik zal aanhouden?

SvO: Ja ik zie dat er nog wel meer onduidelijkheden inzitten, zo heet het bij mij weer een optreden. Probeer nu zoveel mogelijk dezelfde benamingen te gebruiken, in de 'focused' fase kunnen we het helemaal consistent maken. Voor nu had ik even voorstelling aangehouden.

LvD: Prima. Ik stel voor dat we binnenkort met z'n vieren rond een tafel gaan zitten om even door te nemen wat we tot nu toe hebben gedaan, en kijken of we eventuele inconsistenties eruit kunnen halen.

== Todo's ==

== Notities ==
-

== Drafts ==

=== Goals ===

Het nieuwe systeem zal moeten voldoen aan de volgende eisen:


'''Usability:''' 

De taken van de gebruikers moeten zo eenvoudig mogelijk te zijn uit te voeren. Dit zal moeten leiden tot eenvoudige adaptie van het nieuwe systeem van nieuwe én oude medewerkers. 


'''Verminderen menselijke afhankelijkheid:''' 

Momenteel zijn de kantoormedewerkers zelf de bron van alle informatie over voorstellingen, klanten, kostuums etc. Het nieuwe systeem zal ervoor moeten zorgen dat de stakeholders meer betrokkenen worden in dit proces.


'''Fouten vermijden:''' 

Mensen maken fouten. Het systeem kan er aan bijdragen om deze fouten te voorkomen. Door een goede usability en de implementatie van business rules, zal systeem moeten leiden tot minder fouten binnen Close-act.


'''Integratie:''' 

Het systeem moet een geheel worden waarin alle taken kunnen worden uitgevoerd. Dit zal leiden tot een vermindering van gedupliceerde data en een betere usability. Daarnaast kunnener meer fouten vermeden worden door business rules te implementeren tussen de verschillende systemen binnen Close-Act.


'''Tijdswinst:''' 

Al de bovenstaande doelstellingen zullen gezamelijk leiden tot een tijdwinst.


'''Transparantie:''' 

Het nieuwe systeem zal ervoor moeten zorgen dat de spelersplanning een hoge mate van transparantie krijgt. De spelers moeten duidelijk van elkaar zien wie wanneer en hoevaak werkt. Dit zal leiden tot een betere verstandshouding tussen de spelers.


=== Result ===

Om de bovenstaande doelstellingen te kunnen realiseren zullen de volgende resultaten opgeleverd worden. In dit rapport worden de requirements in de vorm van use cases, scenario's en use case diagrams gedetailleerder worden beschreven

Er zal een ''geïntegreerd systeem'' worden opgeleverd waarin alle onderdelen van de applicatie worden verwerkt. Alle huidige en mogelijk nieuwe organisatorische taken zullen hiermee kunnen worden uitgevoerd. Het geïntegreerde systeem zal minstens de volgende onderdelen gaan bevatten:

- Agenda
* Spelersplanner
* Spelersbeheer
* Optie/voorstelling beheer
* Kostuumbeheer
* Relatiebeheer


'''Agenda:''' 

Op de agenda staan alle gegevens voor een voorstelling. De kantoormedewerkers kunnen op een eenvoudige manier een agenda delen en aanpassen. De spelers kunnen de agenda bekijken om zo up-to-date blijven over de komende voorstellingen.


'''Spelersplanning:''' 

De opdrachtgever heeft aangegeven dat vooral de spelersplanning een punt van aandacht is. In de vernieuwde spelersplanning worden alle verschillende randvariabelen zoals kostuums, voorstellingen en artiesten gecombineerd tot een overzichtelijk en beheerbaar geheel. Kantoormedewerkers kunnen alle informatie van deze randvariabelen eenvoudig beheren en bekijken. Door de volledige integratie zal het mogelijk zijn om automatische regels toe te passen tussen de verschillende variabelen. Als laatste zal het ook voor de spelers zelf mogelijk zijn om hun beschikbaarheid aan te geven.


'''Spelersbeheer:''' 

Er kan worden bijgehouden welke spelers onderdeel zijn van Close-Act en welke rollen en kostuums zij kunnen uitvoeren.


'''Optie/Voorstellingsbeheer:''' 

In het systeem kunnen opties worden geplaatst voor mogelijke voorstellingen. Deze opties worden door de kantoormedewerkers onderzocht en kunnen leiden tot voorstellingen. In het optiebeheer worden de besprekingen rond deze opties bijgehouden.


'''Kostuumbeheer:''' 

Kantoormedewerkers kunnen de verschillende kleine en grote kostuums beheren. Deze kostuums kunnen vervolgens worden toegeschreven aan een speler in de spelersplanner.


'''Relatiebeheer:''''

Als laatste concrete onderdeel wordt er een relatiebeheer verwerkt in de applicatie.Medewerkers kunnen hiermee de contactgegevens opzoeken en beheren.

In het gehele systeem zullen de bestaande business rules verwerkt worden. Dit houdt in dat alle onderdelen van het systeem naar elkaar kunnen verwijzen en restrictieve regels kunnen bevatten. Hierdoor is er een vermindering van fouten, duplicatie en wordt de usability verbeterd.


'''Rechten binnen het systeem'''

Het systeem zal een rechtensysteem implementeren. Dit houdt in dat de kantoormedewerkers de meeste taken mogen uitvoeren terwijl de artiesten zich vooral zullen bezighouden met de het aangeven van de beschikbaarheid. we
Mogelijk zullen de andere stakeholders in de toekomst onderscheidende rechten krijgen.