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

Identifier le produit dont les exigences logicielles sont spécifiées dans ce document, y compris le numéro de révision ou de version. Décrire l’étendue du produit couvert par ce SRS, en particulier si ce SRS ne décrit qu’une partie du système ou un seul sous-système.

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

Décrivez toutes les normes ou conventions typographiques qui ont été suivies lors de la rédaction de ce SRS, telles que les polices de caractères ou les mises en évidence qui ont une signification particulière. Par exemple, indiquez si les priorités des exigences de niveau supérieur sont supposées être héritées par les exigences détaillées, ou si chaque énoncé d’exigence doit avoir sa propre priorité.

Aucune jusqu’à présent.

Public visé et suggestions de lecture

Décrire les différents types de lecteurs auxquels le document est destiné, tels que les développeurs, les chefs de projet, le personnel du marketing, les utilisateurs, les testeurs et les rédacteurs de la documentation.

Décrivez le contenu et l’organisation du reste de ce SRS. Suggérer un ordre de lecture du document, en commençant par les sections d’aperçu et en poursuivant par les sections les plus pertinentes pour chaque type de lecteur.

Portée du projet

Fournissez une brève description du logiciel spécifié et de son objectif, y compris les avantages, les objectifs et les buts pertinents. Reliez le logiciel aux objectifs de l’entreprise ou aux stratégies commerciales. Si vous disposez d’un document distinct sur la vision et la portée, faites-y référence plutôt que d’en reproduire le contenu ici.

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.

Références

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

Énumérez tous les autres documents ou adresses Web auxquels ce SRS fait référence. Il peut s’agir de guides de style d’interface utilisateur, de contrats, de normes, de spécifications des exigences du système, de documents de cas d’utilisation ou d’un document sur la vision et la portée. Fournissez suffisamment d’informations pour que le lecteur puisse accéder à une copie de chaque référence, notamment le titre, l’auteur, le numéro de version, la date et la source ou l’emplacement.

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].

Organisation du chapitre

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

Améliorez le diagramme de déploiement pour qu’il représente le système que vous allez développer.

Pour plus de détails sur les diagrammes de déploiement :

https://www.uml-diagrams.org/deployment-diagrams-overview.html

Figure 1. UML Diagramme de déploiement

Décrivez le contexte et l’origine du produit spécifié dans ce SRS. Par exemple, indiquez si ce produit est un membre suivant d’une famille de produits, un remplacement de certains systèmes existants ou un nouveau produit autonome.

Si le SRS définit un composant d’un système plus vaste, faites le lien entre les exigences du système plus vaste et la fonctionnalité de ce logiciel et identifiez les interfaces entre les deux. Un diagramme simple qui montre les principaux composants du système global, les interconnexions des sous-systèmes et les interfaces externes peut être utile.

Fonctionnalités du produit

Résumez les principales fonctions que le produit doit exécuter ou doit permettre à l’utilisateur d’exécuter. Les détails seront fournis à la section 3, aussi seul un résumé de haut niveau (comme une liste à puces) est nécessaire ici.

Organisez les fonctions de manière à ce qu’elles soient compréhensibles pour tout lecteur du SRS.

Le logiciel Les colons de Catane 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 à Les colons de Catane jusqu’à la victoire de l’un d’entre eux.

Il s’agit ici d’une vue générale des fonctionnalités et non de leur description détaillée.

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

Identifiez les différentes classes d’utilisateurs qui, selon vous, utiliseront ce produit. Les classes d’utilisateurs peuvent être différenciées en fonction de la fréquence d’utilisation, du sous-ensemble de fonctions du produit utilisé, de l’expertise technique, des niveaux de sécurité ou de privilège, du niveau d’éducation ou de l’expérience. Décrivez les caractéristiques pertinentes de chaque classe d’utilisateurs. Certaines exigences peuvent ne concerner que certaines classes d’utilisateurs. Distinguez les classes d’utilisateurs les plus importantes pour ce produit de celles qui sont moins importantes à satisfaire.

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.

TODO: Complétez la description ci-dessus

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

TODO: Complétez la description ci-dessus

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

Conception

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].

Outils de construction

Tous les artefacts logiciels doivent utiliser un outil de construction : Maven ou Groovy pour Java, npm pour TypeScript.

Outils de développement

Bibliothèques et composants logiciels

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

Dressez la liste des composants de la documentation utilisateur (tels que les manuels d’utilisation, l’aide en ligne et les didacticiels) qui seront fournis avec le logiciel. Identifiez tous les formats ou normes connus de livraison de la documentation utilisateur.

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

Hypothèses et dépendances

Dressez la liste de tous les facteurs supposés (par opposition aux faits connus) qui pourraient affecter les exigences énoncées dans le SRS. Il peut s’agir de composants tiers ou commerciaux que vous prévoyez d’utiliser, de problèmes liés à l’environnement de développement ou d’exploitation, ou de contraintes. Le projet pourrait être affecté si ces hypothèses sont incorrectes, ne sont pas partagées ou changent. Identifiez également toutes les dépendances du projet vis-à-vis de facteurs externes, tels que les composants logiciels que vous avez l’intention de réutiliser à partir d’un autre projet, à moins qu’elles ne soient déjà documentées ailleurs (par exemple, dans le document de vision et de portée ou dans le plan de projet).

Aucun jusqu’à présent.

Exigences reportées

Énumérer les exigences qui peuvent être réalisées dans des versions futures du système. 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.

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

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.

Interfaces logicielles

Décrivez les connexions entre ce produit et d’autres composants logiciels spécifiques (nom et version), y compris les bases de données, les systèmes d’exploitation, les outils, les bibliothèques et les composants commerciaux intégrés. Identifiez les éléments de données ou les messages qui entrent dans le système et qui en sortent et décrivez le but de chacun. Décrivez les services nécessaires et la nature des communications.

Se référer aux documents qui décrivent les protocoles détaillés des interfaces de programmation d’applications. Identifiez les données qui seront partagées entre les composants logiciels.

Si le mécanisme de partage des données doit être mis en œuvre d’une manière spécifique (par exemple, l’utilisation d’une zone de données globale dans un système d’exploitation multitâche), spécifiez-le comme une contrainte de mise en œuvre.

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

Décrivez les exigences associées à toute fonction de communication requise par ce produit, notamment le courrier électronique, le navigateur Web, les protocoles de communication des serveurs de réseau, les formulaires électroniques, etc. Définissez tout formatage pertinent des messages. Identifiez les normes de communication qui seront utilisées, telles que FTP ou HTTP. Précisez les problèmes de sécurité ou de cryptage des communications, les taux de transfert des données et les mécanismes de synchronisation.

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

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.

Fonctionnalité Connexion au serveur

Ajoutez la description de la fonctionnalité "Connexion au serveur".

Ne dites pas vraiment "Fonctionnalité A". Indiquez le nom de la fonctionnalité en quelques mots seulement.

Description et priorité

Fournissez une brève description de la fonctionnalité et indiquez si elle a une priorité élevée, moyenne ou faible. Vous pouvez également inclure des évaluations spécifiques des éléments de priorité, comme les avantages, les pénalités, les coûts et les risques (chacun étant évalué sur une échelle relative allant de 1 à 9).

Cette fonctionnalité doit permettre aux joueurs d’accéder à une interface web, qui devra communiquer avec un serveur de jeu.

Elle a une priorité élevée, car si un joueur ne peut pas se connecter au serveur, alors il ne pourra pas pas jouer.

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.

Séquence 1 : (connexion au serveur de jeu établie)

Séquence 2 : (connexion au serveur de jeu non établie)

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 1. Cas d’utilisation Connexion au serveur
Item	Description
#	1
Cas d’utilisation	Connexion au serveur
Alias	ConnexionServeur
Objectif contextuel	Un joueur se connecte à un serveur de jeu
Portée	à compléter
Niveau	Primary task
Condition de succès	Le serveur satisfait la demande de connexion du joueur
Condition d’échec	Le serveur ne satisfait pas la demande de connexion du joueur
Acteurs principaux:	Le joueur et le serveur de jeu
Acteurs secondaires
Événement déclencheur	Le joueur demande la connexion au serveur de jeu
Priorité	High
Fréquence	nbDeJoueurs/Jour
Pré-conditions	Informations sur le serveur Informations sur le joueur
Post-conditions	Le serveur est toujours actif Le joueur est connecté au serveur
Scénario nominal	Le joueur demande la connexion au serveur de jeu Le serveur y répond positivement Le joueur se connecte
Extensions
Alternatives
Cas d’utilisation supérieur
Cas d’utilisation subordonnés	GameManagement
Objectif de performance	< 500ms temps de requête, < 2sec temps de connexion
Problèmes ouverts	Que se passe-t-il si le serveur crash ? Que se passe-t-il si le serveur ne répond pas ?
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Choix d’une partie

Ajoutez la description de la fonctionnalité "Choix d’une partie" en vous basant sur la structure de la fonctionnalité "Connexion au serveur"

Description et priorité

Cette fonctionnalité doit permettre à l’utilisateur de : 1 - soit créer une partie 2 - soit de rejoindre une partie existante via l’interface web du serveur de jeu.

Elle a une priorité élevée, car un joueur ne peut pas jouer s’il ne peut pas créer ou rejoindre une partie.

Séquences de Stimulus/Réponse

Séquence 1 : (affichage du menu et création d’une partie validés)

Séquence 2 : (affichage du menu et rejoindre une partie validés)

Séquence 3 : (affichage du menu réussi et échec de la création d’une partie)

Séquence 4 : (affichage du menu réussi et échec de rejoindre une partie)

Séquence 5 : (échec de l’affichage du menu)

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 2. Cas d’utilisation Choix d’une partie
Item	Description
#	1
Cas d’utilisation	Choix d’une partie
Alias	ChoixPartie
Objectif contextuel	Un joueur peut décider de créer ou de rejoindre une partie
Portée
Niveau	Summary
Condition de succès	Le serveur de jeu valide le choix du joueur (créer ou rejoindre une partie)
Condition d’échec	Le serveur de jeu ne valide pas le choix du joueur (créer ou rejoindre une partie)
Acteurs principaux:	Le joueur et le serveur de jeu
Acteurs secondaires
Événement déclencheur	Choix du type de partie (création ou rejoindre une déjà existante)
Priorité	High
Fréquence	nbDeJoueurs/Jour
Pré-conditions	Le joueur doit être connecté au serveur de jeu
Post-conditions	Le serveur de jeu doit valider le choix du joueur (créer ou rejoindre une partie)
Scénario nominal	Le joueur choisi de créer une partie Le serveur de jeu valide ce choix Le joueur choisi de rejoindre une partie Le serveur de jeu valide ce choix
Extensions
Alternatives
Cas d’utilisation supérieur	LobbyManager
Cas d’utilisation subordonnés	LobbyConnection
Objectif de performance	Temps de réponse <2sec
Problèmes ouverts	Que se passe-t-il si un joueur se déconnecte après avoir fait son choix ? Que se passe-t-il en cas de crash du serveur ?
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Mise en place d’une partie

Séquences de Stimulus/Réponse

Séquence 1 : (connexion au serveur de jeu établie)

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 3. Cas d’utilisation Mise en place d’une partie
Item	Description
#	2
Cas d’utilisation	Mise en place d’une partie
Alias	GameSetUp
Objectif contextuel	La partie est mise en place dans le lobby, les joueurs rejoignent la partie et la préparation sera différente en fonction du nombre de joueur. Il est nécessaire d’avoir 3 joueurs dans le lobby pour pouvoir commencer la partie le lancement se fait lorsque tous les joueurs sont prêts
Portée
Niveau	Summary
Condition de succès	Succès de la connection joueurs/serveur, websocket initié Lancement de la partie réussie
Condition d’échec	Échec de la connexion Erreur lors du lancement de la partie
Acteurs principaux:	Lobby, joueurs
Acteurs secondaires	LobbyManager
Événement déclencheur	Rejoindre une partie
Priorité	High
Fréquence	nbDePartie/Jour
Pré-conditions	Informations sur le lobby
Post-conditions	Les joueurs sont connectés Lobby toujours actif Partie prête
Scénario nominal	Les joueurs se connectent au lobby Les joueurs choisissent une ville Les joueurs se mettent prêt La partie se lance Distribution des cartes du premier âge
Extensions	Les joueurs peuvent choisir la même ville Il n’y a pas forcément 7 joueurs, la préparation peut être différente
Alternatives	La répartition des villes peut être aléatoire
Cas d’utilisation supérieur	LobbyManager
Cas d’utilisation subordonnés	LobbyConnection
Objectif de performance	Lancement <5sec
Problèmes ouverts	Que se passe-t-il si un joueur se déconnecte pendant le lancement ? Que se passe-t-il en cas de crash serveur ?
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Connexion d’un joueur à un lobby

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 4. Cas d’utilisation Connexion d’un joueur à un lobby
Item	Description
#	1
Cas d’utilisation	Connexion d’un joueur à un lobby
Alias	LobbyConnection
Objectif contextuel	Un joueur se connecte à un lobby disponible
Portée	Le lobbyManager doit être capable de gérer les connexions des joueurs au lobby. Il est capital que la connexion soit réussie. Le lobby doit aussi gérer les informations des joueurs pour avoir les prérequis nécessaires au lancement de la partie.
Niveau	Primary task
Condition de succès	Connexion réussie, websocket initiée
Condition d’échec	Échec de la connexion, code d’erreur
Acteurs principaux	Lobby manager, lobby, joueur
Acteurs secondaires
Événement déclencheur	Requête de connexion du joueur à un lobby
Priorité	High
Fréquence	nbDeJoueurs/Jour
Pré-conditions	Informations sur le lobby Informations sur le joueur
Post-conditions	Lobby toujours actif Le lobby n’a pas commencé la partie Le joueur est connecté au lobby
Scénario nominal	Un joueur trouve un lobby Le joueur envoie une requête d’inscription à un lobby La requête est acceptée, il reçoit son token Les infos du joueur sont transmises au lobby Le joueur se connecte Le websocket entre le joueur et le lobby est initié
Extensions	Il peut y avoir plusieurs lobbys Le lobby peut être plein le temps de traitement de la requête La partie peut avoir démarrée le temps de la requête
Alternatives
Cas d’utilisation supérieur	LobbyManager
Cas d’utilisation subordonnés	GameManagement
Objectif de performance	< 500ms temps de requête, < 2sec temps de connexion
Problèmes ouverts	Que se passe-t-il si le lobby crash ? Que se passe-t-il si le lobby ne répond pas ?
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Acheter une carte Developpement

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 5. Cas d’utilisation Acheter une carte Developpement
Item	Description
#	9
Cas d’utilisation	Acheter une carte developement
Alias	buyDevCard
Objectif contextuel	Game
Portée	La Game doit être capable de vérifier si le joueur acheteur a les ressources pour acheter une carte developement.
Niveau	Secondary task
Condition de succès	La Game vérifie si le joueur acheteur a les ressources pour acheter une carte developement . L’acheteur obtient la carte developement et les ressources nécessaire à l’achat sont soustrait aux ressources du joueur .
Condition d’échec	L’acheteur ne possède pas les ressources nécessaires pour acheter une carte developement. Code erreur.
Acteurs principaux:	Le joueur acheteur et la Game
Acteurs secondaires
Événement déclencheur	Un joueur souhaite acheter une carte developement
Priorité	Middle
Fréquence	Dans la limite des stocks disponibles
Pré-conditions	L’acheteur doit avoir les ressources demandé La pioche des cartes developement ne doit pas être vide
Post-conditions	L’achat est enregistré La carte developement est transfert vers l’acheteur et les ressources sont débitées
Scénario nominal	Un joueur veut obtenir une carte developement La Game vérifie si l’acheteur possède les ressources demandées Le transfert de ressource est effectué Le joueur reçoit ça carte developement
Extensions	Un joueur peut acheter plusieurs fois dans le même tour
Alternatives
Cas d’utilisation supérieur	Obtenir-carte-developement
Cas d’utilisation subordonnés
Objectif de performance	< 500ms
Problèmes ouverts	-
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Echanger une carte

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 6. Cas d’utilisation Echanger une carte
Item	Description
#	10
Cas d’utilisation	Echanger une carte
Alias	EchangeCarte
Objectif contextuel	Un joueur échange à un autre joueur une carte durant un tour de jeu.
Portée	La Game doit être capable de vérifier si le joueur à des cartes à échanger pour échanger avec un autre joueur
Niveau	Secondary task
Condition de succès	L’initiateur obtient la carte voulu et le vendeur récupère la carte échangée.
Condition d’échec	L’acheteur ne possède pas de carte à échanger pour échanger avec un autre joueur. Code erreur.
Acteurs principaux:	Le joueur initiateur de l’échanger et le joueur qui accepte l’échange.
Acteurs secondaires
Événement déclencheur	Un joueur souhaite échanger une de ses cartes contre une carte d’un autre joueur
Priorité	Middle
Fréquence	Dans la limite des stocks disponible
Pré-conditions	L’initiateur de l’échange doit avoir des cartes Le joueur qui accepte l’échange doit avoir des cartes
Post-conditions	La vente est enregistré Les cartes sont transférées d’un joueur à l’autre
Scénario nominal	Un joueur regarde les cartes échangeable d’un autre joueur Le joueur selectionne la carte qui l’intéresse La Game vérifie si le joueur solicité par l’initiateur de l’échange accepte l’échange de carte Le transfert de carte est effectué
Extensions	Un joueur peut échanger plusieurs fois dans le même tour
Alternatives
Cas d’utilisation supérieur
Cas d’utilisation subordonnés	ConstructionBatimentParChainage ConstructionBatimentParRessources ConstructionMerveille
Objectif de performance	< 500ms temps de requête
Problèmes ouverts
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Jouer une carte

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 7. Cas d’utilisation Jouer une carte
Item	Description
#	4
Cas d’utilisation	Le joueur doit jouer une carte
Alias	playCard
Objectif contextuel	Le joueur doit jouer une carte de sa main au cours du tour en cours. La carte jouée par le joueur n’a pas toujours la même action. Il existe 3 actions différentes : Recupérer des ressources vià des cartes de ressources, Effectuer les actions des cartes Progrès, Déplacer le pion voleur en utilisant une carte chevalier.
Portée	Game
Niveau	Tâche principale
Condition de succès	La carte du joueur a été jouée et a fait l’action escomptée
Condition d’échec	La carte n’a pas été jouée ou n’a pas fait la bonne action
Acteurs principaux:	Game, joueur
Acteurs secondaires
Événement déclencheur	Début de tour
Priorité	Forte priorité
Fréquence	Zéro ou plusieurs fois par tour
Pré-conditions	Les échanges commerciaux ont été fait préalablement Le joueur doit avoir des cartes dans sa main Le joueur doit remplir les conditions pour pouvoir jouer la carte
Post-conditions	La carte du joueur a été jouer L’action de la carte jouer a été effectué
Scénario nominal	Le joueur choisi la carte qu’il veut jouer L’action de la carte est effectuée
Extensions	1 : Action de la carte 1a : Déplacer pion voleur
Alternatives
Cas d’utilisation supérieur
Cas d’utilisation subordonnés
Objectif de performance
Problèmes ouverts
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Obtenir une ressource

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 8. Cas d’utilisation Obtenir une ressource
Item	Description
#	5
Cas d’utilisation	Obtenir ses ressources
Alias	resourceProduction
Objectif contextuel	Un joueur veut récolter des ressources
Portée	Game
Niveau	Secondary task
Condition de succès	Le joueur possède des territoires capables de produire des ressources.
Condition d’échec	Le joueur ne possède pas de territoires qui produit des ressources.
Acteurs principaux:	Le joueur
Acteurs secondaires
Événement déclencheur	Un joueur possède un territoires producteur de ressource
Priorité	Middle
Fréquence	Une fois par tour
Pré-conditions	Le joueur possède un territoires producteur de ressource La somme des dés est égale à un numéro de territoire possedé par le joueur la somme des dés est différent de 7
Post-conditions	Les ressources produites sont ajoutées aux ressources du joueur
Scénario nominal	Un joueur construit une colonie/ville à un emplacement de colonie/ville Les territoires à proximités produises des ressources particulière A chaque fin de lancé de dés, si la somme des dés est différente de 7 et que la somme des dés est égale à un numéro de territoire possedé par le joueur. Le joueur peut collecté les ressources produites par le territoire désigné. Les ressources produites sont ajoutées aux ressources du joueur.
Extensions	Il peut y avoir plusieurs colonie/ville à proximités et potentiellement plusieurs joueurs pouvant réculter les ressources du territoire selectionné.
Alternatives
Cas d’utilisation supérieur	ConstructionColonie ConstructionVille
Cas d’utilisation subordonnés	ConstructionColonie ConstructionVille
Objectif de performance	< 500ms temps de requête
Problèmes ouverts
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Construire une colonie

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 9. Cas d’utilisation Construire une colonie
Item	Description
#	6
Cas d’utilisation	Construction d’une colonie
Alias	ConstructColonie
Objectif contextuel	Construction d’une colonie
Portée	Joueur
Niveau	Primary Task
Condition de succès	Le bâtiment de la carte a été construit pour le joueur qui a joué la carte
Condition d’échec	La colonie n’a pas été construit La colonie a été construit pour un mauvais joueur
Acteurs principaux:	Joueur
Acteurs secondaires
Événement déclencheur	Le joueur veut construire une colonie qu’il possède car c’est le début de la partie ou car il à échanger des ressources contre la construction d’une colonie
Priorité	High
Fréquence	Zéro ou une fois par tour
Pré-conditions	Une carte bâtiment doit avoir été joué par le joueur Le joueur doit remplir les conditions pour pouvoir jouer la carte (avoir construit le bâtiment)
Post-conditions	Le bâtiment a été construit
Scénario nominal	Construction du bâtiment de la carte
Extensions
Alternatives
Cas d’utilisation supérieur	playCard
Cas d’utilisation subordonnés
Objectif de performance
Problèmes ouverts
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Construire une route

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 10. Cas d’utilisation Construire une route
Item	Description
#	6
Cas d’utilisation	Construction d’une route
Alias	ConstructRoute
Objectif contextuel	Construction d’une route
Portée	Joueur
Niveau	Primary Task
Condition de succès	Le bâtiment de la carte a été construit pour le joueur qui a joué la carte
Condition d’échec	La route n’a pas été construit La route a été construit pour un mauvais joueur
Acteurs principaux:	Joueur
Acteurs secondaires
Événement déclencheur	Un joueur veut construire une route au emplacement de route disponible
Priorité	High
Fréquence	Zéro ou une fois par tour
Pré-conditions	Le joueur doit remplir les conditions pour pouvoir jouer construire la route (la route doit être dans la continuité d’une route ou à proximité d’une colonie/ville possédé par le joueur)
Post-conditions	La route a été construite
Scénario nominal	Construction de la route sur le plateau
Extensions
Alternatives
Cas d’utilisation supérieur	PlayCard
Cas d’utilisation subordonnés
Objectif de performance
Problèmes ouverts
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Construire une ville

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 11. Cas d’utilisation Construire une ville
Item	Description
#	6
Cas d’utilisation	Construction d’une ville
Alias	ConstructVille
Objectif contextuel	Construction d’une ville
Portée	Joueur
Niveau	Primary Task
Condition de succès	La ville est construite et visible sur la carte
Condition d’échec	La ville n’a pas été construit La ville a été construite pour un mauvais joueur
Acteurs principaux:	Joueur
Acteurs secondaires
Événement déclencheur	Un joueur veut améliorer sa colonie en ville
Priorité	High
Fréquence	Zéro ou une fois par tour
Pré-conditions	Le joueur possède une colonie Le joueur doit remplir les conditions pour pouvoir améliorer sa colonie (ressource)
Post-conditions	La ville a été construite
Scénario nominal	Construction de la ville sur la carte
Extensions
Alternatives
Cas d’utilisation supérieur	AmeliorerColonie
Cas d’utilisation subordonnés
Objectif de performance
Problèmes ouverts
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Défausser une carte développement

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 12. Cas d’utilisation Défausser une carte développement
Item	Description
#	13
Cas d’utilisation	Defausser une ou des cartes developpement
Alias	ThrowDevCard
Objectif contextuel	Il y a eu 7 au lancé de dés et le joueur possède plus de 7 carte developpement
Portée	Joueur
Niveau	Primary task
Condition de succès	Le joueur defausse la moitié de ses cartes developpement arrondi à l’entier supérieur
Condition d’échec	Échec lors du defaussage des cartes
Acteurs principaux	Joueur,Game
Acteurs secondaires
Événement déclencheur	Fin de tour
Priorité	High
Fréquence	1 fois tour du voleur
Pré-conditions	Informations sur la main des joueurs
Post-conditions	Le defaussage est réussie
Scénario nominal	Un joueur à lancer les dés et à obtenu 7 Les joueurs doivent défausser leur cartes developpement s’ils ont plus de 7 carte developpement Les joueurs choisissent leur carte à défausser
Extensions
Alternatives
Cas d’utilisation supérieur
Cas d’utilisation subordonnés
Objectif de performance
Problèmes ouverts
Échéancier	1.0
Contraintes
Annexes

Fonctionnalité Fin d’une partie

Exigences fonctionnelles

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:
REQ-2:

Description sous la forme d’un cas d’utilisation

Table 13. Cas d’utilisation Fin d’une partie
Item	Description
#	15
Cas d’utilisation	Fin de la partie
Alias	FinishGame
Objectif contextuel	À la fin de chaque tour, on comptabilise les points pour vérifier si quelqu’un à 10 point de victoire.
Portée	Game
Niveau	Primary task
Condition de succès	Fin de la partie, détermination du gagnant
Condition d’échec	Échec lors de la résolution
Acteurs principaux	Game, joueur
Acteurs secondaires
Événement déclencheur	Fin de chaque tour
Priorité	High
Fréquence	1 fois par tour
Pré-conditions	-
Post-conditions	Fin de la partie Le gagnant est déterminé
Scénario nominal	Un joueur fini son tour On comptabilise les points de victoires, les colonies, villes, cartes, bonus Le gagnant est celui qui à 10 point de victoire
Extensions
Alternatives
Cas d’utilisation supérieur	Game
Cas d’utilisation subordonnés	FinGame
Objectif de performance
Problèmes ouverts
Échéancier	1.0
Contraintes
Annexes

Autres exigences non-fonctionnelles

Exigences de performance

S’il existe des exigences de performance pour le produit dans diverses circonstances, indiquez-les ici et expliquez leur raison d’être, afin d’aider les développeurs à comprendre l’intention et à faire des choix de conception appropriés. Spécifiez les relations temporelles pour les systèmes en temps réel. Faites en sorte que ces exigences soient aussi spécifiques que possible. Vous devrez peut-être énoncer des exigences de performance pour des exigences fonctionnelles ou des caractéristiques individuelles.

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é

Précisez toute exigence concernant les questions de sécurité ou de confidentialité entourant l’utilisation du produit ou la protection des données utilisées ou créées par le produit. Définissez toute exigence en matière d’authentification de l’identité de l’utilisateur. Faites référence à toute politique ou réglementation externe contenant des questions de sécurité qui affectent le produit. Définissez toutes les certifications de sécurité ou de confidentialité qui doivent être satisfaites.

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é

TODO

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.

Règles métier

Énumérez tous les principes de fonctionnement du produit, tels que les personnes ou les rôles qui peuvent remplir telle ou telle fonction dans des circonstances spécifiques. Il ne s’agit pas d’exigences fonctionnelles en soi, mais elles peuvent impliquer certaines exigences fonctionnelles pour faire respecter les règles.

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.

Annexe A : Glossaire

https://docs.asciidoctor.org/asciidoc/latest/sections/glossary/

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.

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.

Annexe C : Liste à déterminer

Recueillir une liste numérotée des références TBD (To Be Done) qui restent dans le SRS afin de pouvoir les suivre jusqu’à leur fermeture.