Chapitre 2 : Analyse et

spécification des besoins

Sommaire
Introduction ................................................................................
1. Identification des acteurs ..........................................................
2. Identification des besoins .........................................................
3. Diagramme de cas d'utilisation générale… ..............................
4. Diagrammes de cas d'utilisation et descriptions textuelles.
5. Diagrammes de séquence système ...........................................
Conclusion… ................................................................................

1
Introduction :
Après la présentation du cadre général de notre projet, ce chapitre sera consacré à la
spécification et d’analyse des besoins. Nous allons énumérer les besoins à satisfaire et qui
représentent les fonctionnalités à réaliser dans notre application.
La phase initiale du développement constitue l’identification des acteurs et des besoins de notre
application. Nous distinguerons les besoins fonctionnels qui représentent les fonctionnalités attendues
de notre application et les besoins non fonctionnels pour éviter le développement d’une application
non satisfaisante, de même trouver un accord commun entre les spécialistes et les utilisateurs pour
réussir le projet.

1. Identification des acteurs :

Avant d’élaborer les besoins fonctionnels, il faut commencer par définir les principaux
acteurs (utilisateurs).

Les acteurs sont des entités externes qui interagissent avec le système, comme une
personne humaine ou un robot. Une même personne (ou robot, ...) peut jouer le rôle de plusieurs
acteurs pour un système, c'est pourquoi les acteurs devraient être décrits par leur rôle, ce rôle
décrit les besoins et les capacités de l'acteur. Un acteur agit sur le système (accès de
lecture/écriture). L'activité du système a pour objectif de satisfaire les besoins de l'acteur. Les
acteurs sont représentés par un pictogramme humanoïde sous-titré par le nom de l'acteur. Les
acteurs sont classifiés en 3 catégories : les acteurs principaux (ex: visiteur, candidat, etc), les
acteurs secondaires (ex: administrateur, opérateur de maintenance, etc), les autres systèmes
(serveur, etc).

Les acteurs potentiels de notre système sont décrits comme suit :


Client : Toute personne qui a accès à l'application dont il a la possibilité de s'inscrire,
recevoir les notifications des nouvelles offres, consulter les actualités, tester ses
compétences et postuler pour les offres qui l’intéresse.

Administrateur : Cet acteur a l'accès à toutes les fonctionnalités de l'application tel
que la gestion des responsables, la gestion des départements, la gestion des offres, la
gestion des actualités et la Consultation des candidatures.

2
2. Identification des besoins :
2.1. Besoins Fonctionnels
On consacrera cette partie à la description des exigences fonctionnelles des différents acteurs
de l’application.


Candidat :

- L’inscription : le candidat doit s’enregistrer avec ses informations personnelles et doit

ajouter les fichiers résumé et photo.
- L'authentification : le candidat doit saisir ses identifiants attribués pour pouvoir accéder à
son espace.
- La modification/mise à jour de son profil : le candidat peut modifier ses informations
personnelles lors de changement ou obtention de nouvelles compétences.

- Postuler aux offres proposées : le candidat peut postuler pour l’offre qui lui convient de
mieux après lecture des informations associées au poste.

- Tests de compétences : pour valider sa candidature à l’offre le client doit passer un test
sous forme de quiz relatif à la nature de chaque offre.

- Accès aux News : le candidat peut lire les dernières actualités relatives à ETC.


Administrateur :

- L'authentification : l'administrateur doit s'authentifier pour accéder à toutes ses

fonctionnalités.
- Gestion des offres : l'administrateur a la possibilité de consulter, ajouter, modifier,
attribuer une date d’expiration et supprimer des offres.

- Gestion des départements : l'administrateur peut gérer les départements (consulter,

ajouter, modifier ou supprimer un département).

- Gestion des actualités : ajouter des nouvelles actualités avec le titre, la description et
l'image correspondante à chaque nouveauté. Il a le droit également à modifier ou
supprimer une actualité.

3
 - Consultation des candidats : l'administrateur peut consulter la liste des clients déjà
inscris tout en pouvant mettre à jour, modifier et supprimer les profils.

- Gestion des candidatures : l’administrateur peut consulter les candidatures, voir les
résultats des tests de compétences et ainsi approuver ou refuser la demande ; en cas
d’acceptation de candidature planifier une date d’entretien.
- Gestion des tests de compétences : l'administrateur peut créer, modifier et
supprimer les tests (créer des questions et des réponses dont une question peut avoir un
nombre infini de réponses).

- Consultation des statistiques : l'administrateur peut consulter la liste des clients

connectés sur l’application et les informations relatives à leurs utilisations de pages, type
de média de connexion.

2.2. Besoins non Fonctionnels

Les besoins non fonctionnels sont les contraintes sous lesquelles le système doit rester
opérationnel. Il doit répondre à plusieurs exigences parmi lesquelles nous citons :
✓ Contraintes ergonomiques
• Convivialité et facilité d’utilisation : Il faut assurer une certaine facilité de
manipulation et d’accès à l’information pour l’utilisateur. L’interface doit
être bien structurée, claire et simple pour l’utilisateur.
• L’interface doit être compatible avec n'importe quelle dimension d’écran que ce
soit en hauteur ou en largeur, facile à manipuler, et compréhensible.
• Le choix des noms des champs de l’interface doit être explicite et significatif.
✓ Contrainte technique :
• Les erreurs doivent être signalées par des messages d’erreurs clairs et
significatifs.
• Le code développé doit être clair et facile à maintenir.

4
3. Diagramme de cas d'utilisation générale :

Chaque usage effectué par les acteurs est représenté par un cas d’utilisation. Chacun de
ces cas représente une fonctionnalité qui a pour objectif produire le résultat attendu. Ainsi, le
diagramme de cas d’utilisation décrit l’interaction entre le système et l’acteur en subvenant aux
besoins de l’utilisateur et tout ce que doit faire le système pour l’acteur. Ci-dessous, nous allons
présenter le diagramme de cas d’utilisation générale.

Diagramme de cas d'utilisation générale

5
 4. Diagrammes de cas d'utilisation et descriptions textuelles :
4.1 : Diagrammes de cas d'utilisation détaillés de l'acteur Client :

Diagramme de cas d'utilisation « Postuler Offres » :

: Diagramme de cas d'utilisation « Postuler Offres »

- Description textuelle :

Tableau : Diagramme de cas d'utilisation "Postuler Offres"

Cas Cas d’utilisation « Postuler Offres »

Acteur Candidat
Précondition Le candidat accède à l’application
Le candidat s’est authentifié correctement à l’application
Post-condition Offres mis à jour
Scénario 1. Le système affiche la page d’accueil
Nominal 2. Le système affiche la liste des nouveautés
3. Le client choisit l’offre affichée et désirée
Scénario Authentification erronée
Alternatif

6
4.2 : Diagrammes de cas d'utilisations détaillés de l’administrateur :

Diagramme de cas d'utilisation « Gérer Candidats » :

Diagramme de cas d'utilisation « Gérer Candidats »

- Description textuelle :
Tableau : Diagramme de cas d'utilisation "Gérer Candidats"

Cas Cas d’utilisation « Gérer Candidats »

Acteur Administrateur
Précondition L’administrateur est connecté et s’est authentifié correctement à
l’application
Un candidat est ajouté ou supprimé
Un candidat est modifié
Post-condition Liste des candidats mis à jour
Scénario 1. L’administrateur accède à son espace
Nominal 2. L’administrateur complète/modifie les champs du candidat
3.Le système affiche la liste des clients à modifier
4.Le système affiche la liste des clients à supprimer
Scénario Authentification erronée de l’administrateur
Alternatif L’administrateur ne sélectionne aucun utilisateur à supprimer

7
 
Diagramme de cas d'utilisation « Gérer Candidatures » :

Diagramme de cas d'utilisation « Gérer Candidatures »

- Description textuelle :
Tableau : Diagramme de cas d'utilisation "Gérer Candidatures"

Cas Cas d’utilisation « Gérer Candidatures »

Acteur Administrateur
Précondition L’administrateur est connecté à l’application
Une nouvelle candidature est ajoutée
Post-condition Liste des candidatures mis à jour
Scénario 1.L’administrateur accède à son espace
Nominal 2.Le système affiche la page d’accueil
3.L’administrateur choisit la rubrique gestion des candidatures
4.Le système affiche la liste des candidatures respectives aux
offres
5.L’administrateur visionne les informations (résultat tests, CV)
6.L’administrateur exécute son verdict
7. En cas d’approbation, le système affiche le calendrier pour
prise de rendez vous
8. Le système envoi une notification au candidat
Scénario Authentification erronée
Alternatif

8
 
Diagramme de cas d'utilisation « Gérer Actualités » :

Diagramme de cas d'utilisation « Gérer Actualités »

- Description textuelle :

Tableau : Diagramme de cas d'utilisation "Gérer Actualités"

Cas Cas d’utilisation « Gérer Actualités »

Acteur Administrateur
Précondition L’administrateur est connecté à l’application
Une nouvelle actualité est ajoutée
Une actualité existante est modifiée
Une actualité est supprimée
Post-condition Liste des actualités mis à jour
Scénario 1.L’administrateur accède à son espace
Nominal 2.Le système affiche la page d’accueil
3.L’administrateur choisit la rubrique gestion des actualités
4.Le système affiche les fonctionnalités de mis à jour des
actualités
5. L’administrateur saisit les données d’ajout d’une nouvelle
actualité
6. Le système affiche la liste des actualités à modifier
7.Le système affiche la liste des actualités à supprimer
Scénario Authentification erronée
Alternatif L’administrateur ajoute une actualité déjà existante
Le système affiche un message d’erreur suite non-respect de
type de données ajoutées/modifiées
L’administrateur ne coche aucune actualité à supprimer

9
5. Diagrammes de séquence système :
Lors de cette étape, nous décrivons le comportement dynamique du système ainsi que les
différentes interactions entre les acteurs et le système de notre projet. En effet, nous allons
illustrer les principaux scénarios possibles du système au moyen de diagrammes de séquence qui
mettent en évidence l’ensemble ordonné de messages échangés par les objets. Les diagrammes
de séquences sont la représentation graphique des interactions entre les acteurs et le système selon
un ordre chronologique relatif à la formulation UML.

5.1 : Diagrammes de séquence système pour l'acteur Client :


Diagramme de séquence « Inscription »
Ces diagrammes de séquence représentent le processus d'inscription. Il représente les interactions
entre l'acteur et le système. Le processus commence lorsque le candidat accède à l'application et
demande de s'enregistrer. Une page d'inscription s’affiche et le candidat est mené à saisir ses
données personnelles pour pouvoir accéder à son espace personnel par la suite. Cette opération
se fait pour n’importe quelle personne cible qui accède à l'application.

Diagramme de séquence « Inscription »

10

Diagramme de séquence « Postuler à une offre »

Le schéma suivant représente les diagrammes de séquence de processus « Postuler ». Tout

utilisateur doit passer par cette opération pour postuler aux différentes offres de l’ETC.

Diagramme de séquence « Postuler »

11
 
Diagramme de séquence « Consulter actualités »
Le diagramme de séquence ci-dessous modélise le processus consultation des actualités. Il
représente les interactions entre le prospect et le système. Depuis la page d'accueil le prospect
aura la possibilité de choisir la rubrique actualités.

Diagramme de séquence « Consulter actualités »

12
 5.2 : Diagrammes de séquence système pour l'acteur Administrateur :

Diagramme de séquence « Ajouter une offre »

Ce diagramme modélise le processus d'ajout d'une nouvelle offre. Il représente les

interactions entre l’administrateur et le système.

Une page d'ajout s'affiche, l’administrateur ajoute une nouvelle offre en remplissant les
données de cette dernière avec une description textuelle, la lier à un département spécifique, la lier à
une série de tests de compétences et à une date d’expiration.

Diagramme de séquence « Ajouter une offre »

13
 
Diagramme de séquence « Modifier un département »

Ce diagramme de séquence modélise le processus de modification d'un département déjà

existant. Il représente les interactions entre les différents acteurs : une page de gestion des
départements s'affiche après l'authentification de l’administrateur puis en choisissant le
département concerné parmi la liste, l’administrateur effectuera sa tâche et validera.

Diagramme de séquence « Modifier un département »

14
 
Diagramme de séquence « Refuser une candidature »

Ce diagramme de séquence modélise le processus de suppression d'une candidature déjà

existante. Il représente les interactions entre l’administrateur et le système. Le système affichera
la liste des candidatures liés à une offre. Le responsable vérifie le résultat des tests de
compétences, lis le CV et en cas de refus choisis la candidature à supprimer.

Diagramme de séquence « Refuser une candidature »

15
Conclusion :
Dans ce chapitre, nous avons approfondi le niveau de vision du projet et nous a permis de bien
comprendre les tâches à réaliser. Entre autre, on a pu prévoir les problèmes à rencontrer et essayer
de chercher des solutions pour les surmonter.

Nous avons essayé de mettre en valeur les besoins fonctionnels et techniques du projet et les
différents scénarios d'utilisation de l’application.

Le chapitre suivant va mieux clarifier le bon fonctionnement de notre projet à travers la

conception de tous les modules.

16
 Chapitre 3 : Conception

Sommaire
Introduction ...................................................................... 29
I. Etude technique… .......................................................... 29
II. Architecture mise en place ........................................... 30
III. Diagramme de déploiement ........................................ 32
IV. Diagramme de classe… .............................................. 33
V . Diagramme de séquence objet..................................... 34
VI. Diagramme d’activité… .............................................. 37
Conclusion… ..................................................................... 38

17
Introduction :
Dans ce chapitre, nous allons présenter la phase de conception de notre projet. Cette partie
a pour rôle de réaliser ce qui a été analysé en le concevant dans un premier lieu, le mettant en
œuvre par la suite et le déployant vers la fin.

Tout d'abord, pour rapprochent encore plus de la réalité physique, nous commençons par
la présentation de diagramme de déploiement. Ensuite, on s'intéresse à la modélisation
dynamique qui traite l'interaction entre les différents objets à travers les diagrammes de séquences
objet. Puis nous présenterons le diagramme de classe objet. Enfin, nous exposons le diagramme
d'activité afin d'identifier le comportement de notre système.

I. Etude technique :
L’architecture de notre application est de type client-serveur où un ordinateur interagit
avec d’autres sur internet ; alors l’architecture la plus adaptée et adoptée pour notre projet est
celle composée de 3 parties :


Une interface web : c'est l'application à travers laquelle l'administrateur ou/et les
candidats pourrons accéder à leurs fonctionnalités.

Un serveur web : C'est le serveur HTTP qui englobe toutes les fichier php, HTML et
Type script . Il assure la communication entre les différents composants de notre
projet tel que l'interface web et la base de donnée Mysql.

Un serveur base de donnée SGBD : On utilise le logiciel MySql, qui contient toutes nos
tables de notre projet, il permet de lire, écrire, modifier, trier, transformer ou même
imprimer les données stockées.

Architecture du projet

18
II. Architecture mise en place :

1. Architecture de la solution :

Notre application est composée de trois couches « 3 tiers ». Il s'agit d'une structure logique
d'architecture applicative qui vise à modéliser une application comme un empilage de trois
couches logicielles (étages, niveaux, tiers…).

Le rôle de chaque couche est :

 La présentation des données : correspondant à l'affichage, la restitution sur le poste de

travail et le dialogue avec l'utilisateur.

 Le traitement métier des données : correspondant à la mise en œuvre de l'ensemble des

règles de gestion et de la logique applicative.

 L'accès aux données persistantes : correspondant aux données qui sont destinées à être
conservées momentanément ou définitivement.

Architecture de l’application

19
 1.1 : Couche présentation des données :

Elle correspond à la partie visuelle de l’application qui est en interaction directe avec les
utilisateurs. On parle d'interface homme machine. Elle peut être réalisée par une application
graphique ou textuelle. Elle est composée est du code HTML5, TypeScript et CSS3.

1.2 : Couche métier :

Appelée aussi la couche logique, elle correspond à la partie fonctionnelle de l'application, celle
qui implémente la « logique », et qui décrit les manipulations que l'application traite sur les
données en fonction des requêtes des utilisateurs, réalisées à partir de la couche présentation.

1.3 : Couche accès aux données :

C’est la partie gérant l'accès aux données du système et leurs persistances. Ces données peuvent
être propres au système, ou gérées par un autre système.

2. Architecture MVC :
Le patron de conception Modèle-Vue-Contrôleur est un patron de conception architectural , qui
organise l'interface utilisateur d'une application en trois composants :

 Un modèle (contenant aussi bien des données que des opérations)

 Une vue (responsable de la présentation aux utilisateurs)

 Un contrôleur, dont le rôle est de gérer les évènements et la synchronisation entre la Vue
et le Modèle

Les éléments du Framework MVC

20
III. Diagramme de déploiement :
Le diagramme de déploiement permet d'illustrer l'architecture physique du système et de
montrer la relation entre ses différentes composantes. Voici le diagramme de déploiement de
notre projet.

Diagramme de déploiement

21
IV. Diagramme de classe :
Le diagramme de classes est le plus important de la modélisation orientée objet, il est le
seul obligatoire lors d'une telle modélisation et permet de monter la structure interne. Il fournit
une représentation abstraite des objets et aspects temporels et dynamiques du système qui vont
interagir pour réaliser les cas d'utilisation.

Une classe est un ensemble de fonctions et de données (attributs) qui sont interreliées par un
champ sémantique. Les classes sont utilisées dans la programmation orientée objet. Elles
permettent de modéliser un programme et ainsi de découper une tâche complexe en plusieurs
petits travaux simples.

Diagramme de classe

22
 Ce diagramme présente les différentes classes de notre projet qu'on va utiliser. Chaque
classe est composée d'un ensemble de fonctions et de données (attributs) qui sont liées ensemble
par un champ sémantique.

Les classes peuvent être liées entre elles grâce au mécanisme d'héritage qui permet de mettre en
évidence des relations de parenté. D'autres relations sont possibles entre des classes, chacune de
ces relations est représentée par un arc spécifique dans le diagramme de classes.

V. Diagramme de séquence d'objet :

Le diagramme de séquence d'objet permet de mieux expliquer les différentes interactions
entre l'acteur et les objets de notre projet. Nous allons présenter quelques diagrammes les plus
pertinentes en mettant en évidence l'ensemble ordonné des messages échangées entre les
différents objets.

Diagramme de séquence d'objet pour l'acteur client :

Diagramme de séquence d’objet « Inscription »

Diagramme de séquence objet « Inscription »

23
 Le candidat accède à l’application. Pour accéder à toutes les fonctionnalités offertes, il
doit s'enregistrer. Il demande le formulaire d'enregistrement et saisie ses données personnelles
pour pouvoir les utiliser par la suite dans la phase d'authentification.

Une fois le formulaire est rempli, le système vérifie ses données. Si elles sont valides,
automatiquement une requête d'ajout d'un nouveau client s'exécute, et ce dernier sera sauvegardé
dans la base de données et la page d'authentification s'affiche.


Diagramme de séquence d’objet « Postuler »

Diagramme de séquence objet « Postuler »

24
 Après authentification et affichage des détails de l’offre choisie, le candidat commence
par cliquer sur « postuler » puis on lui demande à vérifier son profil pour effectuer des mises à
jour s’il a obtenu des nouvelles compétences ou que son profil est incomplet ; puis confirme pour
passer à l’étape suivante de passer le test de compétence relative à l’offre qui correspond à des
questions avec des choix aléatoires et termine par valider.

Diagramme de séquence d'objet pour l'acteur Administrateur :


Diagramme de séquence d’objet « Valider Candidature »

Toute candidature à une offre fait l’objet d’une étude du recruteur/administrateur pour
qualifier le candidat et ainsi procéder à l’étape d’entretien physique par rendez-vous selon
planning.

Diagramme de séquence objet « Valider candidature »

25
VI. Diagramme d'activité :
Les diagrammes d'activité permettent de mettre l'emphase sur les traitements. Ils sont donc
adéquats à la représentation du cheminement de flots de contrôle et de flots de données. Ils
permettent ainsi de modéliser le procédé d'une méthode ou l’enchainement d'un cas d'utilisation.


Diagramme d'activité Statistiques :

Pour accéder au différents statistiques, l’administrateur est appelé à saisir son login et son
mot de passe. Si les identifiants ne sont pas validés, l’administrateur est appelé à saisir des
identifiants valides. Sinon, il accède à l’interface d’accueil de l’application. Par la suite, il doit
choisir le menu « statistiques ». Le système vérifie la disponibilité de données. Si les données ne
sont pas disponibles, un message d’erreur s’affiche pour indiquer la non disponibilité des
données. Sinon, le rapport s’affiche. L’administrateur peut, de ce fait, le consulter et il a même
la possibilité de l’exporter sous différents formats.

Diagramme d'activité « Statistiques »

26
 
Diagramme d'activité Supprimer une offre :

La figure ci-dessous illustre le diagramme d’activité pour le cas d'utilisation Supprimer

une offre. Il décrit d'une manière plus simple le déroulement de flux et des événements entre
les différentes étapes de cas d'utilisation.

Diagramme d'activité « Supprimer une offre »

Conclusion :
Dans ce chapitre, nous avons approfondi le niveau de vision du projet. Nous avons terminé
la phase de conception. Dans le chapitre suivant, nous allons passer à la phase réalisation nous
présenterons les différentes technologies que nous avons utilisé. Aussi nous mettrons quelques
captures écrans des interfaces graphiques.

27
 Chapitre 4 : Réalisation

Sommaire
Introduction .........................................................................
I. Environnement de travail ...................................................
II. Processus de développement ...........................................
III. Scénarios et tests ............................................................

28
58