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        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.3        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.4        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.5        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.>