Introduction
Overall Description
Dit document beschrijft de ontwerpspecificaties voor een indelingsprogramma voor Schaakvereniging UVS. Het doel van dit programma is om alles van een schaakseizoen te beheren. 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 een competitie kunnen aanmaken, zodat ik mijn leden kan laten schaken.
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 Characteristics
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.
Operating Environment
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 and Implementation Constraints
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 Functions
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.
| Actor | Use Case | Brief description |
|---|---|---|
| Wedstrijdleider | Beheren leden en gasten | De wedstrijdleider moet de mogelijkheid hebben om nieuwe leden en gasten in het systeem in te voeren, zodat ze later kunnen worden toegevoegd aan competities. |
| Wedstrijdleider | Printen ronde indeling | De wedstrijdleider moet de indeling van een ronde moeten kunnen uitprinten zodat de leden op locatie de indeling kunnen zien. |
| Wedstrijdleider | Seizoenen bekijken | De wedstrijdleider wil oude seizoenen kunnen bekijken zodat de historie van de club altijd bekeken kan worden. |
| Wedstrijdleider | Aanmaken van een competitie | De wedstrijdleider moet een nieuwe competitie kunnen aanmaken, zodat deze kan worden ingezet voor het organiseren van schaakwedstrijden. |
| Wedstrijdleider | Toevoegen van deelnemers aan een competitie | De wedstrijdleider moet in staat zijn om leden en gasten toe te voegen aan een competitie, zodat zij ingedeeld en kunnen deelnemen aan de schaakwedstrijden. |
| Wedstrijdleider | Toekennen van competitietype | Als wedstrijdleider wil ik een competitie een type kunnen geven, zodat deze het juiste aantal rondes kan krijgen. |
| Wedstrijdleider | Gegevens publiceren op website | De wedstrijdleider wil de ronde indeling, uitslagen en de ranglijst op de website publiceren zodat elk persoon online de gegevens kan bekijken. |
| Wedstrijdleider | Ronde resultaten invoeren | De wedstrijdleider wil resultaten van ronden kunnen invoeren zodat de ranglijst anders wordt. |
| Wedstrijdleider | Indeling genereren voor competitie | De wedstrijdleider wil automatisch door het systeem een indeling voor de rondes van competities laten genereren. |
| Wedstrijdleider | Globale ranglijst bekijken | De wedstrijdleider wil de globale ranglijst bekijken zodat duidelijk is wie het beste is. |
| Wedstrijdleider | Groep ranglijst bekijken | De wedstrijdleider wil de ranglijst van een groep bekijken zodat duidelijk is wie het beste is. |
| Extern wedstrijdleider | Resultaat externe ronde invoeren | De externe wedstrijdleider wil het resultaat van een externe ronde invoeren zodat de rating van het lid aanpast |
Domain Model
Use-case Descriptions
Beheren leden en gasten
Use Case 1: Spelers bekijken
Primary actor: Wedstrijdleider | |
Stakeholders and Interests: De wedstrijdleider, omdat de competities niet gespeeld zouden kunnen worden zonder dat er spelers bekend zijn voor de indelingen. | |
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 creatie open. | |
Postconditions (Success Guarantee): De wedstrijdleider ziet alle bekende spelers | |
Main Success Scenario (Basic Flow): | |
Actor Action | System Responsibility |
1. De wedstrijdleider klikt op de spelerslijst knop |
|
Use Case 1: Spelers toevoegen
Primary actor: Wedstrijdleider | |
Stakeholders and Interests: De wedstrijdleider, omdat de competities niet gespeeld zouden kunnen worden zonder dat er leden en gasten bekend zijn voor de indelingen. | |
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 nieuw lid geregistreerd. | |
Main Success Scenario (Basic Flow): | |
Actor Action | System Responsibility |
1. De wedstrijdleider klikt op de spelerslijst knop. 3. De wedstrijdleider klikt op de speler toevoegen knop.
5. De wedstrijdleider vult de naam en de huidige rating van het nieuwe speler in. 6. De wedstrijdleider selecteert type en voegt de nieuwe speler toe. |
4. Systeem toont de voornaam, achternaam en de rating van gasten. Invulvelden voor een nieuwe speler worden ook getoond. 7. [type = gast] Systeem registreert de nieuwe gast. |
Extensions (Alternative Flow): Type is lid. | |
6a. De wedstrijdleider vult de datum van lidmaatschap in en voegt het nieuwe lid toe. | 7a. Systeem registreert het nieuwe Lid. |
Use Case 1: Spelers verwijderen
Primary actor: Wedstrijdleider | |
Stakeholders and Interests: De wedstrijdleider, omdat de inactieve spelers uit de spelerslijst moeten kunnen gehaald 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 klikt op de spelerslijst knop 3. De wedstrijdleider klikt op de speler verwijderen knop. 5. De wedstrijdleider selecteert een speler om te verwijderen en klikt op de knop. 7. De wedstrijdleider bevestigt de keuze | 4. Systeem toont hetzelfde als bij stap 2 met een knop met een rood kruis bij elke speler. 6. Systeem toont een confirmatie scherm of de gebruiker het zeker weet. 8. Systeem verwijderd de gekozen speler. |
Use Case 1.4: Spelers bewerken
Primary actor: Wedstrijdleider | |
Stakeholders and Interests: De wedstrijdleider, omdat de competities niet gespeeld zouden kunnen worden zonder dat er leden en gasten bekend zijn voor de indelingen. | |
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 klikt op de spelerslijst knop. 3. De wedstrijdleider geeft aan een speler te willen bewerken.
5. De wedstrijdleider past de gegevens aan en drukt op de bewerken knop. |
4. Systeem toont de voornaam, achternaam, type en de rating van gasten. 6. Systeem slaat de nieuwe gegevens op. |
Extensions (Alternative Flow): Type is lid. | |
6a. De wedstrijdleider vult de datum van lidmaatschap in en voegt het nieuwe lid toe. | 7a. Systeem registreert het nieuwe Lid. |
System Sequence Diagram (optional)
<In case the use-case entails complex scenarios, you may decide to create a system sequence diagram showing events generated by external actors, the order of events and inter-system events. All systems are treated as a black box>
Operation Contracts (optional)
<If the use case contains complex manipulations of domain objects, you may decide to specify operation contracts for all system operations included in the use case/ SSD.>
Aanmaken van een competitie
Use Case 2: Aanmaken van een competitie
Primary actor: Wedstrijdleider | |
Stakeholders and Interests: De wedstrijdleider, omdat er zonder competities geen indelingen kunnen worden gemaakt voor de partijen. | |
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 klikt op de competities knop
5. De wedstrijdleider vult de gegevens in voor de competitie. |
4. Systeem toont invulvelden voor de naam, soort competitie, aantal avonden, aantal punten(Zwitsers), type Zwitsers en de indelingsvariatie.
7. Systeem maakt een nieuwe competitie aan. |
System Sequence Diagram (optional)
<In case the use-case entails complex scenarios, you may decide to create a system sequence diagram showing events generated by external actors, the order of events and inter-system events. All systems are treated as a black box>
Operation Contracts (optional)
<If the use case contains complex manipulations of domain objects, you may decide to specify operation contracts for all system operations included in the use case/ SSD.>
Toekennen van competitietype
Use Case 3: Toekennen van competitietype
Primary actor: Wedstrijdleider | |
Stakeholders and Interests: De wedstrijdleider, omdat de competities de correcte aantal rondes, het aantal gespeelde rondes en type rondes per avond moeten krijgen. | |
Brief description: De wedstrijdleider moet een nieuwe competitie kunnen aanmaken, zodat deze kan worden ingezet voor het organiseren van schaakwedstrijden. | |
Preconditions: De wedstrijdleider heeft stap 5 van Use case 2: Aanmaken van een competitie uitgevoerd. | |
Postconditions (Success Guarantee): De wedstrijdleider heeft een competitie-type gegeven aan de nieuw aangemaakte competitie. | |
Main Success Scenario (Basic Flow): | |
Actor Action | System Responsibility |
| |
Extensions (Alternative Flow): De gekozen competitiesoort is een toernooi. | |
2a. De wedstrijdleider kiest het juiste aantal rondes en gespeelde rondes en gaat verder. | 1a. Systeem toont een invulveld voor het aantal rondes en aantal gespeelde rondes per avond. 3a. Systeem geeft het juiste aantal rondes, gespeelde rondes en type rondes liggend aan de competitiesoort. |
System Sequence Diagram (optional)
<In case the use-case entails complex scenarios, you may decide to create a system sequence diagram showing events generated by external actors, the order of events and inter-system events. All systems are treated as a black box>
Operation Contracts (optional)
<If the use case contains complex manipulations of domain objects, you may decide to specify operation contracts for all system operations included in the use case/ SSD.>
Other functional requirements (optional)
Code | Description |
FR1 | Als een uitslag van een ronde is ingevuld moeten de ratings van de personen geüpdate worden |
FR2 | Als een uitslag van een ronde is ingevuld moet de ranglijst geüpdate worden |
FR3 | Het programma moet competities voor Periodecompetitie, meerkamp en toernooi kunnen afhandelen |
FR4 | Het programma moet in Java of Python geschreven zijn |
FR5 | Er moet op een minimalistische manier kunnen worden geschakeld tussen databases |
FR6 |
|
Non-functional Requirements
De volgende non-functionele requirements zijn geschreven volgens FURPS.
Usability
Code | Description |
NFR1 | Het programma moet via een exe te runnen zijn |
NFR2 | Het programma moet draaien zowel Windows als MacOS |
Reliability
Code | Description |
NFR1 |
Performance
Code | Description |
NFR2 |
Security
Code | Description |
NFR2 |
User interface sketches (optional)
<Provide low-fidelity user interface sketches. Map the sketches to use cases and other requirements if applicable.>