You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 158 Next »



Introductie

Algemene beschrijving

Dit document beschrijft de ontwerpspecificaties voor een indelingsprogramma voor Schaakvereniging UVS. Het doel van dit programma is om alles van een schaakseizoen te beheren. In een schaakseizoen kunnen verschillende competitie gehouden worden, deze competities in een seizoen staan niet vast. Per competitie zijn er rondes die moeten worden ingedeeld. Deze rondes hebben meerdere spelers waarvan de resultaten ook moeten worden verwerkt tot een ranglijst na elke ronde. Deze gegevens moeten ook worden geüpload naar de WordPress-website van Schaakvereniging UVS.

Userstories

Algemeen

US1: Als wedstrijdleider wil ik leden en gasten kunnen invoeren, updaten en verwijderen in het systeem, zodat ik ze daarna kan toevoegen aan competities.
US2: Als wedstrijdleider wil ik dat de ronde indeling uitgeprint kan worden, zodat de witspelers hierop de resultaten kunnen invullen.
US3: Als wedstrijdleider wil ik dat oude seizoenen kunnen worden bekeken, zodat deze informatie kan worden gebruikt voor statistieken.
US4: Als wedstrijdleider wil ik dat er per lid en gast een spelershistorie wordt bijgehouden.
US5: Als wedstrijdleider wil ik de historie van spelers kunnen inzien zodat oude resultaten altijd beschikbaar blijven.

Competities

US5: Als wedstrijdleider wil ik de mogelijkheid hebben om competities te beheren, zodat ik ze actueel kan houden.
US6: Als wedstrijdleider wil ik leden en gasten kunnen toevoegen aan een competitie, zodat zij kunnen gaan schaken.
US7: Als wedstrijdleider wil ik een competitie een type als periodecompetitie, meerkamp en toernooi kunnen geven , zodat deze het juiste aantal rondes kan krijgen.
US8: Als wedstrijdleider wil ik spelers kunnen indelen in verschillende categorieën of groepen binnen een competitie, zodat de competitie eerlijk en gebalanceerd is.
US9: Als wedstrijdleider wil ik het indeling van een toernooi kunnen genereren, zodat deelnemers hun indeling kunnen bekijken.
US10: Als wedstrijdleider wil ik dat alle informatie die bij een competitie hoort, op de website van de vereniging gepubliceerd kan worden, zodat actuele informatie beschikbaar is.
US11: Als wedstrijdleider wil ik het resultaat van een ronde eenvoudig kunnen invoeren, zodat deelnemers de resultaten kunnen zien.
US12: Als wedstrijdleider wil ik dat de applicatie automatisch de ranglijst bijwerkt nadat een ronde alle resultaten heeft, zodat de ranglijst up-to-date blijft.
US13: Als wedstrijdleider wil ik dat de applicatie automatisch de ratings van de spelers bijwerkt volgens de ratingformule, nadat een ronde alle resultaten heeft.
US14: Als Externe wedstrijdleider wil ik dat de resultaten van externe competities bijgehouden kunnen worden, zodat de rating van spelers altijd up-to-date kan zijn. 
US15: Als wedstrijdleider wil ik de globale ranglijst kunnen bekijken zodat duidelijk is hoe goed de leden het doen.
US16: Als wedstrijdleider wil ik de ranglijst van een competitie kunnen bekijken zodat duidelijk is hoe goed de leden het doen.

User Classes and Karakteristieken

Binnen het indelingsprogramma zijn er twee gebruikers: de interne wedstrijdleider en de externe wedstrijdleider van de schaakvereniging. Deze gebruikers krijgen toegang tot het programma door in te loggen met hun eigen gegevens. Ze kunnen alles doen wat het programma zou moeten kunnen. Ze gebruiken het systeem om seizoenen, competities, leden en gasten te beheren.

Operatieomgeving

Het indelingsprogramma zal worden geprogrammeerd in Java en zal moeten werken op de ondersteunde versies van Windows en MacOS besturingssystemen. Er is een bestaande testdatabase waarop de nieuwe database gebaseerd kan worden, maar het zou ook handig zijn als het met een andere database kan werken. Daarom wordt er gebruik gemaakt van de Java Persistence API (JPA), waardoor het relatief eenvoudig wordt om een andere database aan het programma te koppelen.

Design- en Implementatiebeperkingen

Voor dit project zijn er weinig dingen die ons in de weg zullen zitten tijdens het werken. Het enige dat bekend is momenteel is dat de schaakvereniging geen budget heeft vrijgemaakt voor het hosten van een externe database waardoor wij de database lokaal moeten gaan ontwerpen.

 

Product functionaliteiten

De hoofdfunctionaliteiten van het indelingsprogramma zijn als volgt: de gebruiker moet een seizoen kunnen aanmaken, zodat er een competitie kan worden opgezet. Binnen deze competities zijn er speelrondes die moeten worden ingedeeld in speelparen. Het aantal speelrondes verschilt per competitietype. Nadat deze speelrondes zijn gespeeld, moeten de resultaten worden ingevuld en worden deze gebruikt om ranglijsten te genereren voor de specifieke rondes. Na afloop van een wedstrijd zal ook de rating van de spelers worden aangepast. Aan het einde van een speelronde zullen de resultaten worden geüpload naar de website van UVS.


ActorUse CaseBrief description
WedstrijdleiderBeheren spelersDe wedstrijdleider moet de mogelijkheid hebben om nieuwe leden en gasten in het systeem in te voeren, zodat ze later kunnen worden toegevoegd aan competities.
WedstrijdleiderStartrating vastleggen
De wedstrijdleider wil aan het begin van het seizoen de startrating van elke speler vastleggen, zodat hier na het seizoen mee vergeleken kan worden.
WedstrijdleiderPrinten ronde indelingDe wedstrijdleider moet de indeling van een ronde moeten kunnen uitprinten zodat de leden op locatie de indeling kunnen zien.
WedstrijdleiderSeizoenen bekijkenDe wedstrijdleider wil oude seizoenen kunnen bekijken zodat de historie van de club altijd bekeken kan worden.
WedstrijdleiderBeheren van competitiesDe wedstrijdleider wil de mogelijkheid hebben om competities te beheren, zodat deze actueel blijven.
WedstrijdleiderBeheren van competitiegroepenDe wedstrijdleider moet groepen kunnen toevoegen aan een competitie, zodat er daarna spelers kunnen worden toegevoegd.
WedstrijdleiderBeheren van spelers in competitiegroepDe wedstrijdleider moet in staat zijn om leden en gasten toe te voegen aan een competitiegroep, zodat zij ingedeeld en kunnen deelnemen aan de schaakwedstrijden.
WedstrijdleiderGegevens publiceren op websiteDe wedstrijdleider wil de ronde indeling, uitslagen en de ranglijst op de website publiceren zodat elk persoon online de gegevens kan bekijken.
WedstrijdleiderRonde resultaten invoerenDe wedstrijdleider wil resultaten van ronden kunnen invoeren zodat de ranglijst anders wordt.
WedstrijdleiderIndeling genereren voor competitieDe wedstrijdleider wil automatisch door het systeem een indeling voor de rondes van competities laten genereren.
WedstrijdleiderGlobale ranglijst bekijkenDe wedstrijdleider wil de globale ranglijst bekijken zodat duidelijk is wie het beste is.
WedstrijdleiderGroep ranglijst bekijkenDe wedstrijdleider wil de ranglijst van een groep bekijken zodat duidelijk is wie het beste is.
Extern wedstrijdleiderResultaat externe ronde invoerenDe externe wedstrijdleider wil het resultaat van een externe ronde invoeren zodat de rating van het lid aanpast

Usecasediagram

Domein Model

Speler

Spelers in het systeem kunnen altijd een rating hebben. Als de speler een interne speler zijn hebben ze ook een naam, als ze dit niet zijn wordt de naam van de speler niet bijgehouden. Deze interne spelers kunnen vervolgens ook leden en gasten zijn. Spelers kunnen deel uitmaken van groepen binnen competities, kunnen meedoen aan matches en hun rating wordt bijgehouden op de globale leaderboard.

Competities

Competities hebben een naam, een startdatum, een maximum aantal ronden en een maximaal aantal keren dat een speler dezelfde kleur kan spelen. Een competitie kan een toernooi, een periodecompetitie of een meerkamp competitie zijn. Meerkamp competities houden bij of ze enkel of dubbele rondes hebben met hun "rondetype" attribuut. Een periodecompetitie houdt ook de periode bij, zodat er bij de indeling gekeken kan worden naar wat de winnaars van de vorige competitie was. Een toernooi heeft maar een competitie, maar heeft bij die competities settings om mee te nemen voor de puntentelling.

Groep

Een groep is een verzameling van spelers die meedoen aan een competitie. De groep van spelers spelen tegen elkaar in meerdere rondes, en de resultaten van al deze rondes worden opgeslagen in verschillende soorten ranglijsten en tabellen. 

Ronde

In een ronde spelen de spelers die in de groep zitten die de ronde speelt tegen elkaar spelen. Hierbij hoort een schemalijst die voor de matches geprint kan worden, en een resultatenlijst die na de ronde ingevult wordt. De matches die de spelers tegen elkaar spelen hebben allemaal een resultaat. Of wit wint, of zwart wint, of er is een padstelling, of er is een uitzondering. De resultaten die hier uitkomen zijn weer terug te zien in de tabellen en ranglijsten van groep, en de globale ranking. Ook de rating van een speler kan door matches omhoog en omlaag gaan.

Use-casebeschrijvingen

Beheren spelers

UC 1.1: Spelers bekijken

Primary actor: Wedstrijdleider

Stakeholders and Interests:

De voorzitter, omdat hij goed geïnformeerd wil zijn over wie de leden zijn en hoeveel leden er in totaal zijn.
De penningmeester, omdat veranderingen in het ledenaantal gevolgen kunnen voor het budget van de vereniging.
De secretaris, omdat hij de persoonsgegevens moet bijhouden van de actieve leden en dan is een digitale lijst erg handig.

Brief description:

De wedstrijdleiders willen de spelers kunnen bekijken zodat ze weten wie er in het systeem staat.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft het hoofdscherm open. 

Postconditions (Success Guarantee): De wedstrijdleider ziet alle bekende spelers.

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de spelerslijst te willen zien.


2. Systeem toont voornaam, achternaam, rating en type van de bekende spelers.

3. Systeem toont invulvelden voor de voornaam, achternaam, rating en type van de speler. 


UC 1.2: Spelers toevoegen

Primary actor: Wedstrijdleider

Stakeholders and Interests:

De voorzitter, omdat hij wil dat de leden goed kunnen worden ingedeeld d.m.v. het indelingsprogramma.
De penningmeester, omdat veranderingen in het ledenaantal gevolgen kunnen voor het budget van de vereniging.
De secretaris, omdat hij de persoonsgegevens moet bijhouden van de actieve leden en dan is het handig als de digitale lijst actueel is.

Brief description:

De wedstrijdleiders willen leden en gasten registreren binnen het systeem zodat zij ingedeeld kunnen worden binnen competities en toernooien

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft het hoofdscherm open. 

Postconditions (Success Guarantee): De wedstrijdleider heeft een nieuwe speler geregistreerd. 

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de spelerslijst te willen zien.



4. De wedstrijdleider vult de voornaam, achternaam, rating en type van de nieuwe speler in.



2. Systeem toont voornaam, achternaam, rating en type van de bekende spelers.

3. Systeem toont invulvelden voor de voornaam, achternaam, rating en type van de speler. 


5. Systeem registreert de nieuwe Speler.


UC 1.3: Spelers verwijderen

Primary actor: Wedstrijdleider

Stakeholders and Interests:

De voorzitter, omdat hij wil dat de leden goed kunnen worden ingedeeld d.m.v. het indelingsprogramma.
De penningmeester, omdat inactieve of niet betalende spelers een negatieve invloed hebben op het verwachte budget.
De secretaris, omdat er met inactieve spelers geen accurate toernooiplanning gemaakt kan worden

Brief description:

De wedstrijdleiders willen spelers kunnen verwijderen omdat zij niet meer actief zijn bij de vereniging.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft het hoofdscherm open. 

Postconditions (Success Guarantee): De wedstrijdleider heeft een speler verwijderd. 

Main Success Scenario (Basic Flow): 

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de spelerslijst te willen zien.


4. De wedstrijdleider geeft aan een speler te willen verwijderen.


6. De wedstrijdleider bevestigt de keuze  .

 
2. Systeem toont voornaam, achternaam, rating en type van de bekende spelers

3. Systeem toont invulvelden voor de voornaam, achternaam, rating en type van de speler. 


5. Systeem vraagt of de gebruiker het zeker weet.


7. [keuze = ja] Systeem verwijdert de gekozen speler.

Extensions (Alternative Flow): Keuze is nee.


 

7a Speler wordt niet verwijdert.
Usecase verwijderen stopt.


UC 1.4: Spelers bewerken

Primary actor: Wedstrijdleider

Stakeholders and Interests:

De voorzitter, omdat hij wil dat de gegevens van de leden correct in het systeem staan zodat er geen misverstanden kunnen ontstaan..
De secretaris, omdat incorrecte persoonsgegevens van de leden niet goed is voor de communicatie tussen de vereniging en de leden. 

Brief description:

De wedstrijdleiders willen leden en gasten kunnen bewerken omdat de gegevens van de speler anders is.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft het hoofdscherm open. 

Postconditions (Success Guarantee): De wedstrijdleider heeft de gegevens van een speler aangepast.

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de spelerslijst te willen zien.



4. De wedstrijdleider geeft aan een speler te willen bewerken.


6. De wedstrijdleider past de gegevens aan en geeft aan te willen opslaan.


2. Systeem toont voornaam, achternaam, rating en type van de bekende spelers

3. Systeem toont invulvelden voor de voornaam, achternaam, rating en type van de speler. 


5. Systeem toont de voornaam, achternaam, type en de rating van de speler. 


7. Systeem slaat de nieuwe gegevens op.

System Sequence Diagram 

Omdat deze vier usecases allemaal CRUD zijn is er voor gekozen om alleen het aanmaken van een speler uit te werken in een system sequence diagram. De wedstrijdleider vraagt als eerste alle spelers en de invulvelden op, het systeem laat deze vervolgens zien in een tabel. Daarna vult de wedstrijdleider de velden in en maakt een nieuwe speler aan.

Beheren van competities

Use Case 2.1: Competitie aanmaken

Primary actor: Wedstrijdleider

Stakeholders and Interests:

De voorzitter, omdat activiteiten als competities nieuwe mensen aantrekken om bij de vereniging te betrekken.
De penningmeester, omdat activiteiten soms financiële aspecten hebben, zoals inschrijfgeld of prijsgeld.
De secretaris, omdat hij verantwoordelijk is voor het administratieve werk rondom de competities. 

Brief description:

De wedstrijdleider moet een nieuwe competitie kunnen aanmaken, zodat deze kan worden ingezet voor het organiseren van schaakwedstrijden.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft het hoofdscherm open.

Postconditions (Success Guarantee): De wedstrijdleider heeft een nieuwe competitie aangemaakt.

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de competities te willen zien.


3. De wedstrijdleider geeft aan een competitie te willen toevoegen.


5. De wedstrijdleider vult de gegevens in voor de competitie.


2. Systeem toont de naam, competitie type en aantal spelers van de bestaande competities.

4. Systeem toont invulvelden voor de naam, soort competitie, aantal rondes, aantal keer dezelfde kleur, aantal punten voor winst, verlies, remise, oneven en vrijgesteld.


6. Systeem maakt een nieuwe competitie aan.


Use Case 2.2: Competities bekijken

Primary actor: Wedstrijdleider

Stakeholders and Interests:

Spelers, omdat zij met een duidelijk overzicht gemakkelijk kunnen zien welke competities er zijn voor een inschrijving.
Sponsoren, omdat zij met een overzicht gemakkelijk kunnen zien welke activiteit wanneer is. Hiermee kunnen ze mogelijk reclame maken voor de activiteit zoals flyers.
Voorzitters, omdat hij wilt weten welke competities relevant zijn voor de leden.

Brief description:

De wedstrijdleider wilt de competities kunnen bekijken zodat hij alle competities in een ogenblik kan zien.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft het hoofdscherm open.

Postconditions (Success Guarantee): De wedstrijdleider heeft een nieuwe competitie aangemaakt.

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de competities te willen zien.


2. Systeem toont de naam, competitie type en aantal spelers van de bestaande competities.


Use Case 2.3: Competitie bewerken

Primary actor: Wedstrijdleider

Stakeholders and Interests:

Secretaris, omdat zij actuele informatie willen over de competities zodat er geen misverstanden ontstaan.
Voorzitters, omdat hij wilt weten welke competities relevant zijn voor de leden.
Penningmeester, omdat met veranderingen aan de competitie het inschrijfgeld of prijzengeld mogelijk kan veranderen.

Brief description:

De wedstrijdleider moet een nieuwe competitie kunnen aanmaken, zodat deze kan worden ingezet voor het organiseren van schaakwedstrijden.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft het hoofdscherm open.

Postconditions (Success Guarantee): De wedstrijdleider heeft een competitie bijgewerkt.

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de competities te willen zien.

3. De wedstrijdleider geeft aan een competitie te willen bewerken.

5. De wedstrijdleider vult de bewerkte gegevens van de competitie in.


2. Systeem toont de naam, competitie type en aantal spelers van de bestaande competities.

4. Systeem toont invulvelden voor de naam, soort competitie, aantal rondes, aantal keer dezelfde kleur, aantal punten voor winst, verlies, remise, oneven en vrijgesteld.

6. Systeem bewerkt de competitie met de nieuwe gegevens.


Use Case 2.4: Competitie verwijderen

Primary actor: Wedstrijdleider

Stakeholders and Interests:

Secretaris, omdat zij geen inactieve of incorrecte informatie over de competities willen zodat er geen onduidelijkheden komen.
Voorzitters, omdat hij wilt dat de oude informatie weggehaald wordt zodat er focus kan gelegd worden op nieuwe competities.

Brief description:

De wedstrijdleider moet een competitie kunnen verwijderen als deze niet meer nodig zijn binnen het systeem.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft het hoofdscherm open.

Postconditions (Success Guarantee): De wedstrijdleider heeft een nieuwe competitie aangemaakt.

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de competities te willen zien.


3. De wedstrijdleider geeft aan een competitie te willen verwijderen.


7. De wedstrijdleider bevestigt de keuze.


2. Systeem toont de naam, competitie type en aantal spelers van de bestaande competities.


4. Systeem vraagt of de gebruiker het zeker weet.


6. [keuze = ja] Systeem verwijderd de gekozen competitie.

Extensions (Alternative Flow): Keuze is nee.



6a Competitie wordt niet verwijdert.
Usecase verwijderen stopt.


System Sequence Diagram 

Omdat deze vier usecases allemaal CRUD zijn is er voor gekozen om alleen het aanmaken van een speler uit te werken in een system sequence diagram, zodat toch duidelijk is hoe het werkt. De wedstrijdleider wil een nieuwe competitie aanmaken, daarom wordt de createCompetition functie aangeroepen.

Beheren van competitiegroepen

Use Case 3.1: Competitiegroepen bekijken

Primary actor: Wedstrijdleider

Stakeholders and Interests:

De voorzitter, omdat hij goed geïnformeerd wil zijn over de competitiegroepen. 

De secretaris, omdat hij verantwoordelijk is voor het administratieve werk rondom de competities. 

Brief description:

De wedstrijdleiders willen de competitiegroepen kunnen bekijken zodat ze weten welke er in het systeem staan.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft de competities open. 

Postconditions (Success Guarantee): De wedstrijdleider ziet alle competitiegroepen van de gekozen competitie.

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de competitiegroepen te willen zien van de gekozen competitie.


2. Systeem toont de groepsletters en de spelers van de bestaande groepen van de gekozen competitie. 


Use Case 3.2: Competitiegroep aanmaken

Primary actor: Wedstrijdleider

Stakeholders and Interests:

De wedstrijdleiders willen de competitiegroepen kunnen bekijken zodat ze weten welke er in het systeem staan.
De secretaris, omdat hij verantwoordelijk is voor het administratieve werk rondom de competities. 

Brief description:

De wedstrijdleider moet een nieuwe competitiegroep kunnen aanmaken, zodat er spelers aan toegevoegd kunnen worden en zo aan de competitie toegevoegd kunnen worden.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft de competities open.

Postconditions (Success Guarantee): De wedstrijdleider heeft een nieuwe competitiegroep aangemaakt bij een competitie.

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de competitiegroepen te willen zien van de gekozen competitie


3. De wedstrijdleider geeft aan een competitiegroep te willen toevoegen.


5. De wedstrijdleider vult de groepsletter in voor de competitiegroep.


2. Systeem toont de groepsletter en de spelers van de bestaande competitiegroepen van de gekozen competitie.


4. Systeem toont invulvelden voor de groepsletter. 


6. Systeem maakt een nieuwe competitiegroep aan.


Use Case 3.3: Competitiegroep bewerken

Primary actor: Wedstrijdleider

Stakeholders and Interests:

Secretaris, omdat zij actuele informatie willen over de competities zodat er geen misverstanden ontstaan.
Voorzitters, omdat hij wilt weten welke competities relevant zijn voor de leden.
Penningmeester, omdat met veranderingen aan de competitie het inschrijfgeld of prijzengeld mogelijk kan veranderen.

Brief description:

De wedstrijdleider moet een competitiegroep kunnen bewerken, zodat deze aangepast kan worden wanneer dat nodig is.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft de competities open.

Postconditions (Success Guarantee): De wedstrijdleider heeft een competitiegroep bijgewerkt van een competitie.

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de competitiegroepen te willen zien van de gekozen competitie

3. De wedstrijdleider geeft aan een competitiegroep te willen bewerken.

5. De wedstrijdleider vult de bewerkte groepsletter van de competitiegroep in.


2. Systeem toont de groepsletter en de spelers van de bestaande competitiegroepen van de gekozen competitie. 

4. Systeem toont een invulveld voor de groepsletter.

6. Systeem bewerkt de competitie met de nieuwe gegevens.


Use Case 3.4: Competitiegroep verwijderen

Primary actor: Wedstrijdleider

Stakeholders and Interests:

Secretaris, omdat zij geen inactieve of incorrecte informatie over de competities willen zodat er geen onduidelijkheden komen.
Voorzitters, omdat hij wilt dat de oude informatie weggehaald wordt zodat er focus kan gelegd worden op nieuwe competitiegroepen.

Brief description:

De wedstrijdleider moet een competitiegroep kunnen verwijderen als deze niet meer nodig is binnen het systeem.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft de competities open.

Postconditions (Success Guarantee): De wedstrijdleider heeft een competitiegroep verwijderd van een competitie

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de competitiegroepen te willen zien van de gekozen competitie


3. De wedstrijdleider geeft aan een competitiegroep te willen verwijderen.


5. De wedstrijdleider bevestigt de keuze.


2. Systeem toont de groepsletter en de spelers van de bestaande competitiegroepen van de gekozen competitie.


4. Systeem vraagt of de gebruiker het zeker weet.


6. [keuze = ja] Systeem verwijderd de gekozen competitiegroep.

Extensions (Alternative Flow): Keuze is nee.



6a Competitiegroep wordt niet verwijdert.
Usecase verwijderen stopt.

Beheren van spelers in competitiegroep

UC 4.1: Spelers van competitiegroep bekijken

Primary actor: Wedstrijdleider

Stakeholders and Interests:

De voorzitter, omdat hij wil dat de leden goed kunnen worden ingedeeld in de competities. 
De secretaris, omdat hij de persoonsgegevens moet bijhouden van de actieve leden en dan is het handig als de digitale lijst actueel is.

Brief description:

De wedstrijdleiders willen spelers in een competitiegroep bekijken zodat ze weten welke spelers in de groep zitten.

Preconditions:  De wedstrijdleider heeft KlukKluk geopend en heeft het competitiegroep scherm open. 

Postconditions (Success Guarantee): De spelers in de competitiegroepen zijn getoond.

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de competitiegroepen te willen zien van de gekozen competitie

3. De wedstrijdleider geeft aan de spelers in een groep te willen zien door een competitiegroep te selecteren.



2. Systeem toont alle groepen van de gekozen competitie


4. Systeem toont de beschikbare spelers die in de groep kunnen en de huidige spelers in de groep.

UC 4.2: Spelers toevoegen aan competitiegroep

Primary actor: Wedstrijdleider

Stakeholders and Interests:

De voorzitter, omdat hij wil dat de leden goed kunnen worden ingedeeld in de competities. 
De secretaris, omdat hij de persoonsgegevens moet bijhouden van de actieve leden en dan is het handig als de digitale lijst actueel is.

Brief description:

De wedstrijdleiders willen spelers toevoegen in een competitiegroep zodat deelnemers mee kunnen doen aan een competitie. 

Preconditions:  De wedstrijdleider heeft KlukKluk geopend en heeft het competitiegroep scherm open. 

Postconditions (Success Guarantee): Er zijn nieuwe spelers toegevoegd aan de gekozen competitiegroep.

Main Success Scenario (Basic Flow):

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de competitiegroepen te willen zien van de gekozen competitie

3. De wedstrijdleider geeft aan de spelers in een groep te willen zien door een groepsletter te selecteren.


5. De wedstrijdleider geeft aan welke speler hij wil toevoegen aan de competitiegroep.


2. Systeem toont alle groepen van de gekozen competitie


4. Systeem toont de beschikbare spelers die in de groep kunnen en de huidige spelers in de groep.


6. Systeem voegt de spelers toe aan de competitiegroep.


UC 4.3: Spelers verwijderen van een competitiegroep

Primary actor: Wedstrijdleider

Stakeholders and Interests:

De voorzitter, omdat hij wil dat de leden goed kunnen worden ingedeeld in een competitiegroep.
De penningmeester, omdat inactieve of niet betalende spelers een negatieve invloed hebben op het verwachte budget.
De secretaris, omdat er met inactieve spelers geen accurate toernooiplanning gemaakt kan worden

Brief description:

De wedstrijdleiders willen spelers kunnen verwijderen van een competitiegroep omdat zij niet meer actief zijn bij de competitie.

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft het competitiegroep scherm open. 

Postconditions (Success Guarantee): De gekozen spelers zijn verwijderd uit de gekozen competitiegroep.

Main Success Scenario (Basic Flow): 

Actor Action

System Responsibility

1. De wedstrijdleider geeft aan de competitiegroepen te willen zien van de gekozen competitie

3. De wedstrijdleider geeft aan de spelers in een groep te willen zien.


5. De wedstrijdleider geeft aan welke speler(s) hij wil verwijderen uit de competitiegroep.


2. Systeem toont alle groepen van de gekozen competitie

4. Systeem toont de beschikbare spelers die in de groep kunnen en de huidige spelers in de groep.


6. Systeem verwijderd de speler(s) uit de competitiegroep.


Vastleggen startrating

UC 5: Vastleggen startrating

Primary actor: Wedstrijdleider

Stakeholders and Interests:

Spelers: deze willen aan het einde van een seizoen hun voortgang kunnen vergelijken met het begin van het seizoen

Brief description:

De wedstrijdleider wil aan het begin van het seizoen de startrating van elke speler vastleggen, zodat hier na het seizoen mee vergeleken kan worden

Preconditions: De wedstrijdleider heeft KlukKluk geopend en heeft het hoofdscherm open.
Postconditions (Success Guarantee): Voor elke speler is een startrating vastgesteld in de database, en deze wordt afgebeeld binnen de applicatie
Main Success Scenario (Basic Flow):
Actor ActionSystem Responsibility

 1. De wedstrijdleider geeft aan de algemene spelerslijst te willen zien.


3. De wedstrijdleider drukt op de knop om startrating vast te stellen.


5. De wedstrijdleider bevestigt de startrating op te willen slaan.

 

2. Systeem toont voornaam, achternaam, rating en type van de bekende spelers.


4. Het systeem toont een pop-up ter bevestiging van het vaststellen van de startratings.


6. [Keuze = ja] Het systeem slaat de huidige ratings van de spelers op als de startrating van het nieuwe seizoen.

Extensions (Alternative Flow): Keuze is nee

 


 6a. Het systeem sluit de pop-up en de startrating wordt niet vastgelegd.

Ronde resultaten invoeren

UC 6: Ronde resultaten invoeren

Primary actor: Wedstrijdleider

Stakeholders and Interests:

Spelers: de spelers die deel hebben genomen aan een match willen dat hun rating up-to-date blijft.
Voorzitter: Als de wedstrijdresultaten correct worden ingevuld geeft dit een beter inzicht op de status van de huidige competities.

Brief description:

De wedstrijdleider voert het resultaat van een wedstrijd in voor de interne spelers. Hierna wordt de rating van de interne spelers aangepast.

Preconditions: De interne spelers zijn aanwezig in het systeem en ronde is al ingedeeld.
Postconditions (Success Guarantee): Het resultaat van de wedstrijden in de ronde is opgenomen in het systeem en de rating van de interne spelers zijn aangepast. 
Main Success Scenario (Basic Flow):
Actor ActionSystem Responsibility

1. De wedstrijdleider geeft aan dat hij de resultaten van een ronde wedstijden in wilt voeren.


3. De wedstrijdleider voert één voor één de resultaten in voor gespeelde wedstrijden.

 

2. Systeem geeft een lijst van gespeelde wedstrijden.


4. Het systeem berekent de nieuwe rating van de spelers, slaat de nieuwe rating en het resultaat van de wedstrijden binnen de ronde op, en toont de net ingevoerde ronde.


Resultaat externe ronde invoeren

UC 7: Resultaat externe ronde invoeren

Primary actor: Externe Wedstrijdleider

Stakeholders and Interests:

Spelers: de speler die deel heeft genomen aan een externe match wil dat zijn rating up-to-date blijft.

Brief description:

De externe wedstrijdleider voert het resultaat van een externe wedstrijd in voor een interne speler. Hierna wordt de rating van de interne speler aangepast.

Preconditions:

De interne speler is aanwezig in het systeem.

Een externe match heeft plaatsgevonden. 

Postconditions (Success Guarantee): Het resultaat van de externe wedstrijd is opgenomen in het systeem en de rating van de interne speler is aangepast. 
Main Success Scenario (Basic Flow):
Actor ActionSystem Responsibility

 1. De externe wedstrijdleider geeft aan dat hij het resultaat van een externe wedstrijd in wilt voeren


3. De externe wedstrijdleider geeft aan of de witspeler intern of extern was


5. De externe wedstrijdleider geeft de naam van de interne witspeler


7. De externe wedstrijdleider geeft de rating van de externe zwartspeler


9. De externe wedstrijdleider kiest de uitslag van de wedstrijd.


11. De externe wedstrijdleider bevestigt de input.

 

2. Het systeem vraagt of de speler die wit speelde intern of extern was


4. [witspeler is intern] Het systeem vraagt om de naam van de interne witspeler


6. Het systeem vraagt om de rating van de externe zwartspeler


8. Het systeem vraagt wat de uitslag van de wedstrijd was


10. Het systeem toont een popup ter bevestiging van het opslaan van het resultaat van de match. 


12. [wedstrijdleider bevestigt] Het systeem slaat het resultaat van de externe match met een interne witspeler en een externe zwartspeler op. De rating van de interne speler wordt geupdate. 

Extensions (Alternative Flow): De witspeler is extern

 

5a. De externe wedstrijdleider geeft de rating van de externe witspeler


7a. De externe wedstrijdleider geeft de naam van de interne zwartspeler


9a. De externe wedstrijdleider kiest de uitslag van de wedstrijd.


11a. De externe wedstrijdleider bevestigt de input.

4a. Het systeem vraagt om de rating van de externe witspeler


6a. Het systeem vraagt om de naam van de interne zwartspeler


8a. Het systeem vraagt wat de uitslag van de wedstrijd was


10a. Het systeem toont een popup ter bevestiging van het opslaan van het resultaat van de match. 


12a. [wedstrijdleider bevestigt] Het systeem slaat het resultaat van de externe match met een interne zwartspeler en een externe witspeler op. De rating van de interne speler wordt geupdate.  

De wedstrijdleider wijst de input af


10b. Het systeem bewaart tijdelijk de ingevoerde inputs en gaat terug naar stap 2

Indeling genereren voor competitie

Primary actor: Interne Wedstrijdleider

Stakeholders and Interests:

Spelers: spelers willen ingedeeld worden in een competitie zodat ze kunnen spelen.

Brief description:

De interne wedstrijdleider geeft aan een competitie indeling te willen genereren waarna het systeem een indeling genereert met de beschikbare spelers en groepen.

Preconditions:

Er zijn spelers in een competitie/groep ingedeeld.

Postconditions (Success Guarantee): Er is een indeling gegenereerd voor de competitie.
Main Success Scenario (Basic Flow):
Actor ActionSystem Responsibility

 1. De interne wedstrijdleider geeft aan dat hij een indeling voor een competitie wil laten genereren.

 

2. Het systeem kiest het juiste indeel systeem en maakt een indeling

Extensions (Alternative Flow): Er zijn geen spelers beschikbaar.

 

2a. Het systeem laat een foutmelding zien.

Andere functionele eisen (optional)

Code

Description

FR1

Het programma moet in staat zijn om op een gemakkelijke manier te schakelen tussen verschillende databases, zodat de gebruikers zonder veel moeite tussen verschillende databases kunnen schakelen.

FR2

Het programma moet in staat zijn om alle input die door de gebruiker wordt ingevoerd te valideren voordat hij deze door stuurt naar de database zodat er geen kwaadaardige query's naar de database worden gestuurd.

FR3

Het programma moet in staat zijn om te draaien op zowel Windows als MacOS zodat het zoveel mogelijk gebruikers kan ondersteunen door op de meest recente OS'en te kunnen draaien.

FR4

Het programma moet standalone worden kunnen gelanceerd zodat de gebruiker geen externe webhosting hoeft te onderhouden.

 

Non-functionele eisen 

De volgende non-functionele requirements zijn geschreven volgens FURPS.


Usability

Code

Description

NFR1

Een gebruiker moet de resultaten van een competitie in kunnen voeren zonder elk lid of resultaat aan te hoeven klikken.

NFR2

Een gebruiker moet met weinig klikken tot de functies kunnen komen.

NFR3

Een gebruiker moet de functies kunnen gebruiken met zo min mogelijk pop-up windows.

Reliability

Code

Description

NFR1


Performance

Code

Description

NFR2

Alle schermen moeten binnen minimaal 2 seconden laden

Security

Code

Description

NFR2

SQL-injecties moeten voorkomen worden door prepared statements.

User interface schetsen

Wireframe spelers

In de wireframe is te zien hoe de menubalk er ongeveer uit gaat zien, met links een knop voor de homepage en daarnaast een poppetje van een speler waarna je op het spelers scherm komt. Op het spelers scherm is een tabel te zien van alle spelers die in het systeem zijn opgeslagen. Boven de tabel staan een aantal velden om een nieuwe speler te kunnen toevoegen. Als op de bewerken knop gedrukt wordt veranderen de teksten uit de tabel in velden om de tekst aan te passen.


 






















  • No labels