Spécification des exigences

1. Introduction

Ce chapitre décrit les exigences du projet «Trivial Pursuit». Il suit la norme ISO/IEC/IEEE 29148-2018.

1.1. Avant-propos

L’objectif de ce document est de décrire les spécifications des exigences du projet "Trivial Pursuit" 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.

1.2. Définitions, acronymes et abréviations

Norme ISO/IEC/IEEE 29148-2018

Ingénierie des systèmes et du logiciel — Processus du cycle de vie — Ingénierie des exigences

SRS

Software Requirements Specification, Spécification des Exigences Logicielles

Table 1. Acronymes
Acronyme Description

JDBC

Java DataBase Connectivity

JPA

Java Persistence API

SGBD

Système de Gestion de Bases de Données
Table 2. Définitions
Terme Définition

WebSockets

Protocole servant à établir des connexions TCP persistantes entre serveurs et clients

1.3. Public visé et suggestions de lecture

Ce document est à la destination des étudiants de première année du Master Informatique de Nantes Université.

1.4. Portée du projet

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

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

1.5. Références

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

  2. «Trivial Pursuit — Genus Edition». Horn Abbot International Limited

  3. Trivial Pursuit. Article Wikipedia

  4. Les règles du jeu : Trivial Pursuit. Ribambel

1.6. Vue d’ensemble

Le reste de ce document contient une description globale du système logiciel Trivial Pursuit (section Section 1.8, les exigences fonctionnelles spécifiques (section Section 6) et les exigences non-fonctionnelles du système (voir Section 2.

1.7. Organisation du chapitre

1.8. Description générale

1.8.1. Perspectives du produit

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

Bien que le système soit distribué et organisé en différents composants, les joueurs doivent le percevoir comme un seul logiciel. La Figure 1 présente l’architecture globale préconisée du logiciel. Il est organisé en trois nœuds logiques distincts. Le nœud Navigateur contient les artefacts nécessaires à l’exécution du Client Web. Ce client utilise des WebSockets pour communiquer avec l’artefact Serveur TP, déployé sur le nœud Serveur.

Le nœud Serveur contient tous les artefacts nécessaires à la gestion de plusieurs parties du jeu. Le Serveur TP utilise JDBC pour interroger le SGBD, qui stocke toutes les données du logiciel. Le SGBD déployé sur le nœud Database.

Les joueurs interagissent avec le Client Web, qui utilise le protocole les WebSockets pour communiquer avec (au maximum) un serveur de jeu.

diagram
Figure 1. UML Diagramme de déploiement
Un Nœud Logique est une cible de déploiement qui représente une ressource informatique sur laquelle les artefacts peuvent être déployés pour être exécutés.
Plusieurs nœuds logiques peuvent s’exécuter sur un même Nœud Physique ou Dispositif.

Trivial Pursuit sera le premier d’une ligne de produits de type "Jeu de plateau". Son architecture servira comme exemple à d’autres produits.

1.8.2. Fonctionnalités du produit

Le logiciel Trivial Pursuit doit assurer trois fonctions principales :

  1. Connexion au serveur : permettre à un joueur de rejoindre un serveur pour ensuite choisir une partie.

  2. Création de jeu : permettre aux joueurs de se découvrir et de commencer une partie.

  3. Le jeu : permettre aux joueurs de jouer effectivement à Trivial Pursuit jusqu’à la victoire de l’un d’entre eux.

1.8.3. Caractéristiques et classes d’utilisateurs

Le logiciel Trivial Pursuit a deux classes d’utilisateurs : les joueurs et les administrateurs.

Les joueurs peuvent avoir différents niveaux : débutants, intermédiaires ou experts.
Cependant, indépendamment de leur niveau, les joueurs utilisent la même interface utilisateur pour jouer les uns contre les autres.

Les administrateurs peuvent gérer les joueurs et les parties.

1.8.4. Environnement opérationnel

Le Serveur 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 compatible avec les WebSockets : Firefox (≥ 7.0), Chrome (≥ 5.0), Safari (≥ 5.0), ou Edge (≥ 12.0).

2. Exigences non-fonctionnelles

2.1. Contraintes de conception et de mise en œuvre

2.1.1. Langages de programmation

Utiliser le langage Java, version 11 (minimum)
NF-Req-1

Le serveur de jeu doit être développé en Java (version ≥ 11), en utilisant le Spring Boot (version ≥ 3.0.0).

Utiliser le langage TypeScript, version 4 (minimum)
NF-Req-2

Le client doit être développé en TypeScript (version ≥ 4.0), en utilisant le Angular Framework (version ≥ 16.0).

2.2. Langage de conception

Utiliser Asciidoc
NF-Req-3

La documentation de développement du logiciel doit être écrite dans le format Asciidoc.

Utiliser PlantUML
NF-Req-4

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

2.3. Mise en œuvre

Utiliser JUnit Jupiter (version ≥ 5.0)
NF-Req-5

Les tests dynamiques doivent utiliser JUnit Jupiter (version ≥ 5.0) et Jasmine (version ≥ 5.1.0).

Utiliser un framework de Log
NF-Req-6

Le code doit journaliser ses principales opérations en utilisant SLF4J et TypeScript Logging.

2.4. Outils de production

Utiliser un outils de production automatique
NF-Req-7

Tous les artefacts logiciels doivent utiliser un outil de production : Maven (version ≥ 3.9.0) ou Gradle (version ≥ 8.0) pour Java et npm (version ≥ 9.0.0) pour TypeScript.

2.5. Outils de développement

2.6. Bibliothèques et composants logiciels

3. Vérification

  1. Les méthodes du projet doivent être vérifiées grâce aux tests unitaires, indépendamment du langage utilisé. Chaque test unitaire doit décrire clairement son intention.

  2. L’interface (API) des composants ou modules doubles tests doivent être vérifiées grâce aux tests fonctionnels.

  3. Les tests des composants/modules doivent être indépendants des autres composants. Des doublures de test doivent être utilisées pour assurer l’isolation des tests.

4. Documentation utilisateur

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

4.1. Hypothèses et dépendances

Aucune jusqu’à présent.

4.2. Exigences reportées

  1. Les versions futures du logiciel comprendront l’utilisation de différentes interfaces utilisateur : Client Lourd, Smartphones, etc.

5. Exigences en matière d’interface externe

5.1. Interfaces utilisateur

  • Aucune exigence

5.2. Interfaces matérielles

  • Aucune, le logiciel n’interagit pas directement avec un quelconque dispositif matériel.

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

5.4. Interfaces de communication

  • Les communications entre le client et le serveur de jeu doivent utiliser des Websockets.

6. Exigences fonctionnelles

6.1. Fonctionnalité « Joindre une partie »

6.1.1. Description et priorité

Id FR-1

Description

Cette fonctionnalité permet à un joueur de se connecter au serveur de jeu, pour ensuite participer à une partie.

Priorité

Haute

6.1.2. Description sous la forme d’un cas d’utilisation

Cas d’utilisation « Rejoindre une partie »
Item Description

#

1

Cas d’utilisation

Joindre une partie

Alias

Connexion

Objectif contextuel

Portée

Le système

Niveau

Summary

Condition de succès

Le joueur participe à une partie

Condition d’échec

Le joueur n’arrive pas à joindre une partie

Acteurs principaux

Le joueur

Acteurs secondaires

Le serveur

Événement déclencheur

Le joueur souhaite jouer une partie

Priorité

Haute

Fréquence

Une fois par jour

Pré-conditions

  • Le joueur est connecté à Internet

  • Le joueur a une adresse email valide

  • Le serveur est en ligne

Post-conditions

  • Le joueur est connecté au serveur

Scénario nominal

  1. Le joueur ouvre son navigateur et visite le site Trivial Pursuit

  2. Le joueur informe son identifiant et son mot de passe et se connecte au serveur

  3. Le serveur propose une liste de parties disponibles

  4. Le joueur choisit une partie et la rejoint

  5. Le serveur prévient le joueur que la partie va commencer

Extensions

  • [2a] Le joueur n’a pas d’identifiant. Créer un nouveau compte (Cas d’utilisation 11)

  • [2b] Le joueur a oublié son mot de passe. Réinitialiser mot de passe (Cas d’utilisation 12)

Alternatives

Cas d’utilisation supérieur

Aucun

Cas d’utilisation subordonnés

  • Créer un nouveau compte

  • Réinitialiser mot de passe

Objectif de performance

à compléter

Problèmes ouverts

-

Échéancier

Version 1.0

Contraintes

Annexes

6.2. Fonctionnalité « Jouer un tour »

6.2.1. Description et priorité

Id FR-2

Description

Permet à un joueur déjà connecté au Système et affecté à une partie, de jouer à cette partie.

Priorité

Moyenne

6.2.2. Description sous la forme d’un cas d’utilisation

Cas d’utilisation « Jouer un tour »
Item Description

#

2

Cas d’utilisation

Tour de jeu

Description

Les joueurs jouent leurs tours alternativement, plusieurs fois dans une partie. Pendant chaque tour, ils peuvent effectuer plusieurs actions : lancer le dée, déplacer le camembert, répondre à une question.

Niveau

Utilisateur

Portée

Système (Le jeu Trivial Pursuit)

Priorité

Haute

Échéance

Version 1.0.0

Acteurs principaux

  1. Un joueur

Acteurs de soutien

Aucun pour l’instant.

Parties prenantes et intérêts

Aucun pour l’instant.

Pré-conditions

  • Aucun tour d’un autre joueur n’est entamé.

  • Ce le tour de ce joueur

  • Le paquet de cartes est disponible.

  • La partie est en cours.

Post-conditions

Aucune

Condition finale de réussite

  • Le joueur a lancé le dé une our plusieurs fois

  • Le joueur a répondu à une ou plusieurs questions (autant de questions que de lancées de dé)

  • Le joueur a mal répondu à la dernière question et le joueur à gauche commence son tour OU il a remporté la partie

Condition finale d’échec

  • Le joueur n’a répondu à aucune question

  • Le joueur a répondu correctement à la dernière question, mais ce n’est plus son tour

Garanties minimales

  • L’ordre des joueurs reste le même

  • Deux joueurs ne jouent pas leur tour en même temps

  • Le jeu passe au tour du joueur suivant

Événement déclencheur

Le joueur précédent termine son tour OU le joueur commence la partie.

Scénario nominal

  1. Le Système prévient le joueur que c’est son tour

  2. Le joueur demande au Système de lancer le dé

  3. Le Système affiche la valeur obtenue

  4. Le Système propose les destinations (cases) possibles

  5. Le joueur choisit la destination

  6. Le Système affiche le camembert sur la case destination

  7. Le Système tire une carte et affiche une question correspondant à la couleur de la case destination

  8. Le joueur répond à la question

  9. Le Système valide la réponse :

    1. Mauvaise réponse : le tour de ce joueur est fini

    2. Bonne réponse : le joueur recommence son tour

Alternatives

  1. [Alternative à 9b] Le camembert est sur une case « Quartier Général » :

    1. Il remporte un triangle correspond à la couleur de la case, seulement s’il ne possède pas le triangle de couleur correspondant à la case.

    2. Si son camembert est plein[1] : il remporte la partie (elle s’arrête)

1. C’est son 6e triangle

Problèmes ouverts

  • Que faire si un des joueurs abandonne une partie en cours ?

6.3. Fonctionnalité « Créer un compte »

6.3.1. Description et priorité

Id FR-3

6.3.2. Description sous la forme d’un cas d’utilisation

Créer un compte
Item Description

#

11

Cas d’utilisation

Créer un compte

Alias

Inscription

Objectif contextuel

à compléter

Portée

Système

Niveau

Utilisateur

Condition de succès

Le joueur arrive à créer un compte, connait son identifiant et son mot de passe

Conditions d’échec

  • Le joueur n’arrive pas à créer un compte

  • Le joueur crée un compte, mais ne connait pas son identifiant ou son mot de passe/

Acteurs principaux

Le joueur

Acteurs secondaires

Un serveur d’identification

Événement déclencheur

Le joueur souhaite participer à une partie

Priorité

Moyenne

Fréquence

Pré-conditions

  • Le joueur est connecté à Internet et possède une adresse email valide et accessible

Post-conditions

  • Le Système connaît le joueur à travers son identifiant

Scénario nominal

  1. Le joueur demande la création d’un compte

  2. Le joueur saisi son adresse email, son nom, prénom, date de naissance et son mot de passe

  3. Le Système envoie une URL unique à l’adresse email du joueur

  4. Le joueur reçoit l’email et ouvre l’URL

  5. Le serveur reçoit la requête correspondant à l’URL envoyée et valide l’inscription

Extensions

Alternatives

Cas d’utilisation supérieur

Joindre une partie (UC-1, [uc-1])

Cas d’utilisation subordonnés

Aucun

Objectif de performance

-

Problèmes ouverts

Aucun

Échéancier

_Version 1.1

Contraintes

Annexes

6.4. Fonctionnalité « Réinitialiser mot de passe »

6.4.1. Description et priorité

Id

FR-4

6.4.2. Description sous la forme d’un cas d’utilisation

Réinitialiser mot de passe
Item Description

#

12

Cas d’utilisation

Réinitialiser mot de passe

Alias

à compléter

Objectif contextuel

à compléter

Portée

à compléter

Niveau

à compléter

Condition de succès

à compléter

Condition d’échec

à compléter

Acteurs principaux:

à compléter

Acteurs secondaires

à compléter

Événement déclencheur

à compléter

Priorité

à compléter

Fréquence

à compléter

Pré-conditions

  • à compléter

  • à compléter

Post-conditions

  • à compléter

  • à compléter

  • à compléter

Scénario nominal

  1. Le joueur demande au Système la réinitialisation de son mot de passe

  2. Le joueur saisi son identifiant

  3. Le Système envoie une URL unique au joueur

  4. Le joueur ouvre l’URL et saisi son nouveau mot de passe

Extensions

  1. à compléter

  2. à compléter

Alternatives

  • Alternative à 3 : Le joueur n’est pas inscrit, le Système ne fait rien.

Cas d’utilisation supérieur

Joindre une partie (UC-1, [uc-1])

Cas d’utilisation subordonnés

Aucun

Objectif de performance

à compléter

Problèmes ouverts

  • à compléter

  • à compléter

Échéancier

Version 1.1

Contraintes

à compléter

Annexes

à compléter

7. Autres exigences non-fonctionnelles

7.1. Exigences de performance

Jouabilité
NF-Req-8

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.

Efficacité
NF-Req-9

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

7.2. Exigences de sécurité

  • Aucune

7.3. Attributs de qualité logicielle

7.3.1. Extensibilité

7.3.2. Maintenabilité

Le code doit être maintenable
NF-Req-10

Le logiciel doit être lisible et facile à maintenir.

Respect des conventions de codage Java
NF-Req-11

Les sources Java doivent respecter les directives de codage Google.

Les directives de codage Java peuvent être facilement vérifiées grâce à PMD
Respect des conventions de codage TypeScript
NF-Req-12

La source TypeScript doit respecter les directives de codage Google.

Configurez npm pour utiliser ESLint et Prettier, et forcer votre code à respecter des conventions de codage TypeScript.

8. Liste d’exigences

Table 3. Exigences fonctionnelles (4)
Code Titre

FR-1

Section 6.1

FR-2

Section 6.2

FR-3

Section 6.3

FR-4

Section 6.4

FR-5

[freq-5]
Table 4. Exigences non-fonctionnelles (12)
Code Titre

NFR-1

Utiliser le langage Java, version 11 (minimum)

NFR-2

Utiliser le langage TypeScript, version 4 (minimum)

NFR-3

Utiliser Asciidoc

NFR-4

Utiliser PlantUML

NFR-5

Utiliser JUnit Jupiter (version ≥ 5.0)

NFR-6

Utiliser un framework de Log

NFR-7

Utiliser un outils de production automatique

NFR-8

Jouabilité

NFR-9

Efficacité

NFR-10

Le code doit être maintenable

NFR-11

Respect des conventions de codage Java

NFR-12

Respect des conventions de codage TypeScript

Annexe A : Glossaire

Termes

Terme

Description courte

Signification

Camembert

Pièce mobile du plateau de jeu

Il correspond à la position d’un joueur pendant la partie. Il contient 5 cases vides, qui sont remplies pendant la partie par des triangles de couleur différente

Triangle

Pièce triangulaire qui s’emboite à l’intérieur d’un camembert.

Les triangles ont des couleurs différentes qui correspondent aux différentes catégories de question.