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.
Public visé et suggestions de lecture
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.
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.
Le système 7 Wonders entre dans le cadre du projet de fin de semestre du module Analyse, conception et mise en oeuvre de logiciels.
Références
-
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 Exigences fonctionnelles) et les exigences non-fonctionnelles du système (voir [nonfunctional]).
Description générale
Perspectives du produit
7 Wonders est un jeu de cartes 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.
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.
Fonctionnalités du produit
Le logiciel 7 Wonders doit assurer deux fonctions principales :
-
Création de jeu : permettre à deux joueurs de se découvrir et de commencer une partie.
-
Le jeu : permettre aux joueurs de jouer effectivement à 7 Wonders jusqu’à la victoire de l’un d’entre eux.
Les fonctions secondaires du logiciel :
-
Permettre aux joueurs de se créer un compte et de s’authentifier.
-
Permettre aux joueurs de demander d’autres joueurs en ami et d’inviter des amis dans leurs parties.
Les fonctions annexes du logiciel :
-
Permettre à des administrateurs de gérer les parties et les joueurs.
|
Une image des principaux groupes d’exigences connexes et de leurs relations, comme une carte conceptuelle, est souvent utile. |
Caractéristiques et classes d’utilisateurs
Le logiciel 7 Wonders 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.
Potentiellement dans une version ultérieure du logiciel, une classe d’utilisateurs à part, les administrateurs, pourrait voir le jour. Ces utilisateurs spéciaux auraient des droits étendus leur permettant de gérer les parties et les joueurs.
Environnement opérationnel
| Décrivez l’environnement dans lequel le logiciel fonctionnera, y compris la plate-forme matérielle, le système d’exploitation et ses versions, ainsi que tout autre composant logiciel ou application avec lequel il doit coexister pacifiquement. |
Le logiciel 7 Wonders 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.
Contraintes de conception et de mise en œuvre
|
Décrivez tous les éléments ou problèmes qui limiteront les options disponibles pour les développeurs. Il peut s’agir de politiques d’entreprise ou de réglementation, de limitations matérielles (exigences en matière de temps et de mémoire), d’interfaces avec d’autres applications, de technologies, d’outils et de bases de données spécifiques à utiliser, d’opérations parallèles, d’exigences linguistiques, de protocoles de communication, de considérations de sécurité, de conventions de conception ou de normes de programmation (par exemple, si l’organisation du client est responsable de la maintenance du logiciel livré). |
Langages de programmation
-
Le serveur de jeu doit être développé en Java (version ≥ 11), en utilisant le framework Spring.
-
Le client doit être développé en TypeScript (version ≥ 4.0), en utilisant le framework Nuxt.
Langage de conception
-
Les documents sur le développement du logiciel doivent être écrits dans le format
Asciidoc. -
Les diagrammes UML d’analyse, conception et mise en œuvre devront être réalisés en
PlantUML.
Outils de développement
-
Le logiciel de gestion de version Git.
-
Les éditeurs de code VS Code ou Intellij IDEA.
-
La plateforme de lancement d’applications dans des containers Docker.
-
L’application pour tester des API Postman.
Bibliothèques et composants logiciels
Le projet 7 Wonders utilisera les bibliothèques et composants logiciels suivants :
Vérification
-
Les doubles tests doivent être utilisés pour tester chaque composant indépendamment.
-
Chaque test unitaire doit décrire son intention.
Exigences reportées
Sont listées ici les exigences qui pourraient être réalisées dans des versions futures du système.
Tout d’abord, la possible création d’une application mobile sur les différentes plateformes les plus connues comme iOS et Android. De cette exigence pourrait donc naitre la possibilité d’y intégrer un système de tchat en ligne textuel et vocal.
On pourrait également ajouter une interface administrateur pour la gestion et la modération des parties et des joueurs.
Un système de niveau et de classement pourrait voir le jour. Gagner une partie rapporterait de l’expérience et des récompenses.
Exigences en matière d’interface externe
Interfaces utilisateur
|
Décrivez les caractéristiques logiques de chaque interface entre le produit logiciel et les utilisateurs. Il peut s’agir d’exemples d’images d’écran, de normes d’interface graphique ou de guides de style de famille de produits à respecter, de contraintes de disposition des écrans, de boutons et de fonctions standard (p. ex., aide) qui apparaîtront sur chaque écran, de raccourcis clavier, de normes d’affichage des messages d’erreur, etc. Définissez les composants logiciels pour lesquels une interface utilisateur est nécessaire. Les détails de la conception de l’interface utilisateur doivent être documentés dans une spécification d’interface utilisateur distincte. |
Interfaces matérielles
Le logiciel n’interagit pas directement avec un quelconque dispositif matériel.
Exigences fonctionnelles
|
Décrire les exigences fonctionnelles du système qui peuvent être exprimées et langage naturel. Pour plusieurs applications, c’est la partie principale de la SEL et son organisation doit, par conséquent, être bien réfléchie. Elle est habituellement hiérarchisée par caractéristiques, mais elle peut l’être, par utilisateur ou par sous-système. Les exigences fonctionnelles peuvent inclure les caractéristiques, les capacités et la sécurité. Lorsque des outils de développement, tels des référentiels d’exigences ou des outils de modélisation sont utilisés, on peut référer à ces données en indiquant l’endroit et le nom de cet outil. |
|
Ici, il ne s’agit plus de décrire le domaine métier, mais de spécifier ce que le système doit faire. N’oubliez pas qu’il s’agit d’une spécification de que le système doit faire et non pas de comment il le fait. |
Création d’un compte.
Il s’agit de mettre en évidence comment un utilisateur, d’un point de vue système, peut créer et s’authentifier à un compte.
Description et priorité
Cette fonctionnalité permet alors à l’utilisateur, via une page de connexion, la création d’un compte et l’échange de ses données avec notre système. La priorité de cette fonctionnalité est faible du fait de son caractère non obligatoire. Cependant, cette fonctionnalité inclus d’important élément de priorité comme la gestion de la sécurité. Les risques présents sont notament le piratage et donc donc la récupération par tiers de données des utilisateurs. Du fait de l’importance de notre logicielle qui reste pour l’instant simplement dans un cradre universitaire, on estime ce risque à 2.
Séquences de Stimulus/Réponse
L’utilisateur accède via son navigateur à notre site. IL peut ainsi s’enregistrer en communiquant à l’interface son email, un username et un mot de passe.
Exigences fonctionnelles
Pour permettre cette fonctionnalité, notre logiciel doit intégrer :
-
REQ-1: un système d’authentification Ce système stocke les champs demandés : "email, user name, password". L’email doit être valide et unique, le reste des paramètres ne présentent aucune obligation. Si l’email entré n’est pas unique, notre interface renvoie une erreur.
-
REQ-2: une page "login" A FAIRE L’utilisateur accède à ces composants via une page "login" de notre front. Cette page permet ainsi à l’utilisateur d’accèder à toutes ces capacités de manière efficace.
Description sous la forme d’un cas d’utilisation
| Item | Description |
|---|---|
# |
1 |
Cas d’utilisation |
Création d’un compte. |
Alias |
Nouveau joueur sur le jeu. |
Objectif contextuel |
Création d’un compte, envoie de donnée utilisateur. |
Portée |
Le nouveau joueur et le serveur. |
Niveau |
Tâche intermédiaire. |
Condition de succès |
Création du compte réussis. |
Condition d’échec |
Problème de connexion, données fournit incorrect, "email" choisit par le joueur déjà utilisé. |
Acteurs principaux |
Nouveau joueur. |
Acteurs secondaires |
Serveur créant le compte. |
Événement déclencheur |
Avoir accédé à la page "home" du site et cliqué sur le bouton "Register". |
Priorité |
Maximale. |
Fréquence |
On peut creer un compte à n’importe quel moment à condition de fournir un email non utilisé. |
Pré-conditions |
Ne pas avoir de compte déjà affilié à son email. |
Post-conditions |
Accéder aux fonctionnalités du logiciel, création d’une partie (publique/privé), rejoindre partie (publique/privé). |
Scénario nominal |
Via son navigateur, le futur joueur accède à la page "home" de notre logiciel. Il clique alor sur "Register". Ensuite, il doit rentrer trois champs :
Il finit par cliquer sur "Confirmer". Le compte est créé. |
Extensions |
Aucune. |
Alternatives |
On pourrait demander un "username" unique, demander une confirmation de création de compte par email. |
Cas d’utilisation supérieur |
Aucun. |
Cas d’utilisation subordonnés |
Création d’une partie. |
Déroulement d’une partie. |
Objectif de performance |
Création du compte rapide (connexion client - serveur efficace). |
Problèmes ouverts |
Problèmes de connexion ou un joueur qui ne fournit pas une email unique. |
Échéancier |
Version 1.0 |
Contraintes |
La création du compte dure environ 2min. |
Annexes |
Création d’une partie
Cette fonctionnalité permet alors à l’utilisateur authentifié, via notre logiciel, la création d’une partie dite "publique" ou "privé". La priorité de cette fonctionnalité est très forte du fait de son caractère obligatoire pour notre logiciel. Cependant, cette fonctionnalité inclus d’important élément de priorité. On compte en effet l’aspect administrateur du créateur de partie et l’aspect publique ou privé (partie publique accessible uniquement par mot de passe).
Les risques présents sont notament les erreurs réseaux. Cependant, du fait du peu d’utilisateur que nous avons actuellement, on estime ce risque à 4.
Séquences de Stimulus/Réponse
L’utilisateur accède à la page de création de partie. Il peut ainsi choisir entre une partie publique ou privé en communiquant à l’interface son email, un username et un mot de passe. Dans le cas d’une partie privé, il recoit un mot de passe unique. Ce sera à lui de transmettre ce mot de passe via un interface de communication tierce. Une fois la partie créé, l’utilisateur (alors administrateur de la partie) gère le lobby. Il peut choisir le nombre de joueur et sa civilisation.
Exigences fonctionnelles
Pour permettre cette fonctionnalité, notre logiciel doit intégrer :
-
REQ-1: Une gestion des parties. A FAIRE
Ce système doit permettre à l’utilisateur de creer simplement une partie via une interface adapté.
-
REQ-2: Permettre dans le lobby de consulter la liste des joueurs présents. A FAIRE
-
REQ-3: Permettre à tous les utilisateurs de choisir sa civilisation et d’afficher les civilisations déjà réservé. A FAIRE
-
REQ-4: Se définir comme prêt à jouer. A FAIRE
Description sous la forme d’un cas d’utilisation
| Item | Description |
|---|---|
# |
2 |
Cas d’utilisation |
Création d’un lobby. |
Alias |
Création d’un lobby et démarrage de la partie. |
Objectif contextuel |
Création et gestion du lobby. |
Portée |
Le nouveau joueur et le serveur. |
Niveau |
Tâche principale. |
Condition de succès |
Démmarage de la partie réussi. |
Condition d’échec |
Problème de connexion. Le nombre de joueur ayant rejoins la partie n’est pas suffisant (15 minutes de délais). |
Acteurs principaux: |
Joueurs hôte de la partie, il peut creer et supprimer sa partie à tout moment dans le lobby. Le serveur. |
Acteurs secondaires |
Les joueurs ayant accès au mot de passe de la partie privé. |
Événement déclencheur |
Avoir selectionné "Création partie" engendrant la création du lobby. |
Priorité |
Maximale |
Fréquence |
On ne peut creer qu’un seul lobby au même momment. |
Pré-conditions |
Avoir un compte, être authentifié, ne pas être dans une partie déjà en cours, ne pas déjà être en train de creer une autre partie. |
Post-conditions |
Lancement de la partie. Erreur la partie n’a pas été lancé dans les temps (15min maximum). |
Scénario nominal |
Un joueur clique sur création d’une partie. Le joueur accède donc au lobby Il peut :
|
Extensions |
Aucune. |
Alternatives |
Partie publique, pas de mot passe à communiquer. |
Cas d’utilisation supérieur |
Création d’un compte. |
Cas d’utilisation subordonnés |
Déroulement d’une partie. |
Objectif de performance |
Lancer le plus rapidement possible. |
Problèmes ouverts |
Problèmes de connexion, timout du lobby (15min). |
Échéancier |
1.0 |
Contraintes |
Une partie privé non lancé reste ouverte 15min maximum avant de supprimer la partie et d’éjecter les joueurs. |
Accéder à une partie.
Il s’agit de mettre en évidence comment un utilisateur connecté, d’un point de vue système, peut accéder à une partie publique ou privé.
Description et priorité
Cette fonctionnalité permet alors à l’utilisateur, via une page de partie, d’accéder à l’une d’entre elle. Il peut alors choisir entre privé et publique. S’il souhaite accéder à une partie privé, il doit fournir le mot de passe choisis par l’hôte.
La priorité de cette fonctionnalité est maximale car essentiel dans le jeu. Les risques présents sont notament les erreurs réseaux. Cependant, du fait du peu d’utilisateur que nous avons actuellement, on estime ce risque à 4.
Séquences de Stimulus/Réponse
L’utilisateur accède via son navigateur à notre site. Il doit être authentifié pour accéder à la page des proposant les parties Ensuite, il choisi son mode de jeu, choisis une partie en défilalnt la liste des parties publiques en attente de joueurs ou fournit directement un mot de passe indentifiant une partie privé. Il accède ansuite au lobby où il va pouvoir consulter la liste de joueurs présent, le nom de l’hôte, les civilisations de chaque joueurs présent et celles qui sont encore disponible. Il va ensuite pouvoir se metrre sur "Prêt" et attendre que chanque joueur en face de même.
Exigences fonctionnelles
Pour permettre cette fonctionnalité, notre logiciel doit intégrer :
-
REQ-1: Une page proposant les eux modes de partie A FAIRE Ce système stocke parties publique en ofrant la possiblité au joueurs de les afficher.
-
REQ-2: Un composant pour rejoindre une partie prifé via le mot de passe A FAIRE L’utilisateur doit pouvoir écrire le mot de passe dans un encadré. S’il se trompe de mot de passe, une erreur doit s’afficher.
Description sous la forme d’un cas d’utilisation
| Item | Description |
|---|---|
# |
3 |
Cas d’utilisation |
Déroulement d’une partie |
Alias |
Partie publique et lobby. |
Objectif contextuel |
Déroulement d’une partie publique ou privé. |
Portée |
Serveur et joueurs dans la partie. |
Niveau |
Résumé. |
Condition de succès |
Être le joueur avec le plus de points de victoires à la fin du troisième Âge. |
Condition d’échec |
Ne pas être le joueur avec le plus de points de victoires. Problème de connexion, joueurs deconnecté entrainant un nombre insuffisant pour ce mode de jeux (min 2 joueurs). |
Acteurs principaux: |
Joueurs, entre 3 et 7. |
Acteurs secondaires |
Aucun. |
Événement déclencheur |
Tousles joueurs ont cliqué sur "Prêt" dans le lobby entrainant le démmarage de la partie. |
Priorité |
Maximale. |
Fréquence |
Pas de limite pour le nombre de parties. |
Pré-conditions |
Un joueur authetifié doit avoir créé le Lobby et si nous sommes dans le cas d’une partie privé, il doit avoir partagé le mot de passe. Ensuite, il faut le nombre de joueurs indiqué par l’hôte. Ces joueurs doivent être authentifié et doivent avoir choisis leur civilisations. Enfin, chaque joueurs doit avoir cliqué sur "Prêt" pour lancer le jeu. |
Post-conditions |
Le vainqueur est désigné. Il s’agit du joueur avec le plus de points de victoires. À la fin de la partie, les items suivants sont compté automatiquement par le logiciel en points de victoire :
Le jeu établit alors le classement des joueurs. |
Scénario nominal |
Le jeu se déroule en trois Âges. La partie commence à l’Âge I et se termine à la fin de l’Âge III. Durant un Âge, les joueurs jouent 7 cartes qui contribuent à améliorer leur civilisation. À la fin de chaque Âge a lieu une phase de bataille où les joueurs voisins opposent leur nom de points militaires. Les vainqueurs gagnent un bonus de points de victoires, les perdants un malus. |
Extensions |
Aucunes |
Alternatives |
|
Cas d’utilisation supérieur |
Création d’un compte. Création du lobby. |
Cas d’utilisation subordonnés |
Aucun. |
Objectif de performance |
À chaque tour du joueur, l’objectif est d’accumuler le plus de points de victoire afin de remporter la partie. |
Problèmes ouverts |
Aucuns. |
Échéancier |
Version 1.0 |
Contraintes |
Il faut au minimum 3 joueurs et au plus 7 joueurs. Une partie dure 10-30min. |
Déroulement d’une partie
Cette fonctionnalité permet alors à l’utilisateur authentifié, ayant accédé au lobby d’une partie publique ou privé de jouer.
La priorité de cette fonctionnalité est très forte du fait de son caractère obligatoire pour notre logiciel. Le principal élément de cette fonctionnalité doit permettre la connexion des joueurs. De plus, il faut pouvoir jouer avec les autres utilisateurs en temps réel. Ces éléments sont très importants et doivent parfaitement fonctionner. Les risque sont évalués à 7.
Séquences de Stimulus/Réponse
L’utilisateur accède à sa civilisation. Après que chaque joueur a choisi sa face, la partie commence. L’utilisateur à donc accès à son plateau, sa reserve de pièce, ses construction actuelles (au nombre de 0 en début de partie) et les nom de ses voisins. IL peut alors recevoir son paquet de carte virtuel et interargir avec.
Exigences fonctionnelles
Pour permettre cette fonctionnalité, notre logiciel doit intégrer :
-
REQ-1: Une gestion de la partie en temps réel. A FAIRE Ce système doit permettre à l’utilisateur de joueur en même temps que ces adversaires.
-
REQ-2: Permettre de consulter la liste des joueurs présents. A FAIRE
-
REQ-3: Permettre de consulter ses voisins. A FAIRE
-
REQ-4: Permettre d’affectuer les actions du jeux tel que tire carte, construire carte/merveille, acheter ressources, payer ressources, défausser carte. A FAIRE
Description sous la forme d’un cas d’utilisation
| Item | Description |
|---|---|
# |
4 |
Cas d’utilisation |
Déroulement d’une partie |
Alias |
Partie publique et lobby. |
Objectif contextuel |
Déroulement d’une partie publique ou privé. |
Portée |
Serveur et joueurs dans la partie. |
Niveau |
Résumé. |
Condition de succès |
Être le joueur avec le plus de points de victoires à la fin du troisième Âge. |
Condition d’échec |
Ne pas être le joueur avec le plus de points de victoires. Problème de connexion, joueurs deconnecté entrainant un nombre insuffisant pour ce mode de jeux (min 2 joueurs). |
Acteurs principaux: |
Joueurs, entre 3 et 7. |
Acteurs secondaires |
Aucun. |
Événement déclencheur |
Tous les joueurs ont cliqué sur "Prêt" dans le lobby entrainant le démmarage de la partie. |
Priorité |
Maximale. |
Fréquence |
Pas de limite pour le nombre de parties. |
Pré-conditions |
Un joueur authentifié doit avoir créé le Lobby et si nous sommes dans le cas d’une partie privé, il doit avoir partagé le mot de passe. Ensuite, il faut le nombre de joueurs indiqué par l’hôte. Ces joueurs doivent être authentifié et doivent avoir choisis leur civilisations. Enfin, chaque joueurs doit avoir cliqué sur "Prêt" pour lancer le jeu. |
Post-conditions |
Le vainqueur est désigné. Il s’agit du joueur avec le plus de points de victoires. À la fin de la partie, les items suivants sont compté automatiquement par le logiciel en points de victoire :
Le jeu établit alors le classement des joueurs. |
Scénario nominal |
Le jeu se déroule en trois Âges. La partie commence à l’Âge I et se termine à la fin de l’Âge III. Durant un Âge, les joueurs jouent 7 cartes qui contribuent à améliorer leur civilisation. À la fin de chaque Âge a lieu une phase de bataille où les joueurs voisins opposent leur nom de points militaires. Les vainqueurs gagnent un bonus de points de victoires, les perdants un malus. |
Extensions |
Aucunes |
Alternatives |
|
Cas d’utilisation supérieur |
Création d’un compte. Création du lobby. |
Cas d’utilisation subordonnés |
Aucun. |
Objectif de performance |
À chaque tour du joueur, l’objectif est d’accumuler le plus de points de victoire afin de remporter la partie. |
Problèmes ouverts |
Aucuns. |
Échéancier |
Version 1.0 |
Contraintes |
Il faut au minimum 3 joueurs et au plus 7 joueurs. Une partie dure 10-30min. |
Autres exigences non-fonctionnelles
Exigences de performance
-
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.
-
Le client Web doit pouvoir s’exécuter sur un ordinateur personnel doté de 4 Go de RAM.
Exigences de sécurité
La création d’un compte utilisateur et donc le stockage de données personnelles telles que l’adresse mail doit respecter les règles européennes sur la protection des données (RGPD).
En particulier, la méthode d’authentification doit mettre en oeuvre toutes les mesures nécessaires pour assurer la sécurité du logiciel.
On utilisera HTTPS pour la communication client–serveur.
Attributs de qualité logicielle
|
Précisez toute autre caractéristique de qualité du produit qui sera importante pour les clients ou les développeurs. En voici quelques-unes : adaptabilité, disponibilité, exactitude, flexibilité, interopérabilité, maintenabilité, portabilité, fiabilité, réutilisabilité, robustesse, testabilité et convivialité. Rédigez-les de manière à ce qu’elles soient spécifiques, quantitatives et vérifiables, si possible. Au minimum, clarifiez les préférences relatives pour divers attributs, comme la facilité d’utilisation par rapport à la facilité d’apprentissage. |
Extensibilité
Le logiciel devra respecter toutes les bonnes pratiques qui permettent son extensibilité.
Maintenabilité
-
Le logiciel doit être lisible et facile à maintenir.
-
La source Java doit respecter les directives de Google.
Autres exigences
La base de données devra respecter les bonnes pratiques en la matière.
| Définissez toute autre exigence non couverte ailleurs dans le SRS. Il peut s’agir d’exigences relatives à la base de données, à l’internationalisation, à la législation, aux objectifs de réutilisation du projet, etc. Ajoutez toute nouvelle section pertinente pour le projet. |
Annexe A : Glossaire
| Définissez tous les termes nécessaires pour interpréter correctement le SRS, y compris les acronymes et les abréviations. Vous pouvez créer un glossaire distinct couvrant plusieurs projets ou l’ensemble de l’organisation, et vous contenter d’inclure les termes spécifiques à un seul projet dans chaque SRS. |