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 Autres exigences non-fonctionnelles).
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’une partie
Cette fonctionnalité permet à l’utilisateur authentifié de créer et configurer une nouvelle partie.
Cette fonctionnalité est prioritaire.
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 merveille.
Exigences fonctionnelles
Pour permettre cette fonctionnalité, le logiciel doit intégrer :
-
REQ-1 : Configuration d’une nouvelle partie. Un utilisateur authentifié peut créer un nouvelle partie via l’interface de l’application web. Il pourra configurer les paramètres suivants : nombre de joueurs requis, partie publique ou privée, c’est-à-dire avec ou sans mot de passe, et distribution aléatoire ou non de la face des merveilles aux joueurs.
-
REQ-2 : Création d’un lobby. Une fois une partie configurée, un nouveau lobby doit être créé en enregistrant les paramètres retenus. Ce lobby doit être visible aux autres joueurs sur l’interface de l’application web où sont affichés tous les lobbies. L’utilisateur qui a créé la nouvelle partie doit être automatiquement redirigé vers le lobby associé et être ajouté aux joueurs de la partie. Si l’utilisateur quitte son lobby, il est supprimé. Si la partie n’a pas commencé au bout de 15 min, le lobby est supprimé.
-
REQ-3 : Lancement de la partie. Lorsque tous les joueurs requis sont dans le lobby, ont choisi la face de leur merveille si cette option est activée et ont indiqué qu’ils sont prêts, alors le lobby est supprimé et les joueurs redirigés vers la nouvelle partie.
Description sous la forme d’un cas d’utilisation
| Item | Description |
|---|---|
# |
1 |
Cas d’utilisation |
Création d’un lobby |
Alias |
Aucun |
Objectif contextuel |
Configuration et gestion d’un lobby |
Portée |
Un utilisateur et le serveur |
Niveau |
Tâche principale |
Condition de succès |
Démarrage de la partie |
Condition d’échec |
Un lobby en attente existe déjà pour cet utilisateur, le nom du lobby est déjà prit. |
Acteurs principaux |
Utilisateur et le serveur |
Acteurs secondaires |
Aucun |
Événement déclencheur |
Depuis l’interface de l’application web, avoir clique pour créer une nouvelle partie. |
Priorité |
Maximale |
Fréquence |
Autant de fois qu’un utilisateur veut créer une partie. Un seul lobby peut exister par joueur. |
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 créer une autre partie. |
Post-conditions |
Lobby créé |
Scénario nominal |
Un utilisateur accède à l’interface de création d’un lobby. Il peut configurer le nom de la partie, le nombre de joueurs requis, la distrbution aléatoire ou non de la face de la merveille, si la partie est publique ou privée et le mot de passe associé. Si aucune erreur n’est rencontrée, le lobby est créé et l’utilisateur est ajouté aux joueurs de la partie. Il est redirigé vers l’interface du lobby. |
Extensions |
Aucune |
Alternatives |
Aucune |
Cas d’utilisation supérieur |
Connexion |
Cas d’utilisation subordonnés |
Accéder à un lobby |
Objectif de performance |
Création rapide du lobby |
Problèmes ouverts |
Problèmes de connexion, expiration du lobby (15min). |
Échéancier |
1.0 |
Contraintes |
Un lobby ne peut exister que pour 15 min. Il ne peut exister qu’un lobby par utilisateur à la fois. Le nom du lobby doit être unique par rapport aux autres lobbies actifs. |
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 de voir les parties en attente de joueurs et d’en rejoindre une.
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 à l’application web. Il doit être authentifié pour accéder à la page proposant les parties.
Ensuite, il choisit son mode de jeu, choisis une partie en déffilant 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 merveilles 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é, le logiciel doit intégrer :
-
REQ-1 : Consulter les parties en attente de joueurs. Sur une interface dédiée de l’application web, un utilisateur connectée pourra consulter les parties en attente de joueurs : les lobbies. Cette interface permettra de filtrer les parties publiques et privées. Les informations suivantes seront disponibles pour chaque lobby : nombre de joueurs dans le lobby, nombre de joueurs requis, nom de la partie, type de partie (publique/privée).
-
REQ-2 : Rejoindre une partie privée. Un utilisateur souhaitant rejoindre une partie privée devra saisir le mot de passe du lobby. S’il est incorrect, une erreur sera levée. Sinon, l’utilisateur sera ajouté aux joueurs de la partie et redirigé vers l’interface du lobby. Une merveille lui sera attribué aléatoirement.
-
REQ-3 : Rejoindre une partie publique. Un utilisateur pourra rejoindre une partie publique. Il sera ajouté aux joueurs de la partie et redirigé vers l’interface du lobby. Si le lobby est plein au moment où il souhaite rejoindre, une erreur sera levée. Une merveille lui sera attribué aléatoirement.
-
REQ-4 : Lancement de la partie. Un joueur dans un lobby pourra choisir la face de sa merveille si le lobby le permet. Il pourra indiquer qu’il est prêt. Les informations suivantes seront affichées sur l’interface de l’application web : nom d’utilisateur des joueurs dans le lobby, leur statut (prêt ou non) et leur merveille. Lorsque tous les joueurs seront prêts, la partie se lancera. Si la partie n’est pas lancée au bout de 15 min, le lobby est supprimé, la partie annulée et les utilisateurs redirigés vers l’interface affichant la liste des lobbies.
Description sous la forme d’un cas d’utilisation
| Item | Description |
|---|---|
# |
2 |
Cas d’utilisation |
Accèder à une partie |
Alias |
Rejoindre un lobby |
Objectif contextuel |
Rejoindre une partie, accéder au lobby correspondant |
Portée |
Joueurs dans le lobby et le serveur |
Niveau |
Résumé |
Condition de succès |
Partie rejointe |
Condition d’échec |
Problème de connexion, le lobby n’existe plus, le nombre de joueurs max est atteint |
Acteurs principaux |
Utilisateur souhaitant rejoindre le lobby |
Acteurs secondaires |
Joueurs dans le lobby |
Événement déclencheur |
L’utilisateur connecté rejoint le lobby |
Priorité |
Maximale |
Fréquence |
Un utilisateur peut rejoindre une seule partie à la fois |
Pré-conditions |
L’utilisateur doit possèder un compte et être authentifié, un lobby doit exister. |
Post-conditions |
L’utilisateur accède au lobby et peut effectuer ses choix pour jouer |
Scénario nominal |
Un utilisateur authentifié intéragit avec l’interface de l’application web pour rejoindre un lobby. Si la partie est privée, il doit saisir le mot de passe. En cas d’erreur sur le mot de passe, une erreur est levée. Il est redirigé vers l’interface du lobby. Les informations suivantes sont affichées : nom des joueurs ayant rejoint la partie, leur merveille, s’ils sont prêts ou non. Le joueur peut choisir la face de sa merveille si cette option a été autorisée. Il peut se mettre prêt. Lorsque tous les joueurs sont prêts, la partie se lance. |
Extensions |
Aucune |
Alternatives |
Aucune |
Cas d’utilisation supérieur |
Création d’une partie |
Cas d’utilisation subordonnés |
Déroulement d’une partie |
Objectif de performance |
Choisir efficacement sa partie |
Problèmes ouverts |
Si deux joueurs rejoignent la même partie en même temps, alors qu’il ne reste qu’une place de disponible. |
Échéancier |
Version 1.0 |
Contraintes |
On ne peut rejoindre qu’une partie à la fois. |
Déroulement d’une partie
Cette fonctionnalité permet alors à un joueur de joué au jeu Seven Wonders.
La priorité de cette fonctionnalité est maximale.
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 fonctionne : les risques sont évalués à 7.
Séquences de Stimulus/Réponse
Le joueur accède à sa merveille. Après que chaque joueur ait choisit sa face, la partie commence.
L’utilisateur découvre son plateau, prend connaissance de son nombre de pièces, ses constructions, ses jetons Conflit. Il peut visualiser ces mêmes informations pour les autres joueurs.
Il reçoit le paquet de cartes et intéragit avec.
Exigences fonctionnelles
Pour permettre cette fonctionnalité, le logiciel doit intégrer :
-
REQ-1 : Partie de Seven Wonders en temps réel. Tous les joueurs doivent pouvoir jouer en temps réel et l’interface de l’application web doit se mettre à jour sans rechargement de la page. Les tours doivent se dérouler en simultané pour tous les joueurs : tous les joueurs reçoivent une main de 7 cartes chacun, tous les joueurs peuvent intéragir avec leur main en même en temps. Un tour se conclut lorsque le dernier joueur à intéragit avec sa main. Un âge se termine au bout de 6 tours.
-
REQ-2 : Voir l’état de la merveille des autres joueurs. Chaque joueur pourra voir l’état de la merveille des autres joueurs : bâtiments construits, jetons Conflit, ressources produites, nom du joueur, merveille.
-
REQ-3 : Effectuer des actions. À chaque tour, tous les joueurs tirent une carte de leur main et peuvent construire leur merveille, acheter des ressources, défausser la carte. Toutes ces actions doivent avoir un animation correspondante sur l’interface la partie de l’application web et être visibles de tous les joueurs.
Description sous la forme d’un cas d’utilisation
| Item | Description |
|---|---|
# |
3 |
Cas d’utilisation |
Déroulement d’une partie |
Alias |
Aucun |
Objectif contextuel |
Les joueurs jouent une partie de Seven Wonders. Un vainqueur est désigné à l’issue de la partie. |
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 de l’Âge III |
Condition d’échec |
Ne pas être le joueur avec le plus de points de victoires, des joueurs se déconnectent pendant la partie. |
Acteurs principaux |
Joueurs, entre 3 et 7, et le serveur |
Acteurs secondaires |
Aucun |
Événement déclencheur |
Tous les joueurs sont prêt dans le lobby. |
Priorité |
Maximale |
Fréquence |
On ne peut jouer qu’une partie à la fois |
Pré-conditions |
Une partie doit exister. Le nombre requis d’utilisateurs authentifiés doivent avoir rejoint la partie et s’être mit prêt dans le lobby. La partie est lancée. |
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 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 merveille. À 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 |
Aucune |
Alternatives |
Aucune |
Cas d’utilisation supérieur |
Accéder à une partie |
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 |
Une partie dure 10-30min |
Création d’un compte & connexion
Il s’agit de mettre en évidence comment un utilisateur, d’un point de vue système, peut se créer un compte et s’authentifier.
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 le système.
Cette fonctionnalité n’est pas prioritaire car n’est pas obligatoire.
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 le logiciel 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 à l’application web. Il peut ainsi s’enregistrer en communiquant à l’interface son email, un username et un mot de passe.
Exigences fonctionnelles
Pour permettre cette fonctionnalité, le logiciel doit intégrer :
-
REQ-1 : Création d’un compte. Un utilisateur pourra se créer un compte en entrant son email, son nom d’utilisateur et son mot de passe dans les champs de formulaire de la page dédiée sur l’application web. Le mot de passe devra être unique, le mot de passe et le nom d’utilisateur devront faire au moins 8 caractères. Si les données saisies ne respectent pas ces contraintes, une erreur sera levée.
-
REQ-2 : Connexion à son compte. Un utilisateur ayant un compte pourra s’authentifier en saisissant son email et son mot de passe. Une erreur sera levée si les identifiants sont incorrects.
Description sous la forme d’un cas d’utilisation
Création d’un compte
| Item | Description |
|---|---|
# |
4 |
Cas d’utilisation |
Création d’un compte |
Alias |
Nouveau joueur sur le jeu |
Objectif contextuel |
Création d’un compte, stockage des données de l’utilisateur |
Portée |
L’utilisateur et le serveur |
Niveau |
Tâche intermédiaire |
Condition de succès |
Compte créé |
Condition d’échec |
Problème de connexion, données fournies incorrectes : email déjà utilisé, mot de passe ou nom d’utilisateur ne respecte pas la contrainte d’au moins 8 caractères. |
Acteurs principaux |
Nouvel utilisateur |
Acteurs secondaires |
Aucun |
Événement déclencheur |
Depuis l’interface de l’application web dédiée à la création d’un compte, avoir cliqué sur le bouton d’envoi du formulaire. |
Priorité |
Intermédiaire |
Fréquence |
La création d’un compte intervient une unique fois pour un utilisateur donné |
Pré-conditions |
Ne pas avoir déjà créé un compte |
Post-conditions |
Accéder à la fonctionnalité suivante : connexion |
Scénario nominal |
Sur l’application web, l’utisateur accède à l’interface de création d’un compte depuis et renseigne ses identifiants :
Il confirme l’envoi des données. Son compte est créé et il est redirigé vers l’interface de connexion. |
Extensions |
Aucune |
Alternatives |
Aucune |
Cas d’utilisation supérieur |
Aucun |
Cas d’utilisation subordonnés |
Connexion |
Objectif de performance |
Création du compte rapide : connexion client–serveur efficace |
Problèmes ouverts |
Problèmes de connexion |
Échéancier |
Fonctionnalité non-obligatoire, peut être remise à la version 1.1 |
Contraintes |
Aucune |
Connexion
| Item | Description |
|---|---|
# |
5 |
Cas d’utilisation |
Connexion à son compte |
Alias |
Authentification |
Objectif contextuel |
Connexion à son compte, authentification d’un utilisateur enregistré |
Portée |
L’utilisateur et le serveur |
Niveau |
Tâche intermédiaire |
Condition de succès |
Authentification réalisée avec succès |
Condition d’échec |
Problème de connexion, données fournies incorrectes |
Acteurs principaux |
Utilisateurs enregistrés |
Acteurs secondaires |
Aucun |
Événement déclencheur |
Depuis l’interface de l’application web dédiée à la connexion, avoir cliqué sur le bouton d’envoi du formulaire. |
Priorité |
Intermédiaire |
Fréquence |
La connexion est fréquente : elle est nécessaire à chaque fois que le token d’authentification de l’utilisateur a expiré ou lorsque l’utilisateur s’était déconnecté |
Pré-conditions |
Avoir un compte enregistré |
Post-conditions |
Accéder aux fonctionnalités suivantes : création d’une partie, rejoindre une partie, jouer une partie. |
Scénario nominal |
Sur l’application web, l’utisateur accède à l’interface de connexion et renseigne ses identifiants :
Il confirme l’envoi des données. Le serveur valide son authentification et il est redirigé vers la liste des parties. Si son authentification échoue, une erreur est levée. |
Extensions |
Aucune |
Alternatives |
Aucune |
Cas d’utilisation supérieur |
Création d’un compte |
Cas d’utilisation subordonnés |
Aucun |
Objectif de performance |
Connexion rapide : connexion client–serveur efficace |
Problèmes ouverts |
Problèmes de connexion |
Échéancier |
Fonctionnalité non-obligatoire, peut être remise à la version 1.1 |
Contraintes |
Aucune |
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.
Règles métier
Quelques règles métier notable de Seven Wonders :
-
Vendre une ressource à une cité voisine NE retire PAS au joueur la possibilité de l’utiliser, durant le même tour, pour sa propre construction.
-
Il est possible, durant le même tour, d’acheter une ou plusieurs ressources aux deux cités voisines.
-
Les ressources achetées ne sont utilisables que le tour où elles sont achetées. Les joueurs ne peuvent jamais refuser de commercer.
-
Certains bâtiments commerciaux réduisent le coût unitaire des ressources de 2 à 1 pièce.
-
Si les deux cités voisines d’un joueur produisent une ressource convoitée, il est libre de se fournir chez l’un ou chez l’autre.
-
Pour acheter des ressources, le joueur doit disposer des pièces de monnaie au début du tour. Les pièces gagnées par le commerce lors d’un tour ne peuvent pas être utilisées ce même tour mais seulement à partir du tour suivant.
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. |