Spécification des exigences

Introduction

Ce chapitre décrit les exigences du projet «7 Wonders». Il suit la norme IEEE 830-1998.

Avant-propos

L’objectif de ce document est de décrire les spécifications des exigences du projet "7 Wonders" pour les étudiants en génie logiciel.

Le public visé par cette spécification comprend les développeurs potentiels de l’application, ainsi que les personnes chargées de l’évaluation technique.

Définitions, acronymes et abréviations

Aucune jusqu’à présent.

Portée du projet

Le système logiciel à produire est une version simplifiée du jeu de plateau 7 Wonders, qui sera désigné par le terme "7 Wonders" dans le présent document.

Le système 7 Wonders permettra à des joueurs de différents endroits de s’affronter dans des parties courtes et intensives.

Références

  1. IEEE Standard 830-1993: IEEE Recommended Practice for Software Requirements Specifications

Vue d’ensemble

Le reste de ce document contient une description globale du système logiciel 7 Wonders (section Description générale, les exigences fonctionnelles spécifiques (section [fonctional]) et les exigences non-fonctionnelles du système (voir [nonfonctional].

Description générale

Perspectives du produit

7 Wonders est un jeu de carte type draft où plusieurs joueurs s’affrontent. Le logiciel 7 Wonders doit permettre aux joueurs qui sont connectés à Internet d’utiliser leurs appareils connectés pour jouer. Ainsi, "7 Wonders" est une version électronique en ligne du jeu de cartes type draft.

Fonctionnalités du produit

Le logiciel 7 Wonders doit assurer deux fonctions principales :

  1. Création de jeu : permettre à des joueurs de commencer une partie.

  2. Le jeu : permettre aux joueurs de jouer effectivement à 7 Wonders jusqu’à la victoire de l’un d’entre eux.

Caractéristiques et classes d’utilisateurs

Le logiciel 7 Wonders n’a qu’une seule classe d’utilisateurs : les joueurs.

Environnement opérationnel

Le client Web devrait fonctionner sur tout navigateur Web récent : Firefox, Chrome, Safari, ou Edge.

Langages de programmation

  1. Le serveur de jeu doit être développé en Java (version ≥ 11), en utilisant le https://spring.io [Spring Framework].

  2. Le client doit être développé en TypeScript (version ≥ 4.0), en utilisant le https://reactjs.org [ReactJS Framework].

Langage de conception

  1. Les documents sur le développement du logiciel doivent être écrits dans le format Asciidoc.

  2. Les diagrammes UML d’analyse, conception et mise en œuvre devront être réalisés en PlantUML.

Conception

Mise en œuvre

  1. Les tests dynamiques doivent utiliser JUnit (version >= 5.0) et Jasmine (version >= 3.5.0).

  2. Le code doit journaliser ses principales opérations en utilisant https://www.slf4j.org [SLF4J].

Outils de construction

  1. Tous les artefacts logiciels doivent utiliser un outil de construction : Maven ou Groovy pour Java, npm pour TypeScript.

Vérification

  1. Les doubles tests doivent être utilisés pour tester chaque composant indépendamment.

  2. Chaque test unitaire doit décrire son intention.

Documentation utilisateur

Aucune documentation utilisateur n’est requise pour la première version du logiciel.

Hypothèses et dépendances

Aucun jusqu’à présent.

Exigences fonctionnelles

Connexion d’un utilisateur a l’application client

Description sous la forme d’un cas d’utilisation

Item Description

#

1

Cas d’utilisation

Connexion

Alias

Connexion, Accès à l’application

Objectif contextuel

Connexion du joueur à l’application, accès aux menus de jeu.

Portée

La connexion

Niveau

Summary

Condition de succès

Le joueur est connecté au serveur

Condition d’échec

Le joueur n’est pas connecté

Acteurs principaux:

  • Le joueur

  • L’application

Acteurs secondaires

Événement déclencheur

Accès à l’application par le joueur.

Priorité

Haute

Fréquence

1 fois par session d’utilisation de l’application.

Pré-conditions

Aucune.

Post-conditions

Le joueur est connecté et a accès au menu.

Scénario nominal

  1. Le joueur lance l’application.

  2. L’application demande au joueur d’insérer un pseudo

  3. L’application sauvegarde en local le pseudo

  4. L’application crée une connexion avec le serveur

  5. Afficher le menu de sélection de partie

Extensions

Alternatives

Cas d’utilisation supérieur

Cas d’utilisation subordonnés

Cas d’utilisation du Menu du jeu.

Objectif de performance

Problèmes ouverts

Échéancier

Version 1.0.0

Contraintes

Annexes

Choix de la partie

Description sous la forme d’un cas d’utilisation

Item Description

#

2

Cas d’utilisation

Choix d’une partie

Alias

Menu du jeu

Objectif contextuel

Permet au joueur de rejoindre une partie

Portée

Le jeu

Niveau

Summary

Condition de succès

Le joueur a rejoint la partie.

Conditions d’échec

Le joueur ne peut pas choisir la partie

Acteurs principaux:

Le joueur, l’application

Acteurs secondaires

Événement déclencheur

Connexion du joueur

Priorité

Haute

Fréquence

Autant de fois que le joueur veut rejoindre une partie.

Pré-conditions

Le joueur doit être connecté.

Post-conditions

Scénario nominal

  1. Le joueur selectionne la partie afin de la rejoindre et jouer.

  2. Il peux actualiser le menu de sélection de partie.

Extensions

Alternatives

  1. La partie est deja pleine et il a été mis sur liste d’attente

Cas d’utilisation supérieur

Cas d’utilisation subordonnés

Objectif de performance

Problèmes ouverts

Nous n’avons pas pris en compte la création de parties

Échéancier

Version 1.0.0

Contraintes

Annexes

Préparation de la partie

Description sous la forme d’un cas d’utilisation

Item Description

#

3

Cas d’utilisation

Préparation

Alias

Initialisation, Mise en place

Objectif contextuel

Mise en place de la partie, distribution des Merveilles, des cartes Âge, des jetons Conflit et de la monaie, afin de commencer la partie.

Portée

Le jeu

Niveau

Summary

Condition de succès

Les Merveilles, carte Âge, jetons Conflit et la monaie sont distribués.

Condition d’échec

Les Merveilles, carte Âge, jetons Conflit ou la monaie ne sont pas distribués.

Acteurs principaux:

  • Les joueurs

  • L’application

Acteurs secondaires

Événement déclencheur

Entre trois et sept joueurs sont dans la partie, et un joueur lance la partie.

Priorité

Haute

Fréquence

1 fois par partie

Pré-conditions

Il y a entre 3 et 7 joueurs dans la partie

Post-conditions

  • Tous les joueurs ont une Merveille

  • Tous les joueurs ont leurs cartes et pièces

Scénario nominal

  1. Un joueur lance la partie ou la partie est pleine.

  2. L’application crée 3 paquets de cartes : Un tas de carte d’Âge 1, un tas de carte d’Âge 2 et un tas de carte d’Âge 3. Ces paquets de cartes ne sont composés que de cartes annotées comme inférieures ou égales au nombre de joueurs.

  3. L’application génère un tas de cartes guilde, composé du nombre de joueur+2 cartes, puis les ajoutes dans un ordre aléatoire au tas de carte d’Âge 3.

  4. L’application attribue aléatoirement une Merveille différente à chaque joueur.

  5. L’application distribue 3 de monaie à chaque joueur.

  6. L’application génère une pile de jetons Conflit.

Extensions

Alternatives

Cas d’utilisation supérieur

Choix de la partie

Cas d’utilisation subordonnés

Objectif de performance

Problèmes ouverts

  • Nous ne prenons pas en compte le choix possible des Merveilles

  • Nous ne prenons pas en compte les différentes difficultés des Merveilles

Échéancier

Version 1.0.0

Contraintes

Annexes

Déroulement d’un tour

Description sous la forme d’un cas d’utilisation

Item Description

#

4

Cas d’utilisation

Déroulement du jeu

Alias

Objectif contextuel

Faire jouer une partie de 7 Wonders à plusieurs joueurs

Portée

Le jeu

Niveau

Summary

Condition de succès

Le jeu a bien été préparé, entre 3 et 7 joueurs sont dans la partie

Condition d’échec

Jeu pas préparé, il y a moins de 3 joueurs

Acteurs principaux:

  • Les joueurs

  • L’application

Acteurs secondaires

Événement déclencheur

La partie a fini d’être préparé

Priorité

Haute

Fréquence

1 fois par partie

Pré-conditions

La partie est préparé, il y a entre 3 et 7 joueurs

Post-conditions

Scénario nominal

  1. Prendre 1 carte dans les 7 possédées, donner le reste à son voisin de gauche (Age 1,3), de droite (Age 2)

  2. Phase d’action : Une fois que tout les joueurs ont sélectionné leur carte, ils choisissent une action qu’ils vont tous effectuer simultanément parmis les suivantes.

    1. Construire un batiment

    2. Construire une étape Merveille

    3. Défausser la carte pour obtenir 3 pièces

       2.a Construire u batiment :
Le joueur dépense le coût de sa carte pour construire le batiment, qui est placé dans la pile des batiments. (Voir TYPES DE CARTES)
       2.b Construire une étape Merveille :
Le joueur dépense le coût noté sur son plateau Merveille, utilisant la carte qu'il a choisit à l'étape 1 comme marqueur (carte défaussée). Sa Merveille passe alors un stade.
La Merveille ne peut pas être commencée à l'age 3 et cette étape peut être appelée une seule fois par age.
       2.c Défausser la carte pour obtenir 3 pièces :
Le joueur défausse sa carte sélectionnée à l'étape 1, et obtient 3 pièces qu'il ajoute à son trésor.

  3. Répéter jusqu’au 6eme tour.

    • 6eme tour : a la fin de ce tour, l’age en cours est terminé, les cartes restantes sont défaussées.

    • Un nouvel age est ensuite lancé.

  4. Fin d’un age : Comparer la force militaire avec voisins

    • Si plus (gagne): gagne PV en fonction Age

    • Si moins (perd): moins PV en fonction Age

  5. Lorsque la fin de l’Age 3 est atteinte, le gagnant est celui ayant le plus de PV

TYPES DE CARTES

  1. Carte Resources = Grise, Marron → Construire autres cartes

    • Stocker à côté du plateau

  2. Carte à construire

    • Types :

      • Rouge = Militaire, effet fin Age

        • Force militaire, nombre symbole épée/bouclier

      • Bleu = pas d’effet, juste points de victoire

      • Verte = symbole, collection de symboles → points

      • Jaune = Commerce

        • Resources moins chères voisins

        • Bonus de pièces

    • Coût en haut à gauche

    • Uilisations :

      • Construction

        • Si resource possédée

          • construite

          • PAS défausser resources

        • Si pas resources

          • Acheter à 1 des 2 voisins directs = 2 pièces

          • Voisin ne peut refuser

          • PAS défausser resources

        • Chaînage possible: si age précédent, carte précise possible chaîner → construction direct

        • Ajouter à Merveille de l’Age

          • Coût précisé

          • PV (fin de partie) et pièces (à recevoir direct) précisée sur plateau

      • Défausser → reçoit 3

  3. Carte Guilde (Age 3) = fonctions particulières

Extensions

Alternatives

Cas d’utilisation supérieur

Choix de la partie

Cas d’utilisation subordonnés

Objectif de performance

Problèmes ouverts

  • Nous ne prenons pas en compte le choix possible des Merveilles

  • Nous ne prenons pas en compte les différentes difficultés des Merveilles

Échéancier

Version 1.0.0

Contraintes

Annexes

Déroulement de la fin de partie

Description sous la forme d’un cas d’utilisation

Item Description

#

5

Cas d’utilisation

Fin d’une partie

Alias

Fin d’une partie

Objectif contextuel

Précise les conditions de fin d’une partie

Portée

Le jeu

Niveau

Summary

Condition de succès

Un joueur rempli les conditions de victoire.

Conditions d’échec

Un joueur quitte avant la fin de la partie

Acteurs principaux:

Les joueurs, l’application

Acteurs secondaires

Événement déclencheur

L’Age 3 est terminé et les jetons conflits ont été distribués

Priorité

Haute

Fréquence

Une fois par partie

Pré-conditions

  1. La partie doit avoir commencé

  2. L’Age 3 est terminé

  3. Attribution des jetons conflits

Post-conditions

Scénario nominal

  1. Comptage des points

    1. Conflits militaires : Chaque joueur additionne ses jetons Victoire et Defaites militaires (Peut etre negatif)

    2. Argent : 1 point par lot de 3 pieces

    3. Merveilles : Ajoute au score les points de victoire de sa merveille.

    4. Batiments civils : Ajoute les points de victoire écrits sur chaque batiment civil

    5. Batiments scientifiques : Les points de victoires obtenus sont égales aux nombres de symboles identiques au carré.

    6. Batiments commerciaux : Certains batiments commerciaux procure des points de victoire (voir sur chaque cartes)

    7. Guildes : Chaque Guilde rapporte un nombre de points de victoire qui dépend de la configuration de la cité du joueur et/ou de celle des deux cités voisines (voir Description des bâtiments).

  2. Le joueur avec le plus de point après le comptage est le vainqueur

Extensions

Alternatives

  1. Un joueur a quitté la partie

Cas d’utilisation supérieur

Lancement de la partie

Cas d’utilisation subordonnés

Fermeture du serveur de jeu

Objectif de performance

Problèmes ouverts

Échéancier

Version 1.0.0

Contraintes

Annexes

Autres exigences non-fonctionnelles

Exigences de performance

  1. Le jeu doit être jouable, ce qui signifie que les utilisateurs doivent avoir un retour rapide de leurs actions et que les retards dus aux problèmes de communication/connexion doivent être correctement tenus.

  2. Le client Web doit pouvoir s’exécuter sur un ordinateur personnel doté de 4 Go de RAM.

Exigences de sécurité

  1. Le joueur ne doit pas être mis au courant des attributs secrets d’un autre joueur. Pour cela on utilise des DTO (Datat Transfer Object)

Maintenabilité

  1. Le logiciel doit être lisible et facile à maintenir.

  2. La source Java doit respecter les directives de Google : https://google-styleguide.googlecode.com/svn/trunk/javaguide.html.

Exigences de design

Afin de préparer la réalisation de notre application client, nous avons crée un design de celle ci

Accueil

Homepage
Figure 1. Accueil

Rejoindre une partie

Join game
Figure 2. Rejoindre une partie

Partie en attente du nombre de joueurs

Waiting screen
Figure 3. Partie en attente du nombre de joueurs

En partie

Playing
Figure 4. En partie