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.
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
-
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 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.
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.
Néanmoins, les joueurs de plus bas niveau doivent pouvoir avoir accès à certaines astuces et autres instructions d’aide pour équilibrer leurs expériences de jeu.
Éventuellement un manuel en version numérique devrait toujours être en disposition pour tout type de joueur pendant le déroulement d’une partie.
Environnement opérationnel
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.
Peu importe quel navigateur Web ou système d’exploitation utilisé, tous les joueurs peuvent jouer à un même serveur commun (en anglais "cross-play").
En conséquence, également, il ne devrait y avoir aucun avantage ou désavantage selon le système d’exploitation ou le navigateur Web utilisé.
Enfin, il devrait y avoir une connexion au jeu équilibré et peu demandant pour éviter des problèmes de connexion.
Contraintes de conception et de mise en œuvre
Le développeur doit penser, comme précisé précédemment, aux types d’utilisateurs ayant une faible connexion Internet.
Et faire en sorte que cette faible connexion n’impacte pas la partie de jeu des autres utilisateurs. Par exemple que cela n’interrompt pas une partie de jeu.
Langages de programmation
-
Le serveur de jeu doit être développé en Java (version ≥ 11), en utilisant le https://spring.io [Spring Framework].
-
Le client doit être développé en TypeScript (version ≥ 4.0), en utilisant le https://angular.io [Angular Framework].
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.
Mise en œuvre
-
Les tests dynamiques doivent utiliser JUnit (version >= 5.0) et Jasmine (version >= 3.5.0).
-
Le code doit journaliser ses principales opérations en utilisant https://www.slf4j.org [SLF4J].
Vérification
-
Les doubles tests doivent être utilisés pour tester chaque composant indépendamment.
-
Chaque test unitaire doit décrire son intention.
Documentation utilisateur
Aucune documentation utilisateur n’est requise pour la première version du logiciel.
Exigences reportées
Concernant les documentations : possiblement un manuel du jeu disponible à tout moment pour tout les joueurs à consulter en cas d’incertitude.
Également un didacticiel intégré aux mécanismes de base du jeu, pour tout nouveau joueur qui confirme ne pas connaître les règles de base du jeu.
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. |
Les cartes sont affichés en gros en bas au milieu. Les boutons d’options se situe en petit en haut (une barre). Le plateau se situera au milieu de l’écran. Les actions possible avec les autres joueurs se situeront sur les côtés.
Interfaces matérielles
|
Décrire les caractéristiques logiques et physiques de chaque interface entre le produit logiciel et les composants matériels du système. Cela peut inclure les types de dispositifs pris en charge, la nature des interactions de données et de contrôle entre le logiciel et le matériel, et les protocoles de communication à utiliser. |
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. |
Connexion au serveur
L’objectif est que les joueurs arrive à bien se connecter/déconnecter du serveur
Séquences de Stimulus/Réponse
| Liste des séquences d’actions de l’utilisateur et des réponses du système qui stimulent le comportement défini pour cette fonctionnalité. Celles-ci correspondront aux éléments de dialogue associés aux cas d’utilisation. |
Exigences fonctionnelles
|
Détaillez les exigences fonctionnelles détaillées associées à cette fonctionnalité. Il s’agit des capacités logicielles qui doivent être présentes pour permettre à l’utilisateur d’effectuer les services fournis par la fonction ou d’exécuter le cas d’utilisation. Indiquez comment le produit doit réagir aux conditions d’erreur prévues ou aux entrées non valides. Les exigences doivent être concises, complètes, non ambiguës, vérifiables et nécessaires. Utilisez la mention "A faire" pour indiquer que les informations nécessaires ne sont pas encore disponibles. Chaque exigence doit être identifiée de manière unique par un numéro de séquence ou une étiquette significative.
|
-
REQ-1: Besoin d’être connecter sur la page web
Description sous la forme d’un cas d’utilisation
| Item | Description |
|---|---|
# |
0 |
Cas d’utilisation |
Connexion au serveur et déconnexion au serveur |
Alias |
Connexion et déconnexion au serveur |
Objectif contextuel |
Les joueurs ont réussit à se connecter sur le serveur pour joueur et ont réussit à se déconnecter une fois la partie terminer |
Portée |
Le serveur |
Niveau |
Utilisateur |
Condition de succès |
Les joueurs ont bien réussi à se connecter/déconnecter du serveur |
Condition d’échec |
Les joueurs n’ont pas réussi à se connecter/déconnecter du serveur |
Acteurs principaux: |
Les joueurs |
Acteurs secondaires |
--- |
Événement déclencheur |
Arrivée sur la page web et demande du joueur de se connecter/déconnecter sur un serveur |
Priorité |
3 |
Fréquence |
2 fois par partie, une fois au début pour la connexion, et une fois lorsque la partie est terminé |
Pré-conditions |
|
Post-conditions |
|
Scénario nominal |
|
Extensions |
--- |
Alternatives |
|
Cas d’utilisation supérieur |
--- |
Cas d’utilisation subordonnés |
--- |
Objectif de performance |
--- |
Problèmes ouverts |
|
Échéancier |
--- |
Contraintes |
--- |
Annexes |
--- |
Préparation de la partie
L’objectif ici est de tous mettre en oeuvre pour pouvoir lancer correctement la partie.
Description et priorité
Comme dans le jeu original, ici nous allons distribuer correctement les cartes pour les joueurs et s’assurer que la partie puisse commencer.
La priorité est élevée puisque si cette fonctionnalité n’est pas respecté, nous ne pourrons pas lancer la partie.
Séquences de Stimulus/Réponse
| Liste des séquences d’actions de l’utilisateur et des réponses du système qui stimulent le comportement défini pour cette fonctionnalité. Celles-ci correspondront aux éléments de dialogue associés aux cas d’utilisation. |
Exigences fonctionnelles
|
Détaillez les exigences fonctionnelles détaillées associées à cette fonctionnalité. Il s’agit des capacités logicielles qui doivent être présentes pour permettre à l’utilisateur d’effectuer les services fournis par la fonction ou d’exécuter le cas d’utilisation. Indiquez comment le produit doit réagir aux conditions d’erreur prévues ou aux entrées non valides. Les exigences doivent être concises, complètes, non ambiguës, vérifiables et nécessaires. Utilisez la mention "A faire" pour indiquer que les informations nécessaires ne sont pas encore disponibles. Chaque exigence doit être identifiée de manière unique par un numéro de séquence ou une étiquette significative.
|
-
REQ-1: Besoin d’être connecter sur le serveur "A faire"
-
REQ-2: Besoin que la préparation de la partie soit faites.
Description sous la forme d’un cas d’utilisation
| Item | Description |
|---|---|
# |
1 |
Cas d’utilisation |
Préparation |
Alias |
Initialisation, Mise en place |
Objectif contextuel |
Installer le plateau, avec les cartes, les plateaux et les pièces pour commencer la partie |
Portée |
Le jeu |
Niveau |
Utilisateur |
Condition de succès |
Le jeu est correctement préparé |
Condition d’échec |
Le jeu est mal préparé (mauvaise distribution des cartes/des pieces etc..) |
Acteurs principaux : |
Les joueurs |
Acteurs secondaires |
--- |
Événement déclencheur |
Début de la partie |
Priorité |
1 |
Fréquence |
Une fois par partie |
Pré-conditions |
|
Post-conditions |
|
Scénario nominal |
|
Extensions |
Préparation pour 2 joueurs |
Alternatives |
--- |
Cas d’utilisation supérieur |
--- |
Cas d’utilisation subordonnés |
--- |
Objectif de performance |
--- |
Problèmes ouverts |
|
Échéancier |
--- |
Contraintes |
--- |
Annexes |
Déroulement de la partie
L’objectif est que la partie se déroule correctement
Description et priorité
Chacun leur tours, les joueurs vont choisir une carte qu’ils veulent, puis une fois que tous les joueurs ont choisit leur carte, ont effectue les actions de chaque carte. Si on arrive à la fin d’un âge, on résout chaque conflit militaire, on réinitialise le compteur de tour et on incrémente le compteur d’âge. Si on arrive à la fin de l’âge 3, on compte le nombre de point pour déterminer le gagnant.
Séquences de Stimulus/Réponse
| Liste des séquences d’actions de l’utilisateur et des réponses du système qui stimulent le comportement défini pour cette fonctionnalité. Celles-ci correspondront aux éléments de dialogue associés aux cas d’utilisation. |
Exigences fonctionnelles
|
Détaillez les exigences fonctionnelles détaillées associées à cette fonctionnalité. Il s’agit des capacités logicielles qui doivent être présentes pour permettre à l’utilisateur d’effectuer les services fournis par la fonction ou d’exécuter le cas d’utilisation. Indiquez comment le produit doit réagir aux conditions d’erreur prévues ou aux entrées non valides. Les exigences doivent être concises, complètes, non ambiguës, vérifiables et nécessaires. Utilisez la mention "A faire" pour indiquer que les informations nécessaires ne sont pas encore disponibles. Chaque exigence doit être identifiée de manière unique par un numéro de séquence ou une étiquette significative.
|
-
REQ-1: Besoin d’être connecter sur le serveur "A faire"
Description sous la forme d’un cas d’utilisation
| Item | Description |
|---|---|
# |
2 |
Cas d’utilisation |
Déroulement de la partie |
Alias |
Procédure de déroulement d’un tour |
Objectif contextuel |
Faire en sorte que la partie se déroule correctement et qu’un vainqueur soit désigner |
Portée |
Le jeu |
Niveau |
Utilisateur |
Condition de succès |
Un vainqueur est désigné |
Condition d’échec |
Un tour n’arrive pas à se lancer |
Acteurs principaux: |
Les joueurs |
Acteurs secondaires |
--- |
Événement déclencheur |
Fin de la préparation |
Priorité |
2 |
Fréquence |
Plusieurs fois par partie |
Pré-conditions |
|
Post-conditions |
|
Scénario nominal |
|
Extensions |
--- |
Alternatives |
|
Cas d’utilisation supérieur |
--- |
Cas d’utilisation subordonnés |
--- |
Objectif de performance |
--- |
Problèmes ouverts |
|
Échéancier |
--- |
Contraintes |
--- |
Annexes |
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é
Les modifications des données passeront par des fonctions qui interrogeront le serveur, qui récupèrera les données et les modifiera. Tout ceci en temps réel.
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. |
(à préciser)
Maintenabilité
-
Le logiciel doit être lisible et facile à maintenir.
-
La source Java doit respecter les directives de Google : https://google-styleguide.googlecode.com/svn/trunk/javaguide.html.
Autres exigences
| 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. |
(à préciser)
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. |
(à préciser)
Annexe B : Modèles d’analyse
Voir le chapitre [domain] (analyse du domaine) pour plus de détails.
| En option, inclure tout modèle d’analyse pertinent, tel que des diagrammes de flux de données, des diagrammes de classe, des diagrammes d’état-transition ou des diagrammes entité-relation. |
(à préciser)