Spécification des exigences

1. Introduction

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

1.1. Avant-propos

L’objectif de ce document est de décrire les spécifications des exigences du projet "QuizMaker" pour les étudiants en génie logiciel.

Le public visé par cette spécification comprend les développeurs potentiels de l’application, ainsi que les personnes chargées de l’évaluation technique.

1.2. Définitions, acronymes et abréviations

Norme ISO/IEC/IEEE 29148-2018: Ingénierie des systèmes et du logiciel — Processus du cycle de vie — Ingénierie des exigences
SRS: Software Requirements Specification, Spécification des Exigences Logicielles

Tableau 1. Acronymes
Acronyme	Description
JDBC	Java DataBase Connectivity
JPA	Java Persistence API
SGBD	Système de Gestion de Bases de Données

Tableau 2. Définitions
Terme	Définition
WebSockets	Protocole servant à établir des connexions TCP persistantes entre serveurs et clients
REST	Protocole servant à établir des connexions HTTP entre serveurs et clients

1.3. Public visé et suggestions de lecture

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

1.4. Portée du projet

Le système QuizMaker permettra à des enseignants d’évaluer leurs étudiants grâce à des questions à choix multiple

1.5. Références

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

1.6. Vue d’ensemble

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

1.7. Organisation du chapitre

1.8. Description générale

1.8.1. Perspectives du produit

QuizMaker est un gestionnaire de questionnaires. Le logiciel QuizMaker doit permettre aux étudiants qui sont connectés à Internet d’utiliser leurs appareils connectés pour participer. Ainsi, "QuizMaker" est une version électronique en ligne d’une évaluation.

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

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

Les acteurs interagissent avec le Client Web, qui utilise le protocole les WebSockets et/ou REST pour communiquer avec (au maximum) un serveur QuizMaker.

Figure 1. UML Diagramme de déploiement

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

QuizMaker sera le premier d’une ligne de produits de type "Évaluation". Son architecture servira comme exemple à d’autres produits.

1.8.2. Fonctionnalités du produit

Le logiciel QuizMaker doit assurer trois fonctions principales :

Connexion au serveur : permettre à un utilisateur de rejoindre un serveur pour ensuite créer ou participer à un questionnaire.
Création d’un questionnaire : permettre aux enseignants d’élaborer des questionnaires.
Participation à un questionnaire : permettre aux étudiants de répondre à questionnaire et recevoir une évaluation.

1.8.3. Caractéristiques et classes d’utilisateurs

Le logiciel QuizMaker a deux classes d’utilisateurs : les enseignants et les étudiants.

Les étudiants utilisent la même interface utilisateur pour participer aux questionnaires, indépendamment de leur connaissance en informatique.

Les enseignants peuvent gérer les étudiants et les questionnaires.

1.8.4. Environnement opérationnel

Le Serveur doit fonctionner sur tout système d’exploitation populaire et récent : Linux, Windows, ou MacOS. Le client Web devrait fonctionner sur tout navigateur Web compatible avec les WebSockets : Firefox (≥ 7.0), Chrome (≥ 5.0), Safari (≥ 5.0), ou Edge (≥ 12.0).

2. Exigences non-fonctionnelles

2.1. Contraintes de conception et de mise en œuvre

2.1.1. Langages de programmation

Utiliser le langage Java, version 11 (minimum)

NF-Req-1

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

Utiliser le langage TypeScript, version 4 (minimum)

NF-Req-2

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

2.2. Langage de conception

Utiliser Asciidoc

NF-Req-3

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

Utiliser PlantUML

NF-Req-4

Les diagrammes de conception et de mise en œuvre devront être réalisés en PlantUML, en suivant la norme UML.

2.3. Mise en œuvre

Utiliser JUnit Jupiter (version ≥ 5.0)

NF-Req-5

Les tests du code Java doivent utiliser JUnit Jupiter (version ≥ 5.0).

Utiliser un framework de Log

NF-Req-6

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

2.4. Outils de production

Utiliser des outils de production automatique

NF-Req-7

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

Zéro configuration

NF-Req-8

La production doit se faire sans aucune configuration. Le simple lancement de Maven (mvn package) et de npm (npm run build) doit être suffisant pour produire le logiciel.

2.5. Outils de déploiement

Déploiement

NF-Req-9

Le déploiement du serveur doit se faire grâce aux conteneurs. Le serveur doit contenir un fichier nommé ContainerFile, qui permettra l’exécution d’un conteneur avec Podman ou Docker.

3. Vérification

Les méthodes du composant domaine du backend doivent être vérifiées à l’aide de tests unitaires. Chaque test unitaire doit décrire clairement son intention.

Couverture de code Java

NF-Req-10

Les tests unitaires du serveur doivent couvrir toutes les méthodes du composant domaine. Pour chaque méthode, tous les cas importants doivent être couverts, si besoin en s’aidant d’une approche de test combinatoire.

4. Documentation utilisateur

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

4.1. Hypothèses et dépendances

Aucune jusqu’à présent.

4.2. Exigences reportées

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

5. Exigences en matière d’interface externe

5.1. Interfaces utilisateur

Aucune exigence

5.2. Interfaces matérielles

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

5.3. Interfaces logicielles

La partie client du logiciel doit fonctionner sur des navigateurs web, tandis que la partie serveur doit interagir avec une base de données par le biais de l’API Java Persistence (JPA).

5.4. Interfaces de communication

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

6. Exigences fonctionnelles

6.1. Fonctionnalité « Créer un questionnaire »

6.1.1. Description et priorité

Tableau 3. Créer un
Id	FR-1
Description	Cette fonctionnalité permet à un enseignant de créer un questionnaire
Priorité	Haute

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

Créer un questionnaire

Item	Description
#	1
Cas d’utilisation	Créer un questionnaire
Alias
Objectif contextuel	à compléter
Portée	Système
Niveau	Utilisateur
Condition de succès
Conditions d’échec	L’enseignant n’arrive pas à créer un questionnaire
Acteur principal	L’enseignant
Acteurs secondaires
Événement déclencheur	L’enseignant souhaite évaluer ses étudiants sur un sujet enseigné ou une compétence acquise
Priorité	Haute
Fréquence
Pré-conditions	L’enseignant est connecté à Internet et possède un compte sur le serveur de questionnaires
Post-conditions	Le système contient un nouveau questionnaire
Scénario nominal	L’enseignant se connecte au système L’enseignant crée un module d’enseignement L’enseignant ajoute des étudiants au module L’enseignant crée un questionnaire et lui donne un nom L’enseignant ajoute des questions au questionnaire L’enseignant ferme le questionnaire
Extensions
Alternatives	Le module d’enseignement existe déjà, l’enseignant l’ouvre et crée un questionnaire
Cas d’utilisation supérieur
Cas d’utilisation subordonnés	Créer un module, ajouter des étudiants à un module
Objectif de performance
Problèmes ouverts	Aucun
Échéancier	Version 1.0
Contraintes
Annexes

Item

Description

Cas d’utilisation

Créer un questionnaire

Alias

Objectif contextuel

à compléter

Portée

Système

Niveau

Utilisateur

Condition de succès

Conditions d’échec

L’enseignant n’arrive pas à créer un questionnaire

Acteur principal

L’enseignant

Acteurs secondaires

Événement déclencheur

L’enseignant souhaite évaluer ses étudiants sur un sujet enseigné ou une compétence acquise

Priorité

Haute

Fréquence

Pré-conditions

L’enseignant est connecté à Internet et possède un compte sur le serveur de questionnaires

Post-conditions

Le système contient un nouveau questionnaire

Scénario nominal

L’enseignant se connecte au système
L’enseignant crée un module d’enseignement
L’enseignant ajoute des étudiants au module
L’enseignant crée un questionnaire et lui donne un nom
L’enseignant ajoute des questions au questionnaire
L’enseignant ferme le questionnaire

Extensions

Alternatives

Le module d’enseignement existe déjà, l’enseignant l’ouvre et crée un questionnaire

Cas d’utilisation supérieur

Cas d’utilisation subordonnés

Créer un module, ajouter des étudiants à un module

Objectif de performance

Problèmes ouverts

Aucun

Échéancier

Version 1.0

Contraintes

Annexes

6.2. Fonctionnalité « Réaliser une épreuve »

6.2.1. Description et priorité

Id	FR-2
Description	Permet à un enseignant d’évaluer les étudiants d’un module grâce à un questionnaire.
Priorité	Moyenne

FR-2

Description

Permet à un enseignant d’évaluer les étudiants d’un module grâce à un questionnaire.

Priorité

Moyenne

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

Item	Description
#	UC-2
Cas d’utilisation	Réalisation d’une épreuve
Alias
Objectif contextuel	Évaluer les étudiants grâce à un questionnaire de type QCM
Portée	Système (QuizMaker)
Niveau	Utilisateur
Échéance	Version 1.0.0
Condition de succès	Les étudiants répondent aux questions et obtiennent leurs notes
Condition d’échec	L’enseignant n’a pas les notes des étudiants pour son épreuve
Acteurs principaux :	L’enseignant, les étudiants
Acteurs secondaires
Événement déclencheur	L’enseignant souhaite évaluer ses étudiants
Priorité	Haute
Fréquence
Pré-conditions
Post-conditions	Les étudiants ont une note pour cette épreuve
Scénario nominal	L’enseignant se connecte au système L’enseignant ouvre le module qu’il souhaite réaliser L’enseignant créé une épreuve et lui attribue un ou plusieurs questionnaires, une durée et une date de réalisation L’enseignant se déconnecte du système À la date prévue, les étudiants se connectent au système Le système propose le questionnaire aux étudiants Chaque étudiant navigue entre les questions et répond aux questions La durée de l’épreuve est atteinte ou l’étudiant marque sa copie comme finie Les étudiants se déconnectent du système L’enseignant se connecte au système L’enseignant ouvre l’examen et demande au système de le corriger L’enseignant analyse les notes obtenues L’enseignant demande au système de publier les notes Les étudiants se connectent au système Les étudiants consultent leurs notes
Extensions	Aucune
Alternatives	Aucune
Cas d’utilisation supérieur	Aucun
Cas d’utilisation subordonnés	Aucun
Objectif de Performance	Aucun
Problèmes ouverts	Aucun, pour l’instant
Contraintes
Annexes	Aucun

Item

Description

UC-2

Cas d’utilisation

Réalisation d’une épreuve

Alias

Objectif contextuel

Évaluer les étudiants grâce à un questionnaire de type QCM

Portée

Système (QuizMaker)

Niveau

Utilisateur

Échéance

Version 1.0.0

Condition de succès

Les étudiants répondent aux questions et obtiennent leurs notes

Condition d’échec

L’enseignant n’a pas les notes des étudiants pour son épreuve

Acteurs principaux :

L’enseignant, les étudiants

Acteurs secondaires

Événement déclencheur

L’enseignant souhaite évaluer ses étudiants

Priorité

Haute

Fréquence

Pré-conditions

Post-conditions

Les étudiants ont une note pour cette épreuve

Scénario nominal

L’enseignant se connecte au système
L’enseignant ouvre le module qu’il souhaite réaliser
L’enseignant créé une épreuve et lui attribue un ou plusieurs questionnaires, une durée et une date de réalisation
L’enseignant se déconnecte du système
À la date prévue, les étudiants se connectent au système
Le système propose le questionnaire aux étudiants
Chaque étudiant navigue entre les questions et répond aux questions
La durée de l’épreuve est atteinte ou l’étudiant marque sa copie comme finie
Les étudiants se déconnectent du système
L’enseignant se connecte au système
L’enseignant ouvre l’examen et demande au système de le corriger
L’enseignant analyse les notes obtenues
L’enseignant demande au système de publier les notes
Les étudiants se connectent au système
Les étudiants consultent leurs notes

Extensions

Aucune

Alternatives

Aucune

Cas d’utilisation supérieur

Aucun

Cas d’utilisation subordonnés

Aucun

Objectif de Performance

Aucun

Problèmes ouverts

Aucun, pour l’instant

Contraintes

Annexes

Aucun

6.3. Fonctionnalité « Créer un compte »

6.3.1. Description et priorité

FR-3

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

Créer un compte

Item	Description
#	UC-3
Cas d’utilisation	Créer un compte
Alias	Inscription
Objectif contextuel
Portée	Système
Niveau	Utilisateur
Condition de succès	L’enseignant arrive à créer un compte, connaît son identifiant et son mot de passe
Conditions d’échec	L’enseignant n’arrive pas à créer un compte L’enseignant crée un compte, mais ne connaît pas son identifiant ou son mot de passe/
Acteurs principaux	L’enseignant
Acteurs secondaires	Un serveur d’identification
Événement déclencheur	L’enseignant souhaite participer à une partie
Priorité	Moyenne
Fréquence
Pré-conditions	L’enseignant est connecté à Internet et possède une adresse email valide et accessible
Post-conditions	Le Système connaît l’enseignant à travers son identifiant
Scénario nominal	L’enseignant demande la création d’un compte L’enseignant saisi son adresse email, son nom, prénom et son mot de passe Le Système envoie une URL unique à l’adresse email de l’enseignant L’enseignant reçoit l’email et ouvre l’URL Le serveur reçoit la requête correspondant à l’URL envoyée et valide l’inscription
Extensions
Alternatives
Cas d’utilisation supérieur
Cas d’utilisation subordonnés	Aucun
Objectif de performance	-
Problèmes ouverts	Aucun
Échéancier	Version 1.1
Contraintes
Annexes

Item

Description

UC-3

Cas d’utilisation

Créer un compte

Alias

Inscription

Objectif contextuel

Portée

Système

Niveau

Utilisateur

Condition de succès

L’enseignant arrive à créer un compte, connaît son identifiant et son mot de passe

Conditions d’échec

L’enseignant n’arrive pas à créer un compte
L’enseignant crée un compte, mais ne connaît pas son identifiant ou son mot de passe/

Acteurs principaux

L’enseignant

Acteurs secondaires

Un serveur d’identification

Événement déclencheur

L’enseignant souhaite participer à une partie

Priorité

Moyenne

Fréquence

Pré-conditions

L’enseignant est connecté à Internet et possède une adresse email valide et accessible

Post-conditions

Le Système connaît l’enseignant à travers son identifiant

Scénario nominal

L’enseignant demande la création d’un compte
L’enseignant saisi son adresse email, son nom, prénom et son mot de passe
Le Système envoie une URL unique à l’adresse email de l’enseignant
L’enseignant reçoit l’email et ouvre l’URL
Le serveur reçoit la requête correspondant à l’URL envoyée et valide l’inscription

Extensions

Alternatives

Cas d’utilisation supérieur

Cas d’utilisation subordonnés

Aucun

Objectif de performance

Problèmes ouverts

Aucun

Échéancier

Version 1.1

Contraintes

Annexes

7. Autres exigences non-fonctionnelles

7.1. Exigences de performance

Simplicité

NF-Req-11

QuizMaker doit être simple, ce qui signifie que les acteurs doivent avoir un retour rapide de leurs actions et que les retards dus aux problèmes de communication/connexion doivent être correctement informés.

Efficacité

NF-Req-12

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

7.2. Exigences de sécurité

Aucune

7.3. Attributs de qualité logicielle

7.3.1. Maintenabilité

Le code doit être maintenable

NF-Req-13

Le logiciel doit être lisible et facile à maintenir.

Respect des conventions de codage Java

NF-Req-14

Les sources Java doivent respecter les directives de codage Google.

Les directives de codage Java peuvent être facilement vérifiées grâce à PMD

Respect des conventions de codage TypeScript

NF-Req-15

La source TypeScript doit respecter les directives de codage Google.

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

7.4. Exigences de configurabilité

Configuration SMTP

NF-Req-16

Le SMTP utilisé par le serveur pour envoyer des emails doit être configurable (nom d’hôte, port, nom d’utilisateur, mot de passe) au moment du déploiement du serveur.

Pour tester manuellement votre serveur, vous pouvez utiliser le SMTP de l’université via votre compte mail étudiant :

nom d’hôte : smtp.etu.univ-nantes.fr
port : 465 (protocole TLS) ou 587 (protocole STARTTLS)
nom d’utilisateur : votre identifiant étudiant
mot de passe : votre mot de passe étudiant

Configuration SGBD

NF-Req-17

Le SGBD utilisé par le serveur doit être configurable (nom d’hôte, port, nom d’utilisateur, mot de passe) au moment du déploiement du serveur.

8. Liste d’exigences

Tableau 4. Exigences fonctionnelles (3)
Code	Titre
FR-1	Section 6.1
FR-2	Section 6.2
FR-3	Section 6.3

Tableau 5. Exigences non-fonctionnelles (17)
Code	Titre
NFR-1	Utiliser le langage Java, version 11 (minimum)
NFR-2	Utiliser le langage TypeScript, version 4 (minimum)
NFR-3	Utiliser Asciidoc
NFR-4	Utiliser PlantUML
NFR-5	Utiliser JUnit Jupiter (version ≥ 5.0)
NFR-6	Utiliser un framework de Log
NFR-7	Utiliser des outils de production automatique
NFR-8	Zéro configuration
NFR-9	Déploiement
NFR-10	Couverture de code Java
NFR-11	Simplicité
NFR-12	Efficacité
NFR-13	Le code doit être maintenable
NFR-14	Respect des conventions de codage Java
NFR-15	Respect des conventions de codage TypeScript
NFR-16	Configuration SMTP
NFR-17	Configuration SGBD

Annexe A : Glossaire

Terme

Description courte

Signification

QCM

Questionnaire à choix multiples

Un QCM est un procédé d’évaluation dans lequel sont proposées plusieurs réponses pour chaque question. Une ou plusieurs de ces propositions de réponse sont correctes. Les autres sont des réponses erronées, également appelées "distracteurs" (ou "leurres"). Le QCM permet à un enseignant de voir qu’un étudiant a bien compris et retenu une réponse juste et qu’il est capable d’identifier les erreurs.