1         Introduction

1.1        Overall Description

Dit document beschrijft de ontwerpspecificaties voor een indelingsprogramma voor Schaakvereniging UVS. Het doel van dit programma is om per speelronde spelers in te delen voor hun schaakcompetities. Na afloop van de wedstrijden zal het programma een ranglijst genereren en deze publiceren op de website van de vereniging. Daarnaast moet het mogelijk zijn om deze ranglijst af te drukken.

1.2        User Classes and Characteristics

Binnen het indelingsprogramma zijn een aantal gebruikers: de twee schaakspelers en een bestuurslid van de schaakvereniging. Van de schaakspelers is bekend wie ze zijn, hun lidmaatschap nummer en welke rating zij hebben binnen het schaken. De bestuursleden van de vereniging hebben toegang tot de applicatie om 

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 database waarop het programma moet werken maar het moet ook makkelijk met een andere database kunnen werken. Daarom wordt er gewerkt met de Java Persistence API (JPA). Hierdoor wordt relatief makkelijker om een andere 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

<Summarize the major functions the product must perform or must let the user perform. Details will be provided in Section 3, so only a high level summary is needed here. In most cases, this section will primarily contain a use case diagram and brief use case descriptions >

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