Spécification des exigences

Introduction

Ce chapitre décrit les exigences du projet «les-colons-de-catane». 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 "les-colons-de-catane" 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

Chaque exigence possède sa propre priorité, les quelques priorités qui seront hérités seront précisées sur l’exigence concernée.

Les descriptions et les commentaires sont écrits en français. Les noms de fichiers, les classes qui en découlent ainsi que les signatures de méthodes et fonction seront écrites en anglais. Les références aux diverses activités possibles seront faites en utilisant le nom de leur cas d’utilisation s’il existe.

Public visé et suggestions de lecture

Ces documents sont destinés aux développeurs travaillant sur le projet, les personnes rédigeant la documentation, et au professeur qui notera ce projet.

Il est conseillé de d’abord lire les fichier exigence-settingup-game.adoc puis exigence-typical-player-turn.adoc Le reste des cas d’utilisations peuvent être lu dans l’ordre désiré. Ces cas d’utilisatoins se trouvent dans ~/catan-doc/exigences/pages

Portée du projet

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

Le système les-colons-de-catane permettra à des joueurs de différents endroits de s’affronter dans des parties courtes et intensives.

Les règles utilisées pour les-colons-de-catane seront générales et ne s’adapteront pas en fonction du niveau des joueurs. Il se peut que ces règles soient légèrement différentes pour assurer un déroulé rapide d’une partie.

Références

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

Tous les documents relatifs à ce projet ont été co-rédigés par Mathis EMERIAU et Tristan RAME, et ce, entre le 11 octobre 2022 et le 17 décembre 2022. La documentation est entièrement disponible dans le dossier les-colons-de-catane/catan-doc :
- Les documents relatifs à l’analyse de domaine se trouvent dans le dossier analyse.
- Les documents relatifs à la spécification des exigences se trouvent dans exigences.
- Les documents relatifs à la spécification des composants et des interfaces se trouvent dans composants.
- Les documents relatifs à la conception du projet tels que les diagrammes de classes se trouvent dans conception.

Vue d’ensemble

Le reste de ce document contient une description globale du système logiciel les-colons-de-catane (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

les-colons-de-catane est un jeu de cartes où plusieurs joueurs s’affrontent. Le logiciel les-colons-de-catane doit permettre aux joueurs qui sont connectés à Internet d’utiliser leurs appareils connectés pour jouer. Ainsi, "les-colons-de-catane" est une version électronique en ligne du jeu de société.

Bien que le système soit distribué et organisé en différents composants, les joueurs doivent le percevoir comme un seul logiciel. La figure Figure 1 présente l’architecture globale du logiciel. Les joueurs interagissent avec un client Web, qui utilise le protocole HTTP pour communiquer avec (au maximum) un serveur de jeu. Les serveurs utilisent le protocole TCP/IP pour communiquer avec un serveur de gestion de base de données, qui stocke toutes les données du logiciel.

diagram
Figure 1. UML Diagramme de déploiement

Ce système est un produit autonome. Il n’y a pas de projets antécédents comme base.

Fonctionnalités du produit

Le logiciel les-colons-de-catane doit assurer deux fonctions principales :

  1. Création de jeu : permettre à trois ou quatre joueurs de se découvrir et de commencer une partie.

  2. Le jeu : permettre aux joueurs de jouer effectivement à les-colons-de-catane jusqu’à la victoire de l’un d’entre eux.

Caractéristiques et classes d’utilisateurs

Les utilisateurs doivent avoir minimum 10 ans pour comprendre le jeu et l’apprécier. Ce jeu est pour l’instant destiné à un public francophone ou anglophone (langues parlés par les auteurs du projet).

Le logiciel les-colons-de-catane n’a qu’une seule classe d’utilisateurs : les joueurs. Les joueurs peuvent avoir différents niveaux : débutants, intermédiaires ou experts. Cependant, indépendamment de leur niveau, les joueurs doivent utiliser la même interface utilisateur pour jouer les uns contre les autres. De plus, pour l’instant, différencier le niveau n’est pas encore prévu.

Environnement opérationnel

Le logiciel sera de préférence sur un ordinateur (tablette et téléphone possibles mais non prévus dans le futur).

Le logiciel les-colons-de-catane doit fonctionner sur tout système d’exploitation populaire et récent : Linux, Windows, ou MacOS. Le client Web devrait fonctionner sur tout navigateur Web récent : Firefox, Chrome, Safari, ou Edge.

Version minimum requise pour :
Linux → distribution équivalente à Ubuntu 18.04 LTS
Windows → 10
MacOS → distribution équivalente à macOS High Sierra
Firefox → 71
Chrome → 101.0.4951
Safari → 14
Edge → 88

Contraintes de conception et de mise en œuvre

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://angular.io [Angular 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.

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.

Outils de développement

Aucun outil obligatoire. Néanmoins, IntelliJ est conseillé.

Bibliothèques et composants logiciels

Rien de plus que ce qui est spécifié précédemment.

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 reportées

Les versions futures du système comprendront l’utilisation d’un mécanisme de persistance de données ainsi que différentes interfaces utilisateur : web, IHM classique, etc. Elles permettront aussi l’accès distant à travers une interface REST.
Les joueurs pourront choisir une partie via une interface. Ils ne seront plus affectés automatiquement à une partie existante ou nouvelle.

Exigences en matière d’interface externe

Interfaces utilisateur

Le logiciel possèdera deux interfaces utilisateurs principales, l’une dans le cadre de la connexion et création d’une partie. L’autre sera une interface générale représentant le plateau de jeu, accompagné des divers boutons et images permettant au joueur de jouer.

On aura donc:

  • Une interface générale affichant le plateau de jeu, les joueurs et leur ressources/points de victoires, le tour de jeu.

  • Sur cette interface se trouvera 4 boutons différents, l’un pour jouer une carte développement, l’un pour réaliser l’action "commercer", l’un pour réaliser l’action "construire", et le dernier pour terminer son tour :

  • Pour le cas d’utilisation play-develop-card : Un clic sur le bouton jouer carte ouvrira une autre interface par dessus l’interface générale, qui affichera les cartes que le joueur peut utiliser et un bouton pour fermer l’interface.

  • Pour le cas d’utilisation commercer : Un clic sur le bouton "commercer" ouvrira une autre interface par dessus l’interface générale, qui affichera les ressources sélectionnables et les différentes cibles de l’échange (joueur ou banque), ainsi qu’un bouton pour fermer l’interface.

  • Pour le cas d’utilisation construire : Un clic sur le bouton "construire" ouvrira une autre interface par dessus l’interface générale, qui affichera les constructions réalisables par le joueur, ainsi qu’un bouton pour piocher une carte, et enfin un bouton pour fermer l’interface.

  • Pour le cas de la fin du tour : Un clic sur le bouton "Fin de Tour" mettra fin au tour de jeu.

Interfaces matérielles

Le logiciel n’interagit pas directement avec un quelconque dispositif matériel.

Interfaces logicielles

La partie client du logiciel doit fonctionner sur des navigateurs web, tandis que la partie serveur doit interagir avec une base de données par le biais de l’API Java Persistence (JPA).

Interfaces de communication

Les communications entre le client et le serveur de jeu doivent utiliser des Websockets (TCP/IP).

Exigences fonctionnelles

Fonctionnalité "Mise en place du jeu"

Le jeu est mis en place automatiquement par le système puis par les joueurs.

Description et priorité :
Le plateau est créé avec des tuiles placées de manière aléatoire, les couleurs attribués aux joueurs, les cartes sont créées et les ressources sont affichées, enfin les joueurs choisissent ou placer leurs premières routes et colonies.

Séquences de Stimulus/Réponse :
Les joueurs choisissent où placer leurs routes et colonies à l’aide d’un clic sur le plateau de jeu à un endroit valide.

Exigences fonctionnelles :
Voir le fichier exigence-settingup-game.adoc

Fonctionnalité "Tour de jeu"

Le joueur réalise toutes les actions qu’il peut durant un tour de jeu classique.

Description et priorité

Le joueur commence son tour soit ne jouant une carte développement, soit en lançant les dés. Il peut ensuite à sa guise choisir entre commercer, construire ou jouer une carte développement autant de fois qu’il le veut ou le peut. Une fois qu’il pense avoir fini, le joueur indique la fin de son tour et le tour passe au joueur suivant.

Séquences de Stimulus/Réponse

Le joueur clic sur les boutons destinés aux actions qu’il veut réaliser (commercer, construire, jouer une carte, finir son tour).

Description sous la forme d’un cas d’utilisation

Voir exigences-typical-player-turn.adoc

Fonctionnalité "Commercer"

Le joueur peut effectuer les actions de commerce du jeu.

Description et priorité

Le joueur peut commercer avec d’autres joueurs ou la banque à l’aide de l’interface dédiée. Pour cela il propose un échange aux autres joueurs qui peuvent l’accepter ou refuser, ou il échange avec la banque selon tarifs qui lui sont appliqués personnellement (possession de port ou non).

Séquences de Stimulus/Réponse

Le joueur utilise l’interface graphique pour préciser les ressources à échanger et les joueurs auquels il propose un échange.

Description sous la forme d’un cas d’utilisation

Voir exigence-commercer-use-case.adoc

Fonctionnalité "Construire"

Le joueur peut réaliser toutes les actions liée à l’étape de construction.

Description et priorité

Le joueur peut construire différentes infrastructures (routes, colonies ou villes) à l’aide de l’interface de construction. L’interface est disponible grâce au bouton dédiée. Il est aussi possible de piocher une carte développement à travers cette interface.

Séquences de Stimulus/Réponse

Le joueur utilise l’interface et les différents boutons associés pour construire ses infrastructures. L’emplacement de construction des infrastructures se fait par un clic à l’endroit voulu sur le plateau de jeu.

Description sous la forme d’un cas d’utilisation

Voir exigence-construire-use-case.adoc

Fonctionnalité "Jouer une carte développement"

Le joueur peut jouer une carte développement qu’il possède.

Description et priorité

Le joueur joue une de ses cartes développements, les actions réalisées dépendent de la carte (carte progrès ou carte chevalier).

Séquences de Stimulus/Réponse

Le joueur utilise l’interface dédiée pour choisir la carte qu’il joue.

Description sous la forme d’un cas d’utilisation

Voir exigence-play-develop-card-usecase.adoc

Fonctionnalité "Voleur"

Actions impliquant le pion voleur.

Description et priorité

Quand un joueur fait un 7 au dé, tout les joueurs ayant minimum 7 cartes ressources doivent en défausser la moitié (arrondie supérieur). Quand un joueur fait un 7 au dé, ou quand un joueur joue une carte chevalier : Le joueur qui a réalisé le lancer de dé ou jouer la carte déplace le voleur d’une case. Tout les autres joueurs qui ont une colonie ou ville adjacente à la case du voleur se voient voler une ressource aléatoire par le joueur courant.

Séquences de Stimulus/Réponse

Le nouvelle position du voleur est choisie à l’aide d’un clic à l’emplacement voulu sur le plateau de jeu de l’interface principale.

Description sous la forme d’un cas d’utilisation

Voir exigence-voleur-use-case.adoc

Fonctionnalité "Connexion au serveur"

Le joueur se connecte au serveur.

Description et priorité

Le joueur utilise son navigateur préféré dans lequel il rentre l’url du site dédié au jeu {projet} de ce projet. Il choisit un pseudonyme valide, composé uniquement de chiffres et de lettres. Tout cela se fait au travers d’une interface de connexion.

Séquences de Stimulus/Réponse

Le joueur doit écrire son pseudonyme dans une boîte texte dédiée.

Description sous la forme d’un cas d’utilisation

Voir server-connexion.adoc

Fonctionnalité "Rejoindre une partie"

Le joueur créé ou rejoins une partie non démarré.

Description et priorité

L’utilisateur créé un lobby et le rejoins, ou rejoins un lobby déjà créé par un autre joueur. La partie se lance quand le lobby possède 4 joueurs et que les 4 joueurs ont indiqués être prêt. Quand tout le monde est prêt le créateur du lobby lance la partie. Tout cela se fait dans une interface et à l’aide des boutons dédiés.

Séquences de Stimulus/Réponse

Le joueur clique sur les boutons dédiés pour créer ou rejoindre une partie

Description sous la forme d’un cas d’utilisation

Voir join-a-game.adoc

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é

Un joueur ne doit pas avoir accès aux informations de connexion des autres joueurs tel que leur IP. Un joueur ne peut pas modifier le fonctionnement de la partie.

Attributs de qualité logicielle

Extensibilité

Possibilité de rajouter de nouvelles cartes développement, de nouvelles ressources, et de nouveaux types de tuiles facilement.

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.

Élasticité

On considère pour l’instant que le serveur ne supportera qu’une partie à la fois. Il est donc facile de mettre en relation 3 ou 4 utilisateurs en temps réel.

Règles métier

Les joueurs peuvent interagir avec le produit uniquement de la mnière définit par les exigences fonctionelles. Si un joueur se déconnecte en pleine partie en fermant son navigateur, la partie est fermée automatiquement.

Autres exigences

Annexe A : Glossaire

Vocabulaire et Abréviations utilisés dans la documentation par la suite :
Les colons de Catane → Catane ou Catan
Map → Dictionnaire
Infrastructure → Pions du jeu (route/colonie/ville)

Annexe B : Modèles d’analyse

Voir le chapitre [domain] (analyse du domaine) pour plus de détails.