Vous êtes sur la page 1sur 23

Chapitre II: Spécification des besoins

République Tunisienne
Ministère de l'Enseignement Supérieur et de Recherche Scientifique
Université de Jendouba
Institut Supérieur d'Informatique du Kef 

PROJET DE FIN D’ETUDES

Pour l’obtention de :
Licence Fondamentale en Sciences Informatiques

Conception et Réalisation d’une


Développé au sein de la société FAST CARGO
application web de gestion de
stagiaire

Développé au sein de l’entreprise : COFICAB


Réalisé par : Dirigé par :
Oumayma Ferjeni Dr Sawsen sakji
Mr: Wajdi Zanouni

Année universitaire:2021/2022
Chapitre II: Spécification des besoins

Chapitre I : Cadre général du projet

Introduction :
Dans ce chapitre nous présentons de l’organisme d’accueil. Puis, nous allons introduire notre
sujet ainsi que sa problématique. Puis, nous allons expliquer le travail à réaliser.
I. Présentation de l’organisme d’accueil
1. Historique
<<COFICAB MED>> a été créé en Octobre 2009 à Medjez el bab dans la zone industrielle
BOUMOUS, une photo du site présentée dans la figure 1: Site COFICAB MED, suite à :
 Une politique de logistique de proximité
 Une augmentation de part de marché Local
 Une réduction des coûts en bénéficiant des avantages fiscaux offerts
 Une participation à la stratégie tunisienne de développement régional

figure1 : site COFICAB MED

2. Fiche technique

La carte d'identité de COFICAB MED est présentée par sa fiche signalétique présentée dans le
tableau Fiche technique de COFICAB MED

Tableau 1: Fiche technique de COFICAB MED

Raison sociale COFICAB MED


Situation Société anonyme
juridique
Chapitre II: Spécification des besoins

Statut fiscal Société exportatrice


Secteur Automobile
Activité Fils, câbles isolés et faisceaux de câbles
entrée en 16/09/2009
production
Siege de l’usine 14 rue 18 janvier, 1001 Tunis RP Tunisie
Adresse usine Zone industriel boubous Medjez el bab
9070
PDG M. Hichem ELLOUMI
Directeur de M. Mouhamed Drira
l’usine
Effectif 262
Capital social 5000000 Ddt
Capacité de 40000 km/Sem
production
Certifications SO/TS 16949, ISO 9001, ISO 14001
URL www.coficab.com
E-mail Oficab.ce@coficab.com
Tél/Fax (216) - 71 156 000 / 71 590 230

3. Structure organisationnelle de COFICAB MED

<<COFICAB MED>> est dirigé par le directeur de site qui prend en charge l'application de
la stratégie du groupe <<COFICAB>> au sein du site tout en prenant en compte le contexte
spécifique de <<COFICAB MED>>. Le processus décisionnel bénéficie d'une autonomie
partielle dépendante du siège situé à COFICAB TUNISIE par le processus d'approbation. La
structure de <<COFICAB MED>> est présentée dans la figure 8: Organigramme de<<
COFICAB MED>>

s
r
c
e
i
t
c
e
rt
e
due
r
e
n
i
s
u
'
d
é
e
r
Chapitre II: Spécification des besoins

Figure 2 : Organigramme de la société

II. Problématique
En observant le processus actuel gestion de qualification des stagiaires au sein de
<<COFICAB>> nous avons remarque les points faibles suivants :
— Le nombre important des dossiers des stagiaires augmente le risque de perte des
documents ou leur détérioration, ainsi que la difficulté de recherche d’information.
— La manipulation des plusieurs fichiers Excel pour stocker les données des stagiaires,
entraine des erreurs et redondances des données.
— Perte de temps pour élaborer le planning des tests prochains selon les résultats des
tests précédents.
— Difficulté de connaitre en temps réel les stages terminés

III. Etude de l’existant


Le service de formation, en collaboration avec les encadreurs, détermine les critères d’évaluation de
stage à chaque stagiaire Pour chaque critère il affecte un coefficient allant de 1 à 4 selon le degré
d’importance de critère, La note globale de cet évaluation est calculée comme sui

∑critére × coffition
note evalution=
∑ coffition ¿
¿

L’évaluation de chaque stagiaire est donnée selon le barème représenté par le Tableau :

Not Description Qualification


e
4 L’évaluation de stage et au dessous des attentes T.Bien

3 L’évaluation de stage besoin d’amélioration Bien

2 L’évaluation de stage répond entièrement aux Moyen


attentes
1 L’évaluation de stage dépasse les attentes Faible

Table 1 : barème dévaluation de stage


Chapitre II: Spécification des besoins

Apres avoir calculé la note globale dévaluation, on calcule le pourcentage de cette note par rapport
à la note maximale de la fonction ensuite on détermine la classe de cette note selon la démarche
illustrée par le Tableau 2

A Total >= 90%

B 90% > Total > 75%

C 75% >Total > 60%

D Total < 60%

 Si A ou B : stage validé


 Si C : stage passable
 Si D : stage non validé
IV. Solution Proposée

Après une étude comparative sur les différentes solutions existantes, il est donc primordial au
regard des inconvénients recensés de proposer une solution qui pourra répondre à nos besoins.
1. Définition de l'objet

Pour de résoudre les problèmes constatés et automatiser la tâche de gestion des stagiaires au sein de
COFICAB, nous proposons de d développer une application web dynamique qui doit être
facilement exploitée par la responsable des ressources humaines. Cette application va permettre,
entre autres, de générer automatiquement les matrices de qualification pour , les attestations des
stages et les cartes des stagiaires. Pour garantir la sécurité des données des stagiaires, cette
application sera protégée par un système d’authentification.

2. Accessibilité
L'application Web destinée aux internautes, sera en ligne, accessible depuis un ordinateur
quelconque. Elle devra permettre à un internaute de s'inscrire et de devenir membre du service
(cette inscription est gratuite).
3. Architecture

L’application respectera l’architecture 3 tiers d'un site Web:


Chapitre II: Spécification des besoins

Le site web doit être accessible à tous. Les services de l’application web doivent être
accessibles aux membres du site: une authentification préalable sera donc nécessaire.

Conclusion :
Ce chapitre a été consacré à la présentation du cadre du projet. Après l’étude de l’existant nous
avons déterminé les problématiques, ensuite nous avons présenté la solution envisagée et
l’architecture adopter. Ceci est très important pour le reste du travail, car c’est a partir de cette étude
qu’on va spécifier les besoins et les analyser dans le chapitre suivant.

Chapitre II : Spécification des besoins

Introduction :
On ne peut jamais développer une application sans savoir qu’est ce qu’on veut faire avec elle, c’est
a dire sans savoir nos besoins ou nos exigences pour cette application. Tout au long de ce chapitre,
nous allons spécifier et analyser ces besoins, et aussi déterminer quels sont les acteurs qui vont
interagir avec l’application pour exécuter les actions liés à ces besoins.

I. Identification des acteurs


Différents acteurs seront en interaction avec l'application avec des usages également différents.
Ces acteurs sont :

1. Administrateur:
Chapitre II: Spécification des besoins

Un acteur avec plus de privilèges et plus d’accès aux différents composants de l’application, c’est
lui qui s’occupe de toutes les opérations de gestion.
1. Stagiaire

Un acteur qui a le droit principalement de cherche et de remplir un formulaire de stagiaires

2. encadreur

Un acteur qui a le droit de contrôler et géré l’avancement de stage

II. Spécification des besoins

1. Les Besoins fonctionnels

Les besoins fonctionnels se rapportent aux fonctionnalités que l'application en question doit offrir
pour satisfaire les utilisateurs. Il s'agit des fonctionnalités du système. Ce sont les besoins spécifiant
un comportement d'entrée/sortie du Système. Dans ce contexte, notre système doit permettre la :

 Remplir des demandes:


Cette tâche va être effectuée par un agent. Il s’agit de remplir un formulaire de stagiaires.

 Gestion des demandes reçues :


Cette tâche est confiée au responsable (l’administrateur de l’application), ce qui nécessitera
une authentification avant toute utilisation. Elle consiste essentiellement au traitement des
demandes reçues.
Le système doit permettre au responsable les fonctionnalités suivantes :
Affichage de la liste des demandes par ordre d’envoi.
La recherche (multicritère) des demandes pour le but de consultation, d’édition ou de
suppression
L’édition de ces demandes : accepter/refuser ou mettre en attente.

 Gestion des demandes acceptées :


Après toute acceptation, le système insère automatiquement les informations
correspondantes au : stage, équipe du travail, stagiaire et formation dans la base de données
et envoie automatiquement un mail d’avis favorable au demandeur contenant un login et
mot de passe, que le système doit générer automatiquement, pour que le stagiaire puisse
accéder à son compte personnel par la suite.
Chapitre II: Spécification des besoins

 Le système devra permettre au responsable de :


Consulter la liste des stages (effectués ou qui seront effectués) avec la possibilité de les
éditer (ajouter les informations du tuteur, sujet du stage…).
Mettre à jour les informations.
Savoir quels sont les stages ayant un rapport.

 Messagerie interne :

Le système doit assurer le contact entre le responsable et les autres utilisateurs.

Evaluation du stage :
A la fin du stage, le stagiaire est censé rendre un rapport de stage afin de faire le point
sur son expérience. Donc, le système doit permettre aux stagiaires d’importer leurs
rapports et au responsable de les évaluer (les stagiaires) à l’aide d’un formulaire à multi
choix.

2. Besoins non fonctionnels

Un besoin non fonctionnel est un besoin spécifiant des propriétés du système, telles que les
contraintes liées à l'environnement et l'implémentation, les exigences en matière de performances,
de dépendances de plate-forme, de facilité de maintenance, d'extensibilité et de fiabilité.
Nous entendons par là les besoins qui caractérisent le système. Autrement dit, il s’agit de définir un
ensemble de critères essentiels pour le bon fonctionnement de notre application. Il est à noter
cependant qu’ils peuvent être exprimés en matière de performance, de type de matériel ou le type de
conception.
Dans le cadre de notre travail, nous pouvons citer par exemple :
a. Ergonomie
L’interface de l’application doit être simple et utilisable afin que l’utilisateur puisse
l’exploiter sans se référer à des connaissances particulières, en d’autres termes, notre
application doit être lisible et facile à manipuler par n’importe quel utilisateur ;
b. Besoin de sécurité
L’application devra assurer la sécurité des utilisateurs. D’où la nécessité de procéder à
l’authentification des agents et administrateurs tout en assurant la confidentialité de leurs
données
Chapitre II: Spécification des besoins

c. L’extensibilité
C’est-à-dire qu’il doit y avoir une possibilité d’ajouter de nouvelles fonctionnalités ou de
modifier celles existantes ;
d. Rapidité et intégrabilité dans d’autres applications
L’application devra être rapide et assure que les modules seront intégrables et utilisables
dans d’autres applications.
III. Diagramme de cas d’utilisation
1. Définition
Description sous forme d’actions et de réactions du comportement d’un système du point de
vue de l’utilisateur. Son Objectif est de :
 Définir les limites du système à concevoir
 Définir les relations entre le système et l’environnement
 Partitionner l’ensemble des besoins d’un système
Un utilisateur ou acteur est représenté par un petit personnage, un cas d’utilisation ou
fonctionnalité du système par un ovale, les flèches issues d’un personnage pointent vers les cas
d’utilisation.

Diagramme de cas d’utilisation global


Voici le digramme de cas d’utilisation général pour notre système présenté par cette figure :
Chapitre II: Spécification des besoins

Figure 1: Diagramme du cas d'utilisation global

2.1. Diagramme des cas d’utilisations détaillées :

Nous allons détailler les cas d’utilisation raffinés en décrivant les scénarios de base.
Raffinement du cas d’utilisation « S’authentifier »
Nous allons raffiner le cas d’utilisation « S’authentifier » comme le montre la figure suivante :

S'authentifier

Utilisateur
<<include>> <<include>>

saisie mot de passe


saisie login

Figure 2 : Raffinement du cas d’utilisation d’authentification


Chapitre II: Spécification des besoins

Avant de commencer l’utilisateur (Administrateur/Abonné/Organisateur/Administrateur Forum)


doit s’authentifier comme l’illustre le tableau suivant :

Cas d’utilisation : S’authentifier


Acteurs Administrateur/stagiaire/encadreur
Pré-condition Chargement de l’application
Post condition Page d’accueil affichée
Scénario(s) Nominal -Le système affiche la page de connexion
-L’utilisateur saisie son login et mot de passe
-Le système vérifie si les champs obligatoires sont remplis
-Le système recherche dans la base de données
-Le système affiche la page d’accueil
Scénario(s) Alternatif -Si un champ manquant le système affiche un message d’erreur
-Si l’utilisateur ne se trouve pas dans la base de donnés le
système affiche un message d’erreur

Tableau 1: Raffinement du cas d’utilisation d’authentification

2.1.2 Raffinement du cas d’utilisation « Gérer stagiaire »

Figure 3 : Raffinement du cas d’utilisation Gérer stagiaire


Chapitre II: Spécification des besoins

Après être authentifié, l’Administrateur peut ajouter une stagiaire comme l’illustre le
tableau suivant :

Cas d’utilisation Ajouter stagiaire


Acteurs Administrateur

Pré-condition Administrateur authentifié

Post condition Stagire ajouté

Scénario nominal(s) -L’Administrateur accède à la page Gérer stagiaire


-L’Administrateur clique sur le bouton « Ajouter stagiaire»
-Le système affiche le formulaire d’ajout des stagiaires
- L’Administrateur remplit le formulaire
- L’Administrateur clique sur le bouton « Enregistrer »
-Le système vérifie si les champs obligatoires sont manquants
-Le système ajoute les données dans la base de donnés
-Le système affiche le message « Le stagiaire a été bien ajouté! »

Scénario(s) alternatif(s) -Si un champ obligatoire est manquant le système affiche un


message d’erreur

Tableau 2: Raffinement du cas d’utilisation ajouter stagiaire


Après être authentifié, l’Administrateur peut modifier stagiaire un existant comme l’illustre
le tableau suivant :

Cas d’utilisation Modifier stagiaire


Acteurs Administrateur
Pré-condition Administrateur authentifié
Stagiaire existant
Post condition Stagiaire Modifié
Scénario nominal(s) -L’Administrateur accède à la page Gérer stagiaire
-L’Administrateur clique sur le bouton « Modifier stagiaire »
-Le système affiche le formulaire de modification des stagiaires
-L’Administrateur remplit le formulaire
-L’Administrateur clique sur le bouton « Enregistrer»
-Le système vérifie si les champs obligatoires sont manquants
-Le système ajoute les données dans la base de donnés
-Le système affiche le message « Le stagiaire a été bien Modifié! »
Chapitre II: Spécification des besoins

Scénario(s) alternatif(s) -Si un champ obligatoire est manquant le système affiche un


message d’erreur

Tableau 3 : Raffinement du cas d’utilisation Afficher stagiaire

Après être authentifié, l’Administrateur peut afficher un stagiaire existant comme l’illustre
le tableau suivant :
Cas d’utilisation Afficher stagiaire
Acteurs Administrateur

Pré-condition Administrateur authentifié


Stagiaire existant
Post condition Stagiaire affiché

Scénario nominal(s) - L’Administrateur clique sur le bouton Afficher stagiaire


-Le système cherche dans la base de donnés les stagiaires
disponibles
-Le système renvoie la liste des stagiaires
Scénario(s) alternatif(s) -Pas de stagiaire à afficher

Tableau 4 : Raffinement du cas d’utilisation Afficher stagiaire

Après être authentifié, l’Administrateur peut supprimer un stagiaire existant comme


l’illustre le tableau suivant :

Cas d’utilisation Supprimer stagiaire


Acteurs Administrateur

Pré-condition Administrateur authentifié


Stagiaire existant
Post condition Stagiaire supprimé

Scénario nominal(s) - L’Administrateur clique sur le bouton « Supprimer ».


- Le système supprime le stagiaire

Scénario(s) alternatif(s)
Chapitre II: Spécification des besoins

Tableau 5 : Raffinement du cas d’utilisation Supprimer stagiaire

2.2.3. Raffinement du cas d’utilisation « Gérer stage »


Nous allons raffiner le cas d’utilisation «Gérer stage » comme le montre la figure suivante :

Figure 4 : Raffinement du cas d'utilisation gérer stage


Après être authentifié, l’Administrateur peut ajouter une stage comme l’illustre le tableau
suivant :

Cas d’utilisation Ajouter stage


Acteurs Administrateur

Pré-condition Administrateur authentifié

Post condition stage ajouté

Scénario nominal(s) -L’Administrateur accède à la page Gérer stage


-L’Administrateur clique sur le bouton « Ajouter stage»
-Le système affiche le formulaire d’ajout des stages
- L’Administrateur remplit le formulaire
- L’Administrateur clique sur le bouton « Enregistrer »
-Le système vérifie si les champs obligatoires sont manquants
-Le système ajoute les données dans la base de donnés
-Le système affiche le message « Le stage a été bien ajouté! »

Scénario(s) alternatif(s) -Si un champ obligatoire est manquant le système affiche un


Chapitre II: Spécification des besoins

message d’erreur

Tableau 6: Raffinement du cas d’utilisation ajouter stage


Après être authentifié, l’Administrateur peut modifier stage un existant comme l’illustre le
tableau suivant :

Cas d’utilisation Modifier stage


Acteurs Administrateur
Pré-condition Administrateur authentifié
Stage existant
Post condition Stage Modifié
Scénario nominal(s) -L’Administrateur accède à la page Gérer stage
-L’Administrateur clique sur le bouton « Modifier stage »
-Le système affiche le formulaire de modification des stage
-L’Administrateur remplit le formulaire
-L’Administrateur clique sur le bouton « Enregistrer»
-Le système vérifie si les champs obligatoires sont manquants
-Le système ajoute les données dans la base de donnés
-Le système affiche le message « Le stage a été bien Modifié! »
Scénario(s) alternatif(s) -Si un champ obligatoire est manquant le système affiche un
message d’erreur

Tableau 7 : Raffinement du cas d’utilisation Afficher stage

Après être authentifié, l’Administrateur peut afficher un stage existant comme l’illustre le
tableau suivant :
Cas d’utilisation Afficher stage
Acteurs Administrateur

Pré-condition Administrateur authentifié


Stage existant
Post condition Stage affiché

Scénario nominal(s) - L’Administrateur clique sur le bouton Afficher stage


-Le système cherche dans la base de donnés les stages disponibles
-Le système renvoie la liste des stage
Scénario(s) alternatif(s) -Pas de stage à afficher
Chapitre II: Spécification des besoins

Tableau 8 : Raffinement du cas d’utilisation Afficher stage

Après être authentifié, l’Administrateur peut supprimer un stage existant comme l’illustre
le tableau suivant :

Cas d’utilisation Supprimer stage


Acteurs Administrateur

Pré-condition Administrateur authentifié


Stage existant
Post condition Stage supprimé

Scénario nominal(s) - L’administrateur clique sur le bouton « Supprimer ».


- Le système supprime le stage

Scénario(s) alternatif(s)

Tableau 9 : Raffinement du cas d’utilisation Supprimer stage

2.2.3. Raffinement du cas d’utilisation « Gérer encadreur »


Nous allons raffiner le cas d’utilisation «Gérer encadreur » comme le montre la figure suivante :
Chapitre II: Spécification des besoins

Figure 5 : Raffinement du cas d'utilisation gérer encadreur


Après être authentifié, l’Administrateur peut ajouter un encadreur comme l’illustre le
tableau suivant :

Cas d’utilisation Ajouter encadreur


Acteurs Administrateur

Pré-condition Administrateur authentifié

Post condition encadreur ajouté

Scénario nominal(s) -L’Administrateur accède à la page Gérer encadreur


-L’Administrateur clique sur le bouton « Ajouter encadreur»
-Le système affiche le formulaire d’ajout des encadreurs
- L’Administrateur remplit le formulaire
- L’Administrateur clique sur le bouton « Enregistrer »
-Le système vérifie si les champs obligatoires sont manquants
-Le système ajoute les données dans la base de donnés
-Le système affiche le message « L’encadreur a été bien ajouté! »

Scénario(s) alternatif(s) -Si un champ obligatoire est manquant le système affiche un


message d’erreur

Tableau 10: Raffinement du cas d’utilisation ajouter encadreur


Après être authentifié, l’Administrateur peut modifier un encadreur existant comme
l’illustre le tableau suivant :

Cas d’utilisation Modifier encadreur


Acteurs Administrateur
Pré-condition Administrateur authentifié
Encadreur existant
Post condition Encadreur Modifié
Chapitre II: Spécification des besoins

Scénario nominal(s) -L’Administrateur accède à la page Gérer encadreur


-L’Administrateur clique sur le bouton « Modifier encadreur»
-Le système affiche le formulaire de modification des encadreurs
-L’Administrateur remplit le formulaire
-L’Administrateur clique sur le bouton « Enregistrer»
-Le système vérifie si les champs obligatoires sont manquants
-Le système ajoute les données dans la base de donnés
-Le système affiche le message « L’encadreur a été bien Modifié! »
Scénario(s) alternatif(s) -Si un champ obligatoire est manquant le système affiche un
message d’erreur

Tableau 11 : Raffinement du cas d’utilisation Afficher encadreur

Après être authentifié, l’Administrateur peut afficher un encadreur existant comme


l’illustre le tableau suivant :
Cas d’utilisation Afficher encadreur
Acteurs Administrateur

Pré-condition Administrateur authentifié


Encadreur existant
Post condition Encadreur affiché

Scénario nominal(s) - L’Administrateur clique sur le bouton Afficher encadreur


-Le système cherche dans la base de donnés les encadreurs
disponibles
-Le système renvoie la liste des encadreurs
Scénario(s) alternatif(s) -Pas d’encadreur à afficher

Tableau 12 : Raffinement du cas d’utilisation Afficher encadreur

Après être authentifié, l’Administrateur peut supprimer un stage existant comme l’illustre
le tableau suivant :

Cas d’utilisation Supprimer encadreur


Acteurs Administrateur

Pré-condition Administrateur authentifié


Encadreur existant
Chapitre II: Spécification des besoins

Post condition Encadreur supprimé

Scénario nominal(s) - L’administrateur clique sur le bouton « Supprimer ».


- Le système supprime l’ encadreur

Scénario(s) alternatif(s)

Tableau 13 : Raffinement du cas d’utilisation Supprimer encadreur

IV-Choix architectural :
L’architecture adopté dans notre développement sera à trois niveaux afin d’avoir un découpage
entre les différentes parties de l’application, à savoir la présentation, le métier et les données. 
 La couche présentation : Associée au client qui de fait est dit « léger » dans la mesure où il
n’assume aucune fonction de traitement
 La couche métier : Liée au serveur, qui dans de nombreux cas est un serveur d’application qui
va exécuter tous les calculs ou faire des requêtes vers d’autres serveurs additionnels (exemple
vers des SGBD).
 La couche de données :Liée au serveur de base de données (SGBD)

  Cette séparation respectant tout à fait le paradigme MVC une évolution des niveaux
indépendamment les uns des autres sera possible à l’avenir et permettra donc une meilleure
évolutivité de la solution.

Figure 6: Schéma de l'architecture 3-tierces adoptée

Conclusion :
Ce deuxième chapitre a été dédié à l’analyse et la spécification des besoins. Il donne alors le
feu vert pour l’amorçage de l’étude conceptuelle qui sera décrite dans le chapitre suivant.
Chapitre II: Spécification des besoins
Chapitre II: Spécification des besoins
Chapitre II: Spécification des besoins
Chapitre II: Spécification des besoins

Vous aimerez peut-être aussi