MyClassManager
Spécification d'exigences logicielles
Version 1.2.1
Par : Abdelhadi NAIMI & Mohammed Yassine CHERIFI
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
1
Historique des modifications du document
Date Version Description Auteur
07-11-2018 1.0.0 Création du document Naimi
08-11-2018 1.0.1 Ajouter quelques cas d’utilisation Naimi,
Cherifi
09-11-2018 1.0.2 Création du premier diagramme de cas d’utilisation Cherifi
10-11-2018 1.1.1 Ecrire l’introduction,l’objectif et la portée du Naimi
document
18-11-2018 1.1.2 Création de la 2eme version du diagramme de cas Naimi
d’utilisation
22-11-2018 1.2.0 Ajout des sections 2, 2.1, 2.2 Naimi
26-11-2018 1.2.1 Ajout de quelques maquettes Cherifi
18-01-2019 1.3.0 Ajout de la section conception Naimi
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
2
Table des matières
Historique des modifications du document 2
Table des matières 3
Introduction 5
Objectif du document 5
Portée du document 5
Définitions, acronymes et abréviations 6
Références 6
Vue d’ensemble 6
Description générale 6
Perspectives du produit 6
Fonctions du produit 12
Caractéristiques des utilisateurs 12
Contraintes 12
Hypothèses et dépendances 12
Exigences reportées 13
Exigences spécifiques 13
Fonctionnalités 13
Spécification des cas d’utilisation 13
Détails sur les cas d’utilisation 14
Exigences supplémentaires 16
Conception 18
Aspect structural 18
Aspect dynamique 19
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
3
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
4
1. Introduction
Ce document spécifie les exigences du système MyClassManager, il montre l’objectif
derrière la réalisation de ce système ainsi son périmètre d’utilisation et ses principales
fonctionnalité[Link] document respecte la norme du model IEEE 830 qui est assez utilisée
actuellement et il est soumit en plus aux lois imposées par l’état.
1.1. Objectif du document
Le document a comme objectif de détailler les exigences du système MyClassManager, qui
a pour but de satisfaire les principaux besoins suivants :
- Gestion d'absentéisme : A pour but de suivre l'assiduité des étudiants en suivant
leurs nombre d'absences dans toutes leurs séances, ça permettra une bonne gestion
et va diminuer potentiellement le taux d'absentéisme.
- Correction anonyme : A pour but d’automatiser l'ancienne méthode de correction
anonyme pour réduire le risque d’erreur et pour avoir encore un plus grand degré
d’anonymat et d'intégrité.
1.2. Portée du document
MyClassManager a pour but de faciliter l’appel des étudiants et réduire le taux d’erreur
dans la saisie de notes. Il n’est pas à ce fait responsable lors d’une mauvais utilisation et
dans la détection d’erreurs engendrées par cette utilisation. Il offre quand même la
possibilité de corriger les erreurs de saisie de notes dans un délais légal discuté dans la
sections 3.3.3 mais aussi la possibilité de joindre une absence avec un justificatif ou de
corriger une erreur ou un oublie lors de l’appel.
MyClassManager n’est aussi pas responsable lors des réclamations des étudiants à propos
d’une mauvais notes, ou d’une absence attribué avec injustice, consulter la sections 3.3.3
pour plus d’information.
MyClassManager s'intègre dans le cadre d’un environnement d'enseignement où l’assiduité
et les absences sont marquées et les enseignés sont pénalisés à ce fait. Il s’intègre aussi
dans un environnement où la délivrance et la correction de copies se fait dans une
systématique anonyme.
Ce projet va assurer les fonctions et la bonne implémentation de toutes les exigences
mentionnées dans la sections 3 de ce document en respectant les contraintes mentionnées
dans la sections 2.4.
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
5
1.3. Définitions, acronymes et abréviations
- Absentéisme : L'absentéisme est le fait d'être absent de manière habituelle ou
systématique du lieu de travail ou d’études.
- Groupe : Un groupe d’étudiants dans une même classe.
1.4. Références
- Model IEEE 830 : modèle standard pour la rédaction du document de spécification
des exigences.
- Loi de l’université
- Loi de l‘état
1.5. Vue d’ensemble
Le reste du document va décrire en détails les fonctionnalités du produit ainsi que les
contraintes et les exigences du client.
2. Description générale
2.1. Perspectives du produit
MyClassManager est une application web et mobile. Les maquettes suivantes donnent une
vision sur les principales fonctionnalités de l’application :
Maquettes WEB
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
6
2.1.1 Liste des étudiants / Ajouter un étudiant / Alimenter la base de données à travers un fichier Excel
2.1.2 Liste des utilisateurs / Ajouter un utilisateur
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
7
2.1.3 Correction / Introduire les notes
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
8
Maquettes Mobile
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
9
2.1.4 Faire l’appel / Marquer les absences
2.1.5 Joindre les justificatifs
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
10
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
11
2.2. Fonctions du produit
MyClassManager a deux principales fonctionnalités suivantes :
- Faire l’appel : cette fonction donne la possibilité aux enseignants d’effectuer l’appel
d’une manière facile et simple.
- Introduire les notes : cette fonction concerne aussi les enseignants en leur
permettant d’introduire les notes des examens dans des liste cryptées .
2.3. Caractéristiques des utilisateurs
Les utilisateurs de l’application sont :
- Enseignant : C’est le principal utilisateur de l’application, toutes les fonctions de
l’application seront développées d’une façon à alléger et faciliter son travail.
- Responsable du module : C’est aussi un enseignant mais il peut aussi affecter les
copies et les groupes à des enseignant.
- Chef département : Il peut être un enseignant, un responsable du module ou un
administrateur de l’application ou tous en même temps.
- Responsable anonymat : C’est la personne qui dirige l'aspect de correction anonyme
(Cryptage et décryptage).
2.4. Contraintes
Voici les contraintes qui peuvent limiter le développement du système :
- Un enseignant ne peut pas faire l’appel de la part d’un autre enseignant.
- Chaque enseignant peut enseigner un ou plusieurs groupes à la fois.
- Un étudiant sera exclus d’un module après 3 absences non justifiées ou après 5
absence justifiées dans ce module.
- Un enseignant peut joindre une absence d’un étudiant avec un justificatif.
- Chaque copie d’étudiant va être représentée par un code.
- Les noms des étudiants ne pourront pas être liées à ce code.
- Une note est donnée à l’étudiant après au minimum 2 corrections.
- Dans le cas ou la différences entre les deux corrections est supérieure à un nombre
donné par le responsable du module, une 3ème correction sera mise en place.
- L’enseignant ne saura pas si il est dans sa 1er, 2eme ou même sa 3eme correction.
- Le responsable du module est celui qui affecte les copies ainsi que les groupes au
enseignants.
2.5. Hypothèses et dépendances
MyClassManager dépend surtout de sa bonne utilisation, pour ne pas tomber dans des
problèmes. On suppose que tous ses utilisateurs comprennent et ont reçu une petite
formation sur le fonctionnement de l’application, et surtout celle de l’administration. Voir la
section [Link].
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
12
2.6. Exigences reportées
Les exigences suivantes peuvent être réalisées dans une future version de l’application :
- Notifier les étudiants qui ont un taux élevé d’absences.
- Faire une interface de connexion aux étudiants pour consulter leurs notes.
3. Exigences spécifiques
3.1. Fonctionnalités
3.1.1. Gestion de la correction anonyme
L’application doit avoir une fonctionnalité pour gérer la correction anonyme, avec la
possibilité de plusieurs correction et tout ça dans une anonymat totale.
3.1.2. Faciliter L’appel des étudiants
L’application doit offrir une fonctionnalité au enseignants pour noter facilement les
étudiants absents, et aussi pouvoir joindre des justificatif à ses absences.
3.1.3. Alimentation de la BDD
On doit avoir la possibilité d’alimenter la base de donnée à travers un fichier excel qui
est fourni par la scolarité. Il va contenir la liste d’étudiants distribués en groupes.
3.1.4. Exportation des notes
Après la correction anonyme, on doit pouvoir exporter les notes dans un format
excel.
3.1.5. Examination en temps réel le taux d’absentéisme
Avoir la fonctionnalité d’observer le taux d’absentéisme et les étudiants exclus.
3.2. Spécification des cas d’utilisation
Acteur Cas d’utilisations
Enseignant Joindre les justificatifs, Introduire les notes, Modifier appel,
Faire l'appel, Consulter les statistiques
Responsable module Affecter les paquets de copie, Affecter les groupes
Responsable anonymat Importer la listes chiffrées
Administrateur Créer les comptes, Maintenir l’application
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
13
3.3. Détails sur les cas d’utilisation
On a utiliser le diagramme de séquence système pour détailler quelques cas
d’utilisations
Le diagramme suivant concerne le cas d’utilisation « Faire l’appel »
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
14
Le diagramme suivant concerne le cas d’utilisation « Joindre justificatif»
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
15
3.4. Exigences supplémentaires
3.4.1. Utilisabilité
[Link]. Application WEB pour desktop et mobile
[Link]. La durée de formation pour bien utiliser l’application est de 20 minutes
[Link]. Material Design sera utilisé comme standards d’interface utilisateurs
3.4.2. Fiabilité
[Link]. Application disponibles sur mobile même sans connexion internet
3.4.3. Maintenabilité
[Link]. Les codes de copies sont codés sous la forme NNN-NNN avec N = {0..9}
[Link]. Les notes d’étudiants sont dans un intervalle de nombres réels avec 2 nombres
après la virgule de 0 à 20
3.4.4. Performance
[Link]. Le délais moyen de réponse système sera ~ 20 ms sous une connexion 4G de
520 Kbps
[Link]. L’application pourra fonctionner sans descendre au dessous du délais moyen
même avec au minimum 700 utilisateurs dans le système en même temps.
3.4.5. Sécurité
[Link]. Seul le responsable de l’anonymat peut en cas de panne extraire la listes des
étudiants avec les codes de leur copies.
[Link]. L'administrateur ne pourra pas lier un étudiant à sa copies, même en accédant à
la base de données.
ID Description Urgence Risk
R001 Gérer la correction anonyme 1 1
R002 Alimenter la liste générale des étudiants dans la BDD à travers un 1 2
fichier Excel
R003 Exportation des notes en fichier Excel 1 2
R004 Créer les comptes du chef du département,des enseignants et 1 3
responsables des modules et pour les responsable d’anonymat
R005 Voir en temps réel le taux d’absentéisme et les étudiants exclus 1 3
R006 Faciliter l’appel 1 3
R007 Joindre justificatif 2 1
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
16
R008 Nettoyer la liste d'étudiant de ceux qui ont été exclus 2 1
R009 Introduire les notes en anonymat 2 1
R010 Application WEB pour desktop et mobile 2 1
R011 Aborder la 3ème correction en cas d’une grande différence 2 2
R012 Affecter les paquets de copies aux enseignants pour la correction 2 2
R013 Gérer les justificatifs d’absence 2 2
R014 Paramétrer le choix de la note finale(moyenne ou maximum) 2 3
R015 Afficher la liste des étudiant dont la différence entre les deux notes 2 3
est plus de 3 points
R016 Ajouter manuellement les endettés 2 4
R017 Alimenter la BDD avec la liste des étudiants avec leurs codes 3 1
d’anonymat
R018 Accepter justificatifs au plus 48H après l’absence 3 2
R019 Paramétrer la différence entre les deux notes 3 2
R020 Décomposer les étudiants en groupe 3 3
R021 Examiner le nombre d’absences par l’étudiant 4 1
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
17
4. Conception
4.1. Aspect structural
4.1.1. Diagramme de classe
On a choisi de séparer les étudiants en groupe pour faciliter la classification et
l’affectation d’enseignants. On a conceptualiser la fonctionnalité d’ajout de justificatif comme
un attribut dans la classe associatif entre Séance et Étudiant, par exemple chaque étudiant
assiste à plusieur séances et dans chacune de ces absences l’attribut Absent sera False et
il devra justifier cette absence de cette séance.
Chaque Paquet est affecté à plusieur Enseignant pour conceptualiser l'opération de
correction multiple, et chaque association a le numéro de correction soit 1,2 ou 3.
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
18
4.2. Aspect dynamique
4.2.1. Diagramme d’états transition
On a fait le choix d'utiliser le diagramme d’états transitions proposé par ULM pour
montrer le changement d’état de l’objet paquet (Instance de la classe Paquet) qui a
un comportement complexe par rapport aux autres objets au sein de notre système.
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
19
4.2.2. Diagramme de Navigation
On a choisi le diagramme d‘états transition comme outils efficace pour donner une
vision sur l’enchaînement des écrans et la navigation dans notre système.
Les digrammes suivants représente la navigation faite par l’enseignant dans le système (La
version mobile pour la gestion d’absences et la version WEB pour la gestion de correction)
Version 1.2.1 - 28-11-2018
Naimi Abdelhadi, Cherifi Mohammed Yassine
20