1         Introduction

1.1        Overall Description

Dit document beschrijft de ontwerpspecificaties voor een indelingsprogramma voor Schaakvereniging UVS. Het doel van dit programma is om alles van een seizoen binnen het schaken te beheren. Per competitie zijn er rondes die moeten worden ingedeeld in rondes. Deze rondes hebben meerdere spelers met resultaten die ook moeten worden verwerkt tot een ranglijst na elke ronde. Deze data moet ook worden ge-upload naar de WordPress website van Schaakvereniging UVS.

1.2         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 informatie ook fysiek beschikbaar is.
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.

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 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 schema van een toernooi kunnen genereren, zodat deelnemers hun schema 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 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 wedstrijdleider wil ik dat de resultaten van externe competities bijgehouden kunnen worden, zodat de rating van spelers altijd up-to-date kan zijn. 

1.3        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. Zij kunnen alles wat het programma zou moeten doen. Zij gebruiken het systeem om seizoenen, competities, leden en niet leden te beheren. 

1.4        Operating Environment

Het indelingsprogramma zal worden uit geprogrammeerd worden in Java en zal moeten werken op de Windows en MacOS operating systems. Er is een bestaande testdatabase waarop de nieuwe database gebaseerd kan worden maar het zou ook liever makkelijk met een andere database kunnen werken. Daarom wordt er gewerkt met de Java Persistence API (JPA). Hierdoor wordt het relatief makkelijker om een andere database aan het programma te koppelen. 

1.5        Design and Implementation Constraints

<Describe any items or issues that will limit the options available to the developers. These might include: hardware (e.g. specific mobile platforms), specific technologies, tools, and databases to be used; interfaces to other applications; programming language required; or communications protocols>

1.6        Product Functions

De hoofdfunctionaliteiten van het indelingsprogramma zijn als volgt: De gebruiker moet een seizoen kunnen aanmaken, zodat hier een competitie aangemaakt kan worden. 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 zullen deze resultaten worden meegenomen om ranglijsten te maken voor de specifieke rondes. Na afloop van een wedstrijd zal de rating van de spelers ook worden aangepast. Aan het einde van een speelronde zullen de resultaten worden geüpload naar de website van UVS.

2         Domain Model

<Provide a diagram showing important real-situation conceptual classes in the application domain. Do NOT include software classes. Describe each of the conceptual classes in a glossary.>

3         Use-case Descriptions

<In this section, each use-case is described in detail, optionally accompanied by a system sequence diagram (SSD) and operation contracts. Make sure that the use case descriptions are consistent with the domain model and the use case diagram from Section 1.5>

3.1        Use case 1

<Don’t really say “Use case 1.” State the use-case name instead.>

3.1.1        Fully-dressed use case description

<Provide a fully-dressed use-case description in the format you know from the OOAD course>

3.1.2        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>

3.1.3        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.>

3.2        Use case 2 ( and so on)

…

4         Other functional requirements (optional)

<Use this section to describe functional requirements that cannot be expressed in the shape of use cases, for instance because they do not concern goal-oriented interactions of an actor with the system.>

5         Non-functional Requirements

<Describe non-functional requirements in this section. Please refer to existing software quality models like ISO_IEC_IEEE_25010 or FURPS+.>

5.1        Performance Efficiency

5.2        Security

5.3        Reliability (and so on)

6         User interface sketches (optional)

<Provide low-fidelity user interface sketches. Map the sketches to use cases and other requirements if applicable.>