Version Finale

Rubrique Tunisienne
Ministère de l’Enseignement Supérieure et de la Recherche Scientifique Université

de Jendouba
Faculté des Sciences Juridique Economique et de Gestion de Jendouba
Rapport de Projet de Fin d’Etudes
Présenté en vue de l’obtention du
Diplôme de License Fondamentale en Informatique de Gestion
Par
Mahjoubi Ranya
Conception et développement d’un site web responsive pour

La Startup DATA2AI
Encadrant académique : Mr.

Sellami Mokhtar
Année universitaire : 2021/2022

Dédicace
J’offre ce modeste travail :

A mes chers parents,
Aucune dédicace ne pourra faire témoin de mon profond amour, mon immense
gratitude et plus grand respect à votre égard. On n’oubliera jamais la tendresse
et l’amour dont vous m’avez entourée depuis mon enfance et l’encouragement
dans les moments les plus difficiles de ma scolarité.
A mes adorables frères, qui par les soutiens moraux et les encouragements,
multipliait mes efforts, pour pouvoir réaliser parfois l’impossible.
A tous mes amis, et à tous ceux qu’on aime et à toutes les personnes qui m’ont
encouragée et se donner la peine de me soutenir durant cette formation.
A mes chers enseignants sans exception.

A ceux qui me sont chers.
Mahjoubi Ranya
Remerciement
Nous tenions tout d’abord à remercier DIEU de nous avoir donné le courage, la
force et la volonté pour achever ce travail
La réalisation de ce projet a été possible grâce aux soutiens de plusieurs

personnes à qui je voudrais témoigner toute ma gratitude
J’adresse mes vifs remerciements à toute personne contribuant de près ou de

loin à la réalisation de ce travail.
Nous tenions à remercie vivement la faculté de sciences juridiques économiques

et de gestion de Jendouba (FSJEGJ).
Mes remerciements le plus sincères à Mr. Sellami Mokhtar, mon encadrant à la

faculté de sciences juridiques économiques et de gestion de Jendouba, pour son
encadrement tout au long de notre travail.
Enfin, mes remerciements à tous mes professeurs. Ensuite, je remercie les

membres de jury pour avoir accepté d’évaluer le résultat auquel j’arrivés.
Table des matières
Introduction Générale ............................................................................................................................. 1

Chapitre 1| Cadre de projet .................................................................................................................... 2
1 Introduction ..................................................................................................................................... 2
2 Data2AI............................................................................................................................................. 2
Problématique ................................................................................................................................. 3
3 Cahier des charges technique .......................................................................................................... 3
4 Solution proposée ............................................................................................................................ 9
5 Approche méthodologique .............................................................................................................. 9
5.1 Etude comparative de quelques méthodologies .......................................................................... 9
5.2 Choix de la méthodologie Scrum ................................................................................................ 10
5.3 Processus Scrum.......................................................................................................................... 11
5.4 Le langage UML ........................................................................................................................... 12
6 Conclusion ...................................................................................................................................... 12
Chapitre 2 | Analyse et spécification des besoins ................................................................................ 13
1 Introduction ................................................................................................................................... 13
2 Identification des acteurs............................................................................................................... 13
2.3 Analyse des besoins .................................................................................................................... 14
2.3.1 Besoins fonctionnels ................................................................................................................ 14
2.3.2 Besoins non fonctionnels ......................................................................................................... 15
2.4 Diagramme de cas d’utilisation globale ...................................................................................... 16
2.5 Le Backlog du produit.................................................................................................................. 17
3.1 Livrables du projet....................................................................................................................... 19
3.2 Risques du projet ........................................................................................................................ 19
4. Environnement de travail.............................................................................................................. 20
4.1 environnement matériel ............................................................................................................. 20
4.2 environnement logiciel ............................................................................................................... 20
4.3 Système de gestion de base de données .................................................................................... 23
4.4 Choix technologiques .................................................................................................................. 23
4.5 Organigramme des taches .......................................................................................................... 24
4.6 Planifications de projet : ............................................................................................................. 24
4.7 Diagramme de Gantt : ................................................................................................................. 24
4.8 Architecture de l’application....................................................................................................... 25
4.8.1 Architecture 3-tiers .................................................................................................................. 25
4.8.2 Architecture logicielle : MVC.................................................................................................... 26
5. Conclusion ..................................................................................................................................... 28
Chapitre 3 |Mise en œuvre de sprint 1 ................................................................................................ 31
1 Introduction ................................................................................................................................... 31
2 Backlog de sprint ............................................................................................................................ 31
3 Tableau des taches ......................................................................................................................... 32
4.1 Identification des acteurs............................................................................................................ 32
4.1.1 Raffinement des cas d’utilisation de sprint 1 : ......................................................................... 33
4 Conception ..................................................................................................................................... 39
4.1 Conception statique .................................................................................................................... 39
4.1.1 Diagramme de classe de sprint 1 ............................................................................................. 39
4.1.2 Dictionnaire des données du sprint 1 ...................................................................................... 40
5 Conception dynamique .................................................................................................................. 41
5.1 Diagramme de séquence du sprint 1 .......................................................................................... 41
5.2 Diagramme d’activité .................................................................................................................. 47
6 Réalisation du sprint ...................................................................................................................... 50
6.1 Les interfaces ..................................................................................................................... 50
6.2 Interface inscription .................................................................................................................... 50
6.3 Interface d’authentification ........................................................................................................ 51
7 Test et validation ............................................................................................................................ 53
8 Conclusion ...................................................................................................................................... 56
Chapitre 4 | Mise en œuvre du sprint 2 ............................................................................................... 59
1 Introduction ................................................................................................................................... 59
2 Backlog du sprint 2 ......................................................................................................................... 59
3 Tableau des taches ......................................................................................................................... 60
4 Phase Analyse................................................................................................................................. 61
4.1 Indentification des acteurs ................................................................................................ 61
4.1.1 Raffinement des cas d’utilisation de sprint 2 : ........................................................................ 61
5 Conception ..................................................................................................................................... 67
5.1 Conception statique : .................................................................................................................. 67
5.1.1 Diagramme de classe de sprint 2 ............................................................................................. 67
5.1.2 Dictionnaire des données du sprint 2 ...................................................................................... 68
5.2 Conception dynamique ............................................................................................................... 70
5.2.1 Diagramme de séquence ......................................................................................................... 70
5.2.2 Le diagramme d’activité ........................................................................................................... 74
6 Réalisation de sprint....................................................................................................................... 76
6.1 Les interfaces .............................................................................................................................. 76
6.2 Interface <<consulter projet>> ................................................................................................... 77
7 - Test et validation.......................................................................................................................... 78
8 Conclusion ...................................................................................................................................... 79
Chapitre 5 | Mise en œuvre de sprint 3................................................................................................ 85
1 Introduction : ................................................................................................................................. 85
2 Backlog du sprint 3 : ....................................................................................................................... 85
3 Tableau des taches : ....................................................................................................................... 86
4 Phase d’analyse : ............................................................................................................................ 86
4.1 Identification des acteurs............................................................................................................ 86
5 Conception ..................................................................................................................................... 91
5.1 Conception statique .................................................................................................................... 91
5.1.1 Diagramme de classe globale :................................................................................................. 91
5.1.2 Dictionnaire de données de sprint 3 ........................................................................................ 92
6 Conception dynamique .................................................................................................................. 94
6.1 Diagramme de séquence ............................................................................................................ 94
6.2 Diagramme d’activité ........................................................................................................ 97
7 Réalisation du sprint ...................................................................................................................... 99
7.2 les interfaces : ............................................................................................................................. 99
7.2.1 Interface Gérer service : ........................................................................................................... 99
7.2.2 Interface consulter statistiques ............................................................................................. 100
8 Test et validation .......................................................................................................................... 101
9 Conclusion .................................................................................................................................... 102
Conclusion générale ............................................................................................................................ 103
Bibliographie ....................................................................................................................................... 104
Liste des figures
Figure 1 - Maquette de la page d'accueil ................................................................................................. 4

Figure 2 - Maquette de la page service ................................................................................................... 5
Figure 3 - Maquette de la page contact ................................................................................................... 6
Figure 4 - Maquette de la page register ................................................................................................... 7
Figure 5 - Maquette de la page login ....................................................................................................... 8
Figure 6 - Processus Scrum ................................................................................................................... 11
Figure 7 - Diagramme de cas d'utilisation globale ................................................................................ 16
Figure 8 - Caractéristique du PC ........................................................................................................... 20
Figure 9 - Logo wampserver ................................................................................................................. 21
Figure 10 - Logo StarUML ................................................................................................................... 21
Figure 11 - Logo Visual Studio Code.................................................................................................... 21
Figure 12 - Logo Lucidchart ................................................................................................................. 22
Figure 13 - Logo Trello ......................................................................................................................... 22
Figure 14 - Logo Gantt Project.............................................................................................................. 23
Figure 15 - Organigramme des taches ................................................................................................... 24
Figure 16 - Diagramme de Gantt ........................................................................................................... 25
Figure 17 - Architecture 3-tiers ............................................................................................................. 26
Figure 18 - Schéma du modèle MVC .................................................................................................... 27
Figure 19 - Tableau des taches .............................................................................................................. 32
Figure 20 - Diagramme de cas d'utilisation de sprint 1 ......................................................................... 33
Figure 21 - Diagramme de cas d'utilisation <<s'inscrire>> ................................................................... 34
Figure 22 - Diagramme de cas d'utilisation <<Authentification>> ....................................................... 35
Figure 23 - Diagramme de cas d'utilisation <<Gérer utilisateur>> ....................................................... 36
Figure 24 - Diagramme de classe de sprint 1 ........................................................................................ 39
Figure 25 - Principe de diagramme de séquence ................................................................................... 41
Figure 26 - Exemple message asynchrone ............................................................................................ 42
Figure 27 - Diagramme de séquence <<S'inscrire>> ............................................................................ 43
Figure 28 - Diagramme de séquence <<S'authentifier>> ...................................................................... 44
Figure 29 - Diagramme de séquence <<Bloquer utilisateur>> ............................................................. 45
Figure 30 - Diagramme de séquence <<Débloquer utilisateur>> ......................................................... 46
Figure 31 - Diagramme d'activité <<S'inscrire>> ................................................................................. 47
Figure 32 - Diagramme d'activité <<Authentification>> ...................................................................... 48
Figure 33 - Diagramme d'activité <<Bloquer utilisateur>> .................................................................. 49
Figure 34 - interface signup................................................................................................................... 50
Figure 35 - Interface Authentification ................................................................................................... 51
Figure 36 – Interface user...................................................................................................................... 52
Figure 37 - Tableau des taches .............................................................................................................. 60
Figure 38 - Diagramme de cas d'utilisation de sprint 2 ......................................................................... 61
Figure 39 - Diagramme de cas d'utilisation ........................................................................................... 62
Figure 40 - Diagramme de cas d'utilisation <<Gérer projet >> ............................................................ 63
Figure 41 - Diagramme de cas d'utilisation <<Consulter projet>> ....................................................... 66
Figure 42 - Diagramme de classe du sprint 2 ........................................................................................ 67
Figure 43 - Diagramme de séquence <<créer projet>> ......................................................................... 70
Figure 44 - Diagramme de séquence <<Consulter projet>> ................................................................. 71
Figure 45 - Diagramme de séquence <<Accepter projet>> .................................................................. 72
Figure 46 - Diagramme de séquence <<Refuser projet>> .................................................................... 73
Figure 47 - Diagramme d'activité <<Créer projet>> ............................................................................. 74
Figure 48 - Diagramme d'activité <<Accepter projet>> ....................................................................... 75
Figure 50 - Interface gérer projet .......................................................................................................... 76
Figure 51 - Interface consulter projet .................................................................................................... 77
Figure 52 - Tableau des taches du sprint 3 ............................................................................................ 86
Figure 53 - Diagramme de cas d'utilisation <<Gérer service>> ........................................................... 87
Figure 54 - Diagramme de cas d'utilisation <<Passer réclamation>> ................................................... 89
Figure 55 - Diagramme de cas d'utilisation <<Consulter statistique>> ................................................ 90
Figure 56 - Diagramme de classe globale ............................................................................................. 91
Figure 57 - diagramme de séquence <<ajouter service>> .................................................................... 94
Figure 58 - diagramme de cas d’utilisation <<passer réclamation>> ................................................... 95
Figure 59 - diagramme de séquence <<consulter statistique>> ............................................................ 96
Figure 60 - Diagramme d'activité <<Modifier service>> ..................................................................... 97
Figure 61 - Diagramme d'activité <<Passer réclamation>> .................................................................. 98
Figure 62 - Interface gérer service ........................................................................................................ 99
Figure 63 - Interface consulter statistiques .......................................................................................... 100
Liste des tableaux
Tableau 1 - Etude comparatif de quelque méthodologie......................................................................... 9

Tableau 2 - Identification des besoins ................................................................................................... 13
Tableau 3 - Backlog du produit ............................................................................................................. 17
Tableau 4 - Livrables du projet ............................................................................................................. 19
Tableau 5 - Risques du projet ................................................................................................................ 19
Tableau 6 - Backlog du sprint 1 ............................................................................................................ 31
Tableau 7 - Description textuelle du cas d'utilisation <<S'inscrire>> ................................................... 34
Tableau 8 - Description textuelle de cas d'utilisation <<s'authentifier>> ............................................. 35
Tableau 9 - Description textuelle du cas d'utilisation <<Bloquer utilisateur>> .................................... 37
Tableau 10 - Description textuelle du cas d'utilisation <<Débloquer utilisateur>> .............................. 38
Tableau 11 - Dictionnaire de données <<utilisateur>> ......................................................................... 40
Tableau 12 - Dictionnaire de données <<administrateur>> .................................................................. 40
Tableau 13 - Fiche test fonctionnel de l'interface <<Inscrire>> ........................................................... 53
Tableau 14 - Fiche test fonctionnel de l'interface <<Blocage>>........................................................... 54
Tableau 15 - Fiche test fonctionnel de l'interface <<Déblocage>> ....................................................... 55
Tableau 16 - Backlog du sprint 2 .......................................................................................................... 59
Tableau 17 -Description textuelle de cas d'utilisation <<créer projet>> ............................................... 62
Tableau 18 - Description textuelle de cas d'utilisation <<Accepter projet>> ....................................... 64
Tableau 19 - Description textuelle de cas d'utilisation <<Refuser projet>> ......................................... 65
Tableau 20 - Description textuelle de cas d'utilisation <<Consulter projet>> ...................................... 66
Tableau 23 - Dictionnaire des données <<projet>> .............................................................................. 69
Tableau 24 - Dictionnaire de données <<service>> .............................................................................. 69
Tableau 25 - Test fonctionnel de l'interface <<Acceptation>> ............................................................. 78
Tableau 26 - Backlog du sprint 3 .......................................................................................................... 85
Tableau 27 - Description textuelle de cas d'utilisation <<Gérer service>>........................................... 88
Tableau 28 - Description textuelle de cas d'utilisation <<Passer réclamation>> .................................. 89
Tableau 29 - Description textuelle de cas d'utilisation <<Consulter statistique>> ............................... 90
Tableau 32 - Dictionnaire des données <<projet>> .............................................................................. 93
Tableau 33 - Dictionnaire de données <<service> ................................................................................ 93
Tableau 34 - Dictionnaire des données <<réclamation>> .................................................................. 93
Tableau 35 - Test fonctionnel de l'interface <<réclamation>> ........................................................... 101
Introduction Générale
De nos jours, l’informatique peut se trouver partout et fait partie du quotidien de

bien de personnes. Il a effectivement été vu que rien ne fonctionne plus
réellement sans elle, les écoles, les postes, les magasins, toutes les sociétés en font
usage. Il a fallu que chaque personne s’adapte à la notion d’informatique en tous
genres.
Ce travail a été réalisé dans le cadre de notre projet pour l’obtention de Diplôme
de Licence Fondamentale en Informatique de gestion. Ce dernier consiste à
concevoir et à développer un site web responsive pour la startup
<<DATA2AI>>.
Cinq parties nous permettront de présenter notre travail : Dans le premier chapitre
intitulé <<Cadre de projet>>, on va commencer par la présentation de notre cadre
de projet ainsi le choix méthodologique à suivre.
Dans le deuxième chapitre nommé <<Spécification des besoins >>, il a comme
objectif la détermination des besoins fonctionnels ainsi que les besoins non
fonctionnels de notre application.
Dans les chapitres 3, 4 et 5 <<Mise en œuvre de sprint 1, 2 et 3>>, on va
distinguer les différents cas d’utilisation et détailler les diagrammes de classe
global et les diagrammes de séquence.et les réalisations des sprints, on va définir
l’environnement, les multiples outils de développement et les différentes
interfaces graphiques de notre application suivie par les tests de l’application.
1
FSJEGJ Chapitre 1 : Cadre de projet
Chapitre 1| Cadre de projet
1 Introduction
Dans ce premier chapitre, nous commençons par une présentation de l’étude de l’existant et
nous introduisons la solution proposée tout en évoquant l’intérêt de notre projet. A la fin de ce
chapitre, nous terminons par une présentation de la méthodologie adoptée pour la réalisation de
notre application.
2 Data2AI
DATA2AI est une startup du conseil en nouvelles technologies et en nouveaux systèmes IT

intelligents (Big Data, Cloud, Intelligence Artificielle), en stratégie numérique et digitale, et la
cybersécurité.
Expertises : Data2ai accompagne les entreprises sur l’implémentation d’infrastructures

sécurisées et réalisation des projets IT/ grâce à leur experts Clouds et DevOps et les plateformes
Big Data permettant à mieux répondre aux problématiques et aux enjeux d’aujourd’hui :
Transformation digitale, développement, technologies et innovation. Nos experts BI et Big Data
Analytics vous accompagnent à la mise en place les outils de pilotage adaptés à vos enjeux
business, depuis le choix de la solution jusqu’à l’élaboration des Dashbording et reporting.
Nos Experts et nos formateurs en nouvelles technologies, vous accompagnent afin de mettre en
œuvre des plateformes forte valeur ajoutée et innovants dans vos projets de formation ou SI.
Technologies | Data2AI vous accompagne afin accéder à et maitriser de nombreuses
technologies de pointes comme le cloud/Big Data /ML/Devops pour la réalisation de vos projets
IT/BI en prémisse, Multicloud ou Cloud Hybride.
Plateformes Cloud | Des experts certifiés maitrisant les environnements cloud, vous
accompagne à déployer vos projets sur les 3 Big de plateformes cloud pour mieux répondre à
vos exigences en agilité : Cloud Public AWS, Cloud Public Azure.
Big Data/ Machine Learning| Data2AI vous propose des solutions technologiques
pragmatiques D’analyse avancée, conçues pour fournir aux entreprises différents types
d’analyse (Big Data Analytics et Data Science), permettant la transition vers un modèle
économique fondé sur la valeur ajoutée des données.
2
Problématique
La startup data2ai n'a pas de site web, alors que nous sommes à une époque où toutes
les startups ont un site web moderne.
3 Cahier des charges technique
Ce cahier des charges a pour objectif de définir un site Internet qui permettra aux clients de
trouver les informations nécessaires de notre startup DATA2AI.
La maquette basique composées des grilles de positionnement se trouve directement dans le
présent cahier des charges.
• Front office
Liste des pages :
- Page d’accueil
- Page about
- Page service
- Page contact
- Page registre
- Page login
Menu principal
Le menu principal, horizontal, se trouve sur toutes les pages du site et permet de naviguer dans
chacune des rubriques.
Les noms des rubriques doivent être en texte.
Rubrique :
- Accueil
- About
- Service
- Contact
3
Figure 1 - Maquette de la page d'accueil
4
Page de service :
Cette page permet de lister tous les services offerts par notre startup, et de trouver le service
qu’on recherche.
Le menu est identique au menu de la page d’accueil. On affiche le nom de la service (H1) puis
le texte de présentation, tous les services sur une seule page.
Figure 2 - Maquette de la page service
5
Page contact :
Figure 3 - Maquette de la page contact
6
Page register :
Figure 4 - Maquette de la page register
7
Page login
Figure 5 - Maquette de la page login
8
4 Solution proposée
Comme solution nous proposons de développer un site web responsive"Data2AI",

pour but de faciliter la communication entre les équipes, les consultants et les clients ce
site permet à DATA2AI d’exposer les différents services pourtant sur qui sont basées
sur les nouvelles Technologies, les plateformes Cloud, Big Data et le Machine Learning.
5 Approche méthodologique
5.1 Etude comparative de quelques méthodologies
Description Points Forts Points Faibles
RUP - Une méthodologie de Propose des modèles de Couteux à

conduite et de documents et des canevas personnaliser et très
développement de pour des projets types. axé processus.
projets.
- Un outil prêt à l’emploi.
XP - Représente un ensemble - Itératif. Ne couvre pas les

de pratiques de - Simple à mettre en phases en amont et en
développement. œuvre. aval au
- Cible des projets de moins développement.
de 5 personnes
2TUP S’articule autour de Fait une large place à la Ne propose pas

l’architecture. technologie et à la gestion du documents types.
risque.
Scrum - 5 à 9 personnes - Itérative et incrément - Développement

- Autogérée - Développement d’un imprécis, influence
- Les décisions sont prises backlog de produit de développement
collectivement - Travail en équipe et rapide sur les
- Contient toutes les responsabilité membres de l’équipe
compétences nécessaires collective. de développement.
pour terminer le sprint - Plus de souplesse et de
- Ne change pas pendant créativité.
un Sprint - Augmentation
de productivité.
Tableau 1 - Etude comparatif de quelque méthodologie
9
5.2 Choix de la méthodologie Scrum
Le terme Scrum signifie mêlée au rugby. Il exploite les valeurs et l’esprit du rugby et les
adapte aux projets de développement. Comme le pack lors d’un ballon porté rugby, l’équipe
chargée du développement travaille de façon collective, soudée vers un objectif précis.
Comme un demi mêlé, le Scrum Master aiguillonne les membres de l’équipe, les repositionne
dans la bonne direction et donne le temps pour assurer la réussite du projet.
Scrum se base sur la théorie du contrôle empirique de processus. L’empirisme mentionne que
les connaissances proviennent de l’expérience et d’une prise de décision basée sur des faits
connus. Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité et
contrôler le risque.
Trois piliers soutiennent l’implémentations d’un contrôle empirique de processus : la

Transparence, l’inspection et l’adaptation.
• La transparence : requiert la définition d’un standard commun de pour ces aspects
afin que les observateurs partagent une compréhension commune de ce qui observé.
• L’inspection : les résultats de Scrum doivent fréquemment inspecter les
artéfacts Scrum.
- L’état d’avancement par rapport à un objectif de Sprint (Sprint Global) afin de détecter les
écarts indésirables. La fréquence de ces inspections ne devrait pas gêner le travail en cours. Ces
inspections son bénéfiques lorsqu'elles sont effectuées de manière diligente sur les lieux du
travail par les personnes qualifiées.
• L’adaptation : si un inspecteur détermine qu’un ou plusieurs aspects du processus

dérivent hors des limites acceptables, et que le produit qui en résulte sera
inacceptable, le processus ou e matériel utilisé par le processus doit être ajusté. Un
ajustement doit être fais dès que possible afin de minimiser le risque d’autres
dérives.
10
5.3 Processus Scrum
La figure si dessous décrit le principe de Scrum qui se résume comme suit :

- Propriétaire de produit (Le Product Owner) crée une liste des taches prioritaires appelés
Product Backlog.
- Pendant le Sprint Planning, l’équipe prend une partie des taches du Product Backlog
pour préparer le Sprint Backlog et discuter la manière d’implémentation de ces taches.
- L’équipe a une certaine période de deux à quatre semaines (Sprint) pour achever le
travail, mais elle se réunit chaque jour pour évaluer le progrès (DailyScrum).
— Tout au long de la p ́période, le Scrum Master essaie de maintenir l’équipe concentrée sur
son objectif.
— A la fin de chaque sprint, le travail devrait être potentiellement livrable.
— Au départ du Sprint suivant, l’équipe prend une autre partie des taches de Product Backlog
et répété les étapes précédentes.
— Au-delà du Sprint, le cycle se répété jusqu’à ce que la liste des tâches du Product Backlog
soit achevée ou le budget du projet soit épuisé ou une date limite soit atteinte. L’un de ces
Milestone marque la fin du travail sur le projet. Peu importe la cause de Clôture, Scrum assure
que le travail le plus important a été achevé de la fin du projet.
Figure 6 - Processus Scrum
11
5.4 Le langage UML
UML est un standard de modélisation graphique. Nous avons choisi ce langage pour la
modélisation de notre conception du fait qu’il est idéal pour le contexte orienté objet. Il permet
de présenter un logiciel sous forme graphique compréhensible et simple.
6 Conclusion
Dans ce premier chapitre, nous avons étudié le système et le marché pour dégager les
limites des solution existantes et proposer une solution plus adéquate. Par la suite, nous avons
présenté une analyse de méthodologie de développement pour effectuer le choix de la
méthodologie qui sera adoptée durant le développement de notre système. Dans le chapitre
suivant, nous entamerons l’étude des besoins fonctionnels et non fonctionnels.
12
FSJEGJ Chapitre 2 : Analyse et spécification des besoins
Chapitre 2 | Analyse et spécification des besoins
1 Introduction
Dans ce chapitre, nous présentons les besoins des utilisateurs à travers une spécification des
besoins fonctionnels afin d’aboutir à une application performante et satisfaisante.
Ensuite, nous identifions les acteurs de notre application. Enfin, nous détaillons le travail par la
méthodologie choisie dans le chapitre précédent.
Ce chapitre va traiter l’environnement matériel et logiciel lié à la phase d’implémentation de

notre application. Nous commençons par une présentation de l’architecture matérielle. Ensuite,
nous présentons les différents outils logiciels qui seront utilisés tout au long de la réalisation.
2 Identification des acteurs

Un acteur définit un rôle qu’une entité extérieure assume lors de son interaction avec le
système. En se basant sur cette définition, nous avons dégagé la liste des acteurs de notre
système
Acteurs Rôles
Administrateur C’est la personne responsable de contrôler la totalité

du système
Client C’est toute personne inscrit dans le site et peut
bénéficier par les services offerts par le site.
Tableau 2 - Identification des besoins
13
2.3 Analyse des besoins
Nous allons identifier dans cette partie les acteurs et leurs rôles. Par la suite, nous répondrons
aux questions suivantes << que doit faire le système ?>> et << quelles sont les contraintes ?>>
afin d’expliquer les différents besoins fonctionnels et non fonctionnels que notre application à
satisfaire.
2.3.1 Besoins fonctionnels
Les besoins fonctionnels expriment les attentes des utilisateurs envers le futur système.
Notre site assurera à l’administrateur les fonctionnalités suivantes :
L’administrateur a le droit de Controller n’importe quelle action dans l’application aussi que :
• S’authentifier : il peut accéder à son interface personnelle tout simplement en saisir son
login et son mot de passe.
• Gérer utilisateur : l’administrateur a la possibilité d’ajouter, modifier, supprimer, bloquer
un utilisateur
• Configurer les statistiques.
Notre site assurera aux clients les fonctionnalités suivantes :
• Se connecter au site.
• Consulter les différentes catégories des services.
• Consulter les services.
• Rechercher un service.
• Consulter les news.
• Contacter l’assistance technique.
• Gérer réclamation
• Créé un compte (S’inscrire).
• Accéder à l’espace membre (S’authentifier).
• Gérer son profil.
• Se déconnecter
• Gérer son profil.
• Se déconnecter
14
2.3.2 Besoins non fonctionnels
Futur système doit répondre aux critères suivants :
• Rapidité : le site doit optimiser les traitements pour un temps d’exécution raisonnable.
• Sécurité : les clients doivent s’authentifier pour accéder à certaines fonctionnalités du site.
• Ergonomie : à fin que l’utilisateur de l’application puisse être aisé, celle-ci devra :
• Présenter des interfaces ergonomiques.
• Permettre à l’utilisateur un accès simple.
• Assurer l’homogénéité et la cohérence entre les interfaces.
15
2.4 Diagramme de cas d’utilisation globale
Le diagramme de cas d’utilisation est une représentation graphique du comportement fonctionnel

du système.
Dans cette partie, nous présentons les fonctionnalités du système dans un diagramme de cas
d’utilisation globale permettant de modéliser les besoins de client de manière formelle et de
donner une vision du comportement fonctionnel de notre système.
Figure 7 - Diagramme de cas d'utilisation globale
16
2.5 Le Backlog du produit
SCRUM utilise une approche fonctionnelle pour récolter les besoins des utilisateurs.
L’objectif est d’établir une liste de fonctionnalités à réaliser que l’on appelle backlog de produit.
Le backlog de produit est la liste des fonctionnalités attendus d’un produit. Plus exactement,
au-delà de cet aspect fonctionnel, il contient tous les éléments qui vont nécessiter du travail.
Les éléments sont classés par priorité ce qui permet de définir l’ordre de la réalisation.
Le tableau ci-dessous résume le Backlog produit de notre application.
ID Cas d’utilisation User Story Priorité

1 S’inscrire En tant qu’client je veux inscrire 1
2 Authentification En tant que client je veux être s’authentifier 1
3 Gérer service En tant qu’administrateur je veux gérer les 1

services
4 Consulter service En tant que client je veux consulter les services 1
5 Consulter projet En tant que client je veux consulter le projet 3
6 Gérer client En tant qu’administrateur je veux gérer les 3

clients
7 Consulter statistiques En tant qu’administrateur je veux consulter les 3
statistiques
8 Gérer projet En tant que client je veux modifier les services 2
9 Créer projet En tant que client je veux créer les projets 2
10 Gérer réclamation En tant qu’administrateur je veux gérer les 2

réclamations
11 Passer réclamation En tant que client je veux passer une 3
réclamation.
Tableau 3 - Backlog du produit
17
Scrum master : c’est qu’il n’est jamais fait mention de technique, et qu’il ne produit rien. En
revanche, on peut noter qu’il doit être au service de l’équipe et du PO mais aussi de
l’organisation
- Il est sachant, c’est-à-dire qu’il connait bien (très bien même) Scrum, le guide
scrum et qu’il est garant de la bonne application de scrum dans son équipe, et plus
largement il est garant de l’Agilité de l’équipe
- Il est coach, formateur, accompagnant, il permet à l’équipe de gagner en autonomie.
- Il est servant Leader, il doit être au service (de l’équipe, du PO, de l’organisation),
comme celui qui organiserait une grosse fête chez lui ferait pour que la soirée se
passe bien pour tout le monde
Product owner : est le responsable de son PB et son maintien. Il est également

responsable de la formation des utilisateurs afin qu’ils puissent exploiter toutes les
fonctionnalités du produit.
18
3.1 Livrables du projet
Phase Livrable Responsable
Etude des besoins Analyse et spécification des

besoins
Analyse et conception Diagrammes UML Mahjoubi Ranya
Code et tests Site web
Documentation Rapport du projet
Tableau 4 - Livrables du projet
3.2 Risques du projet
Les risques Type Impact sur projet Action correctives

Performance de mon Non bloquant Retard de livraison Changement de pc
pc par rapport à
l’environnement
Manque de Non bloquant Retard de livraison L’utilisation d’une
formation plate-forme
d’apprentissage
Tableau 5 - Risques du projet
19
4. Environnement de travail
Dans cette partie, nous présentons les outils matériels pour réaliser notre projet.
4.1 environnement matériel
Pendant les différentes phases de notre projet, nous disposons d’un ordinateur portable ayant les
caractéristiques suivantes :
- Marque : Asus
- Processeur [U+202F] : Intel® Core ™ i3-6006U @2.00GHz 1.99GHz - Mémoire
[U+202F] : 8.00 GO.
- Système d’exploitation [U+202F] : Windows 10 Pro ,64-bit.
Figure 8 - Caractéristique du PC
4.2 environnement logiciel
Dans cette partie nous présentons les différents outils logiciels utilisés pour développer notre
solution
• WampServer : est une plateforme de développement Web de type wamp

(‘Windows’,’Apache’,’MySQL’,’PHP’) qui permet de développer des sites internet
dynamiques. Au sein de l’application, on retrouve Apache http Server en tant que
serveur http, PHP pour le langage de script, MySQL pour le système de gestion des
bases de données (SGBD) ainsi que l’application Web phpMyAdmin pour la gestion
des SGBD MySQL. [1]
20
Figure 9 - Logo wampserver
• StarUML
Est un logiciel de modélisation UML (Unified Modeling Language) open source qui peut
remplacer dans bien des situations des logiciels commerciaux et couteux comme Rational Rose.
Etant simple d’utilisation, nécessitant peu de ressources système, supportant UML 2, ce logiciel
constitue une excellente option pour une familiarisation à la modélisation.
Cependant, seule une version Windows est disponible. [2]
Figure 10 - Logo StarUML
• Visual Studio Code

Visual Studio Code est un éditeur de code extensible développé par Microsoft pour Windows,
Linux et MacOs. Les fonctionnalités incluent la prise en charge du débogage, la mise en
évidence de la syntaxe, la complétion intelligente du code, les snippets, la refactorisation du
code et Git intégrer. [3]
Figure 11 - Logo Visual Studio Code
21
• Lucidchart : est une plateforme de collaboration en ligne, basée sur le Cloud,

permettant la création de diagrammes et la visualisation de données, et autres schémas
conceptuels.
Un schéma conceptuel, ou carte conceptuelle est une représentation structurée d’un ensemble de
concepts reliés sémantiquement. [5]
Figure 12 - Logo Lucidchart
• Trello : est un outil d’organisation collaboratif simple et gratuit. Trello est un outil
collaboratif qui organise tous vos projets en une série de listes partagées.
D’un seul coup Trello vous renseignera sur tous vos projets, sur leur état d’avancement et
vous dira qui travaille sur quoi dans votre équipe. [6]
Figure 13 - Logo Trello
22
• Gantt Project : Gantt est un logiciel libre de gestion de projet écrit en Java, ce qui
permet de l’utilisateur sur divers systèmes d’exploitation (Windows, Linux, MacOs). Il
permet d’étudier un diagramme de Gantt qui organise le projet selon des dates fixées.
Figure 14 - Logo Gantt Project
4.3 Système de gestion de base de données
- MySQL : MySQL est un système de gestion de base de données. Il fait partie des logiciels de
de gestion de base de données les plus utilisés au monde, dans les applications Web
principalement, en concurrence avec Oracle ou Microsoft SQL Server. MySQL est un serveur
de bases de données relationnelles SQL développé dans un soucis de performances élevées en
lecture. Son architecture logicielle le rend extrêmement rapide et facile à personnaliser. Les
principaux avantages de MySQL sont sa rapidité, sa robustesse et sa facilité d’utilisation et
d’administration. Un autre avantage majeur de MySQL est sa documentation très complète et
bien construite.
4.4 Choix technologiques
- Symfony : Symfony est un ensemble de composants PHP ainsi qu'un Framework MVC
libre écrit en PHP. Il fournit des fonctionnalités modulables et adaptables qui permettent de
faciliter et d’accélérer le développement d'un site web.
- Twig : twig est un langage de Template qui se compile en code PHP optimisé. Il est
principalement utilisé pour générer du HTML, mais peut également être utilisé pour générer
tout autre format basé sur du texte.
23
4.5 Organigramme des taches
Figure 15 - Organigramme des taches
4.6 Planifications de projet :
Pour bien organiser le déroulement de différentes étapes de notre projet on a réalisé une
planification
Nous avons découpé notre projet en plusieurs tache afin d’assurer son déroulement. Au début
nous avons commencé avec notre sprint 0, puis on a découpé notre projet en 3 sprints dure
chacune () jours pour que nous puisons à la fin avoir un projet complet à livrer.
4.7 Diagramme de Gantt :
Le diagramme de Gantt est un outil utilisé en ordonnancement et en gestion de projet et

permettant de visualiser dans le temps les diverses taches composant un projet, il s’agit d’une
représentation d’un graphe connexe, permet de représenter graphiquement l’avancement du
projet
24
Le diagramme permet :
-De déterminer les dates de réalisation d’un projet
-D’identifier les marges existantes sur certaines taches
-Visualiser d’un coup d’œil le retard ou l’avancement des travaux
Figure 16 - Diagramme de Gantt
4.8 Architecture de l’application
Dans cette partie, nous présentons l’architecture de notre application << le style de
l’architecture en tiers spécifie l’organisation des composants d’exploitation mise en œuvre pour
réaliser le système >>
4.8.1 Architecture 3-tiers
Dans notre application, nous avons utilisé une architecture 3-tiers qui vise à décomposer le système
en trois couches différentes :
25
- Couche présentation : c’est la partie de l’application visible par les utilisateurs.

- Couche métier : constitue l’ensemble des règles de la logique applicative, elle vérifie donc
l’intégrité et la validité des données.
- Couche d’accès aux données : représente les données à conserver et à stocker et qui
souvent à l’implémentation du logique métier...
Le navigateur envoie l’adresse que le client a tapée. Le serveur web cherche si le fichier existe,
et si celui-ci porte une extension reconnue comme une application PHP. Si c’est le cas, le
serveur transmet ce fichier.
PHP analyse et exécute le code. Si ce code contient des requêtes SQL. La base de données
revoie les informations voulues au script qui peut les exploiter (pour les afficher par exemple).
PHP continue de parser la page, puis retourne le fichier dépourvu du code PHP au serveur web
qui génère une page HTML et le renvoie au navigateur qui l’interprète et l’affiche. [7]
Figure 17 - Architecture 3-tiers
4.8.2 Architecture logicielle : MVC
Nous avons applique le modèle Model-View-Control (MVC) pour le développement de

l’application :
- M : modèle de données
- V : pour la présentation, l’interface utilisateur

- C : pour la logique de contrôle, gestion des évènements et la synchronisation
26
L’architecture MVC offre un cadre pour structurer une application, il impose la séparation entre les
données, la présentation et les
Traitements ce qui donne trois parties de l’application finales : modèle, vue et contrôleur
Le Modèle : c’est le comportement de l’application : traitement de données, interaction avec base

de données. Il décrit les données manipulées par l’application.
Le Vue : correspond à l’interface avec lequel l’utilisateur interagit. Sa première tâche est de
présenter les résultats reçus du modèle, puis il reçoit toutes les actions de l’utilisateurs.
Le Contrôleur : reçoit tous les événements de l’utilisateur [8]
Figure 18 - Schéma du modèle MVC
27
5. Conclusion
Dans ce chapitre, nous avons identifié les besoins fonctionnels et non fonctionnels de notre
système ainsi que les acteurs principaux et leurs rôles. Ensuite, nous avons détaillé la première
étape de la méthodologie que nous avons choisie, à savoir, l’identification de l’équipe de travail
et la réalisation de backlog du produit et des sprints. Dans le chapitre suivant, nous entamons
l’étude du sprint 1.
28
FSJEGJ Chapitre 3 : Mise en œuvre de sprint 1
Chapitre 3 |Mise en œuvre de sprint 1
1 Introduction
Ce chapitre fait l’objet d’une présentation du premier sprint du projet qui est la distribution et
le contrôle des droits d’accès. L’étude de se sprint couvre l’analyse, la conception, la réalisation
et les tests fonctionnels.
2 Backlog de sprint
Un sprint est une courte période de durée fixe durant laquelle vont s’enchaîner un certain nombre
d’activités et se terminant par la livraison d’un incrément de produit qui fonctionne
Dans cette partie nous allons présenter le Backlog du sprint qui correspond à une liste des
fonctionnalité attendus d’un sprint. Le tableau ci-dessus résume le Backlog du sprint relatif à
notre livrable.
ID Fonctionnalité Tache Date début Date fin Responsable
1 S’inscrire 01/03/2022 08/03/2022
2 S’authentifier 09/03/2022 16/03/2022
Ranya
3 Gérer utilisateur Ajouter utilisateur 17/03/2022 24/03/2022 Mahjoubi
Modifier utilisateur
Supprimer utilisateur
Bloquer utilisateur
Tableau 6 - Backlog du sprint 1
31
3 Tableau des taches
Le tableau des taches et un affichage visuel de la progression de l’équipe Scrum au cours d’un sprint
Il est composé de 3 colonnes :
• A faire : liste des taches à traiter

• En cours de traitement : liste des taches en cours de développement
• Terminée : liste des taches terminées
Figure 19 - Tableau des taches
4.1 Identification des acteurs
Les acteurs qui interagissent dans le sprint 1 sont :
- Utilisateur : c’est l’acteur principale de notre application, qui permet de s’inscrire et s’authentifier
- Administrateur : c’est l’acteur du back office de contrôler et configurer l’accès du les utilisateurs.
32
4.1.1 Raffinement des cas d’utilisation de sprint 1 :
Figure 20 - Diagramme de cas d'utilisation de sprint 1
33
Raffinement de cas d’utilisation inscription
- Diagramme de cas d’utilisation <<inscription>> pour l’acteur utilisateur :
Pour accéder aux fonctions, l’utilisateur doit s’inscrire en remplissant un formulaire donné
Figure 21 - Diagramme de cas d'utilisation <<s'inscrire>>
Les scénarios d’exécution du cas d’utilisation << s’inscrire>> sont décrits par le tableau suivant
représentant la fiche descriptive de cas
Nom Description
Acteur Utilisateur
Objectif Le site doit permettre aux utilisateurs de s’inscrire
Pré-condition Utilisateur non inscrit
Post-condition Compte utilisateur crée
Scénario Nominal 1. L’utilisateur accède au site
2. Le système affiche l’interface d’inscription
3. L’utilisateur remplit le formulaire
4. Le système affiche un
message de confirmation
Scénario Alternatif Champs vide
3.1 le système affiche un message d’erreur
3.2 le scénario recommence du point 1 du scénario
nominal
Tableau 7 - Description textuelle du cas d'utilisation <<S'inscrire>>
34
Raffinement de cas d’utilisation << S’authentifier >> :
Figure 22 - Diagramme de cas d'utilisation <<Authentification>>
Nom Authentification
Acteur Administrateur, utilisateur
Objectif Autorisation d’accès
Pré-condition Utilisateur inscrit
Post-condition Accès au système
Scénario Nominal 1. Le système demande de saisir login et mot de
passe
2. L’utilisateur saisit non-login et mot de passe
3. Le système vérifie les paramètres
4. Le système affiche l’interface choisit
Scénario Alternatif Champs vides, paramètre non valide 3.1 le
système affiche un message d’erreur
3.2 le scénario recommence du point 1 du scénario
nominal
Tableau 8 - Description textuelle de cas d'utilisation <<s'authentifier>>
35
Raffinement de cas d’utilisation << Gérer utilisateur >> pour l’acteur <<
Administrateur >>
Figure 23 - Diagramme de cas d'utilisation <<Gérer utilisateur>>
Les scénarios d’exécution du cas d’utilisation <<bloquer utilisateur>> sont décrits par les tableaux
suivants représentant les fiches descriptives du cas :
Description textuelle de cas d’utilisation <<bloquer utilisateur>> pour les acteurs
<<administrateur>>
36
Nom Bloquer utilisateur

Acteur Administrateur
Objectif L’administrateur contrôle et gère les utilisateur
Pré-condition - L’administrateur doit être authentifié
- L’administrateur doit accéder à l’interface
bloqué l’utilisateur.
Post-condition Le compte de l’utilisateur et bloqué
Scénario Nominal 1. L’administrateur consulte la liste des
utilisateurs
2. L’administrateur demande le blockage d’un
client
3. Le système demande la confirmation
4. L’administrateur confirme son choix
5. Le système envoie une requête de
modification au SGBD
6. Système envoie un message de confirmation
à l’administrateur
Scénario Alternatif 1 l’administrateur annule la mise à jour :
. Le cas d’utilisation se termine avec échec.
Tableau 9 - Description textuelle du cas d'utilisation <<Bloquer utilisateur>>
37
Les scénarios d’exécution du cas d’utilisation <<débloquer utilisateur>> sont décrits par les tableaux
suivants représentant les fiches descriptives du cas :
Description textuelle de cas d’utilisation <<débloquer utilisateur>> pour les acteurs
<<administrateur>>
Nom Débloquer utilisateur
Objectif L’administrateur contrôle et gère les utilisateurs
Pré-condition - L’administrateur doit s’authentifié
Post-condition Le compte de l’utilisateur est débloqué
Scénario Nominal 1. L’administrateur consulte la liste des

utilisateurs
2. L’administrateur demande le déblocage
d’un client
3. Le système demande la confirmation
4. L’administrateur confirme son choix

5. Le système envoie une requête de
modification au SGBD
6. Système envoie un message de
confirmation à l’administrateur
Scénario Alternatif 1 l’administrateur annule la mise à jour :

. Le cas d’utilisation se termine avec échec.
Tableau 10 - Description textuelle du cas d'utilisation <<Débloquer utilisateur>>
38
4 Conception
4.1 Conception statique

4.1.1 Diagramme de classe de sprint 1
Une classe est un ensemble de fonctionsde données (attributs) qui sont liée ensemble par un champ
sémantique. Les classes sont utilisées dans la programmation orientée objet.
Une classe est représentée par un rectangle séparé en trois parties :

- Première partie contient le nom de la classe
- La seconde contient les attributs de la classe
- La dernière contient les méthodes de la classe
Figure 24 - Diagramme de classe de sprint 1
39
4.1.2 Dictionnaire des données du sprint 1
Le dictionnaire des données est un document qui décrit la base de données ou une collection des bases
de données.
Les tableaux présentés ci-dessous illustrent le dictionnaire de données associé à notre base de données.
Utilisateur
Attribut Type Taille Obligatoire Clé
Id BIGINT 20 Oui Clé primaire
Nomprénom CHAR 50 Oui
Email Varchar 255 Oui
Téléphone Int 8 Oui
Password VARCHAR 255 Oui
Tableau 11 - Dictionnaire de données <<utilisateur>>
Administrateur
Tableau 12 - Dictionnaire de données <<administrateur>>
40
5 Conception dynamique
5.1 Diagramme de séquence du sprint 1
Pour notre site, nous allons élaborer les diagrammes de séquence pour déterminer la
dynamique du système. Ce diagramme met en valeur les échanges de messages entre acteurs et
objets de manière chronologique.
Le principe de ce diagramme est de détailler de séquence système, il permet de découper le système en
trois objets :
- Interface
- Contrôle
- Entité
Figure 25 - Principe de diagramme de séquence
41
Message asynchrone : il n’attend pas de réponse et ne bloque pas l’émetteur qui ne sait pas si le
message arrivera à destination.
Figure 26 - Exemple message asynchrone
Message synchrone : l’émetteur reste alors bloqué le temps que dure l’invocation de l’opération
42
- Diagramme de séquence <<inscription>> : Ce scénario commence lorsque l’utilisateur

demande d’afficher le formulaire d’inscription. Dès que le formulaire sera affiché, l’utilisateur
remplit les champs demandés. Par a suite le système vérifie les champs (type, forme) ainsi que la
vérification des champs obligatoires qui doivent être non vide. Si tout est correcte, le système
envoie les données entrées à la base de données pour être enregistrer et enfin l’affichage de
message d’inscription avec succès. La figure ci-dessous illustre de diagramme de séquence
associé à ce scénario
Figure 27 - Diagramme de séquence <<S'inscrire>>
43
- Diagramme de séquence <<S’authentifier>> : ce diagramme décrit les scénarios possibles lors

de l’authentification par son email et son mot de passe via le serveur d’application qui prend en
charge de vérifier et consulter la base de données. S’il accepté, il y’aura l’accès au système et à
l’application du menu correspondant. Sinon le serveur d’application lui affiche un message
d’erreur.
Figure 28 - Diagramme de séquence <<S'authentifier>>
44
- Diagramme de séquence <<bloquer utilisateur>> :

Ce diagramme décrit les scénarii possibles lors d’une opération de blocage d’un profil, une fois
l’administrateur choisit le blocage, le système lui affiche une fenêtre de confirmation de blocage s’il
confirme, le profil sera bloqué. Dans la figure suivante nous présentons le diagramme de séquence
bloqué profil.
Figure 29 - Diagramme de séquence <<Bloquer utilisateur>>
45
Ce diagramme décrit les scénarios possibles lors d’une opération de déblocage d’un
profil. Une fois l’administrateur choisit le déblocage, le système lui affiche une fenêtre
de confirmation de déblocage, s’il confirme, le profil sera débloqué. Dans la figure
suivante, nous présentons le diagramme de séquence débloqué profil.
Figure 30 - Diagramme de séquence <<Débloquer utilisateur>>
46
5.2 Diagramme d’activité
Le diagramme d’activité est un diagramme comportemental d’UML, permettant de représenter

le déclenchement d’évènements en fonction des états du système et de modéliser des
comportements parallélisables (multithreads ou multiprocessus). Le diagramme d’activité est
également utilisé pour décrire un flux de travail (workflow).
A- Diagramme d’activité <<inscription>>
La figure ci-dessous présente le diagramme d’activité <<inscription>>
Figure 31 - Diagramme d'activité <<S'inscrire>>
47
B – Diagramme d’activité << Authentification>>
La figure ci-dessous présente le diagramme d’activité d’authentification
Figure 32 - Diagramme d'activité <<Authentification>>
48
C – Diagramme d’activité <<bloquer utilisateur>>
La figure ci-dessous présente le diagramme d’activité <<bloquer utilisateur>>
Figure 33 - Diagramme d'activité <<Bloquer utilisateur>>
49
6 Réalisation du sprint
6.1 Les interfaces
Dans cette partie, nous allons présenter quelques interfaces de site afin de montrer le résultat de
ce sprint.
6.2 Interface inscription
La figure ci-dessous présente les erreurs syntaxiques
Figure 34 - interface signup
50
6.3 Interface d’authentification
Cette interface permet à l’utilisateur de taper son login et mot de passe correctement pour pouvoir
accéder à son espace privée sinon elle affiche un message d’erreur
Figure 35 - Interface Authentification
51
Interface espace privée :
Figure 36 – Interface user
52
7 Test et validation
Le test d’un produit logiciel est processus consistant qui vise à garantir le bon fonctionnement du
système à travers une comparaison des comportements attendu et des résultats obtenus.
Le tableau ci-dessous présente le fiche test fonctionnel de l’interface inscription
Id : Type fonctionnel
inscription
Testeur : Ranya Mahjoubi
Object attendu : l’utilisateur doit insère un login et un mot de passe pour créer un compte
Description : Après le développement de l’interface d’inscription on va introduire les informations

nécessaires dans le formulaire et on va faire des tests. (Test sur la syntaxe de chaque champ)
Règle métier
Règle 1 : l’utilisateur accède à l’interface inscription
Règle 2 : l’utilisateur doit remplir le formulaire d’inscription

Règle 3 : l’utilisateur doit respecter les contrôles de saisis
Tests d’acceptation sur l’entité :
Nom de scénario 1 : contrôle syntaxique des champs lorsque l’utilisateur remplie le formulaire il doit
respecter les champs suivants :
- Nom : l’utilisateur doit écrire 255 caractères composer par des lettres [a..z] ou [A..Z]
- Prénom : l’utilisateur doit écrire 255 caractères composer par des lettres [a..z] ou [A..Z]
- Email : l’utilisateur doit écrire 255 caractères composer par des lettres [a..z] ou [A..Z] et : ou
[0..9], ce champs doivent contenir aussi le << @ >>
- Téléphone : l’utilisateur doit écrire 11 caractères composer par des numéros [0..9]
- Login : l’utilisateur écrit 255 caractères composer par des lettres [a..z] ou [A..Z] et : ou [0..9]
- Password : l’utilisateur doit écrire 255 caractères composer par des lettres [a..z] ou [A..Z] et : ou
[0..9] Nom de scénario :
- L’utilisateur doit compléter le processus d’inscription

- L’utilisateur doit remplir tous les champs
- L’utilisateur doit cliquer sur le bouton << s’inscrire >>
Tableau 13 - Fiche test fonctionnel de l'interface <<Inscrire>>
53
Le tableau ci-dessous présente le fiche test fonctionnel de l’interface blocage
Id : blocage Type fonctionnel
Object attendu : l’administrateur doit bloquer utilisateur désiré
Description : Après le développement de l’interface de blocage on va vérifier toutes les

interactions de système après la consultation de la liste des utilisateurs, choisir un utilisateur le
système demande la confirmation de blocage, l’administrateur valider le blocage.
Règle métier
Règle 1 : l’administrateur accède à l’interface bloquer utilisateur
Règle 2 : l’administrateur consulte la liste de utilisateurs
Règle 3 : l’administrateur choisie un utilisateur
Règle 4 : l’administrateur confirme le blocage
Tests d’acceptation sur l’entité : utilisateur
Nom de scénario : l’administrateur confirme le blocage
- L’administrateur consulte la liste des utilisateurs

- Choisir un utilisateur
- L’administrateur demande le blocage
- L’administrateur confirmer le blocage
- Dans la table utilisateur : l’état d’utilisateur doit être modifié : blocage=bloquer
Tableau 14 - Fiche test fonctionnel de l'interface <<Blocage>>
54
Le tableau ci-dessous présente le fiche test fonctionnel de l’interface déblocage
Id : déblocage Type fonctionnel
Object attendu : l’administrateur doit débloquer utilisateur désiré
Description : Après le développement de l’interface de déblocage on va vérifier toutes les

interactions de système après la consultation de la liste des utilisateurs, choisir un utilisateur le
système demande la confirmation de déblocage, l’administrateur valider le déblocage.
Règle métier
Règle 1 : l’administrateur accède à l’interface débloquer utilisateur
Règle 2 : l’administrateur consulte la liste de utilisateurs
Règle 3 : l’administrateur choisie un utilisateur
Règle 4 : l’administrateur confirme le déblocage
Tests d’acceptation sur l’entité : utilisateur
Nom de scénario : l’administrateur confirme le déblocage
- L’administrateur consulte la liste des utilisateurs

- Choisir un utilisateur
- L’administrateur demande le déblocage
- L’administrateur confirmer le déblocage

- Dans la table utilisateur : l’état d’utilisateur doit être modifié : déblocage=débloquer
Tableau 15 - Fiche test fonctionnel de l'interface <<Déblocage>>
55
8 Conclusion
Au cours de ce chapitre, nous avons présenté le premier sprint. Pour ce faire, nous avons passé par la
présentation du Backlog Product, la spécification des besoins, la conception et la réalisation. Dans le
chapitre suivant nous entamons le deuxième sprint.
56
Chapitre 4 | Mise en œuvre du sprint 2
1 Introduction
Durant ce chapitre, nous entamons le deuxième sprint. Pour cela, nous commençons par le
Backlog du sprint, nous passons ensuite aux parties analyse et conception, pour terminer enfin
par les parties réalisation et revue de sprint
2 Backlog du sprint 2
Dans cette partie nous allons présenter le Backlog du sprint qui correspond à une liste des
fonctionnalités attendus d’un sprint. Le tableau ci-dessus résume le backlog du sprint relatif à
notre livrable.
Id Fonctionnalité Tache Date début Date fin Responsable
1 Créer projet 25/03/2022 01/04/2022
2 Gérer projet 04/04/2022 11/04/2022 Mahjoubi Ranya

-Accepter projet
-Refuser projet
3 Consulter projet 12/04/2022 19/04/2022
59
3 Tableau des taches
Le tableau de taches est un affichage visuel de la progression de l’équipe Scrum au cours d’un
sprint.
Il est divisé en trois colonnes : les taches à réaliser, les tâches en cours et les tâches réalisé.
La figure ci-dessous présente le tableau des taches du sprint 2
Figure 37 - Tableau des taches
60
4 Phase Analyse
Dans cette partie, nous présentons les diagrammes de cas d’utilisation et la description textuelle
de certain d’entre eux.
4.1 Indentification des acteurs
Les principaux acteurs de ce sprint sont

Utilisateur : l’acteur déclencheur de ce sprint, il crée un projet après authentification
Administrateur : c’est l’acteur responsable de la gestion et de filtrage des projets après

authentification
4.1.1 Raffinement des cas d’utilisation de sprint 2 :
La figure ci-dessous présente le diagramme de cas d’utilisation de sprint 2 :
Figure 38 - Diagramme de cas d'utilisation de sprint 2
61
Raffinement de cas d’utilisation << créer projet >>
Figure 39 - Diagramme de cas d'utilisation
Description textuelle de cas d’utilisation <<Créer projet>> pour l’acteur <<client>>
Les scénarios d’exécution du cas d’utilisation <<créer projet>> sont décrits par le tableau
suivant représentant la fiche descriptive du cas :
Nom Créer projet
Acteur Utilisateur
Objectif La création d’un projet
Pré-condition Ce cas d’utilisation commence lorsque

l’utilisateur demande au système de faire la
création des projets :
1. L’utilisateur demande de la
création d’un projet
2. Le système affiche un formulaire
de création de projet
3. L’utilisateur remplit le formulaire
Le système vérifie les données
syntaxiquement
Post-condition Projet crée avec succès
Scénario Nominal L’utilisateur annule la création de projet :

. Le cas d’utilisation se termine avec échec
Tableau 17 -Description textuelle de cas d'utilisation <<créer projet>>
62
Raffinement de cas d’utilisation << Gérer projet>>
Figure 40 - Diagramme de cas d'utilisation <<Gérer projet >>
63
Les scénarios d’exécution du cas d’utilisation <<accepter projet>> sont décrits par les tableaux
suivants représentants les fiches descriptives du cas :
Description textuelle de cas d’utilisation <<accepter projet>> pour l’acteur

<<l’administrateur>>
Nom Accepter projet
Objectif L’administrateur contrôle et gère les

projets
Pré-condition Projet accepté
Post-condition Projet créer avec succès
Scénario Nominal Ce cas d’utilisation commence lorsque

l’administrateur demande au système de
faire l’acceptation des projets :
1. L’administrateur consulte
la liste des projets
2. L’administrateur demande
l’acceptation d’un projet
3. Le système demande la
confirmation
4. L’administrateur confirme
son choix
5. Le système envoie une
requête de modification au
SGBD
Scénario Alternatif L’administrateur annule la mise à jour :

Tableau 18 - Description textuelle de cas d'utilisation <<Accepter projet>>
Description textuelle de cas d’utilisation <<refuser projet>> pour :
64
Tableau 21 : Description textuelle de cas d'utilisation <<Refuser projet>>
Nom Refuser projet
Objectif L’administrateur contrôle et gère les projets
Pré-condition Projet refusé
Post-condition Projet créer avec succès

l’administrateur demande au système de faire
le refuse des projets :
1. L’administrateur consulte
la liste des projets
2. L’administrateur demande
le refuse d’un projet
3. Le système demande la
confirmation
4. L’administrateur confirme
son choix
5. Le système envoie une
requête de modification au
SGBD
Scénario Alternatif L’administrateur annule la mise à jour :

Tableau 19 - Description textuelle de cas d'utilisation <<Refuser projet>>
65
Raffinement de cas d’utilisation <<consulter projet>> pour l’acteur

<<utilisateur>>
Figure 41 - Diagramme de cas d'utilisation <<Consulter projet>>
Nom Consulter projet
Acteur Utilisateur
Objectif Consultation des projets
Pré-condition -L’utilisateur doit être authentifié
Post-condition Liste des projets affichés

l’utilisateur demande au système de faire la
consultation des projets :
1. L’utilisateur demande de
consulter la liste des projets
2. L’utilisateur envoi une requête
de sélection à l’entité projet
3. Le système affiche la liste des
projets
Scénario Alternatif L’utilisateur annule la consultation :
. le système affiche un message d’erreur
Tableau 20 - Description textuelle de cas d'utilisation <<Consulter projet>>
66
5 Conception
5.1 Conception statique :
5.1.1 Diagramme de classe de sprint 2
Cette figure représente le diagramme de classe utilisé pour le développement du sprint
Figure 42 - Diagramme de classe du sprint 2
67
5.1.2 Dictionnaire des données du sprint 2
Les tableaux présentés ci-dessous illustrent le dictionnaire de données associé à notre base de
données.
Utilisateur
Administrateur
68
Projet
Nom CHAR 50 Oui
Description Varchar 255 Oui
Tableau 23 - Dictionnaire des données <<projet>>
Service
Titre CHAR 50 Oui
Date Date Oui

création
Tableau 24 - Dictionnaire de données <<service>>
69
5.2 Conception dynamique
5.2.1 Diagramme de séquence
- diagramme de séquence << créer projet>> : Ce scénario décrit l’opération de création d’un
projet. Si le client demande la création d’un projet, le système affiche un formulaire à remplir
le client saisie les données et le système prend en charge la vérification des champs saisie le
système envoyer un message de succées de l’opération ou échec de l’opération
Figure 43 - Diagramme de séquence <<créer projet>>
70
Diagramme de séquence <<consulter projet>> : ce scénario décrit l’opération de

consultation d’un projet
Figure 44 - Diagramme de séquence <<Consulter projet>>
71
-Diagramme de séquence <<accepter projet>>
Ce diagramme décrit les scénarios possibles lors d’une opération d’acceptation d’un projet
Figure 45 - Diagramme de séquence <<Accepter projet>>
72
-Diagramme de séquence <<refuser projet>>
Ce diagramme décrit les scénarios possibles lors d’une opération le refuse d’un projet
Figure 46 - Diagramme de séquence <<Refuser projet>>
73
5.2.2 Le diagramme d’activité
Diagramme d’activité <<créer projet >>
La figure ci-dessous présente le diagramme d’activité de la création d’un projet
Figure 47 - Diagramme d'activité <<Créer projet>>
Diagramme d’activité <<accepter projet>>
74
La figure ci-dessous présente le diagramme d’activité de l’acceptation d’un projet
Figure 48 - Diagramme d'activité <<Accepter projet>>
75
6 Réalisation de sprint
6.1 Les interfaces
Dans cette partie, nous allons présenter quelques interfaces de site afin de montrer le
résultat de ce sprint
La figure ci-dessous présente l’acceptation ou le refus d’un projet
Figure 49 - Interface gérer projet
76
6.2 Interface <<consulter projet>>
La figure ci-dessous présente la consultation d’une liste des projets pour l’acteur utilisateur
Figure 50 - Interface consulter projet
77
7 - Test et validation
Le tableau ci-dessous présente le fiche test fonctionnel de l’interface acceptation
Id accepté Type fonctionnel
Object attendu : l’administrateur doit accepter le projet désiré
Description : après le développement de l’interface d’acceptation on va vérifier toutes les

interactions de système après la consultation de la liste des projets, choisir un projet le système
demande la confirmation d’acceptation. L’administrateur valider l’acceptation
Règles métier :
Règle 1 : l’administrateur accède à l’interface accepter projet
Règle 2 : l’administrateur consulte la liste des projets
Règle 3 : l’administrateur choisie un projet
Règle 4 : l’administrateur confirme l’acceptation
Tests d’acceptation sur l’entité : projet
Nom de scénario : l’administrateur confirme l’acceptation
- L’administrateur consulte la liste des projets

- Choisir un projet
- L’administrateur demande l’acceptation
- L’administrateur confirme l’acceptation
Tableau 25 - Test fonctionnel de l'interface <<Acceptation>>
78
8 Conclusion
Au cours de ce chapitre, nous avons présenté le deuxième sprint. Pour ce faire, nous avons
passé par la spécification, la conception et la réalisation. Dans le chapitre suivant nous entamons
le troisième sprint.
79
Chapitre 5 | Mise en œuvre de sprint 3
1 Introduction :
En partant sur le même principe que les deux sprints précédents. Pour cela, nous commençons
par le backlog du sprint, ensuite nous passons à l’analyse et la conception. Nous terminons par
la réalisation et le test.
2 Backlog du sprint 3 :
Id Fonctionnalité Tache Date début Date fin Responsable
1 Gérer service -Modifier service 20/04/2022 27/04/2022

-supprimer
service
Mahjoubi Ranya
-Ajouter service
2 Passer 28/04/2022 05/05/2022

réclamation
3 Consulter 06/05/2022 13/05/2022

statistique
85
3 Tableau des taches :
Le tableau de taches est un affichage visuel de la progression de l’équipe Scrum au cours d’un
sprint.
Il est divisé en trois colonnes : les taches à réaliser, les tâches en cours et les tâches réalisé. La
figure ci-dessous présente le tableau des taches du sprint 3
Figure 51 - Tableau des taches du sprint 3
4 Phase d’analyse :
Dans cette partie, nous présentons les diagrammes de cas d’utilisation et la description
textuelle de certain d’entre eux.
4.1 Identification des acteurs
Les principaux acteurs de ce sprint sont :
Utilisateur : l’acteur déclencheur de ce sprint, il passe une réclamation après

authentification
Administrateur : c’est l’acteur responsable de la modification, suppression et l’ajout des

services aussi la consultation des statistiques après authentification
86
4.1.2 Raffinement de cas d’utilisation du sprint 3
La figure ci-dessous présente le diagramme de cas d’utilisation de sprint 3 :
Raffinement de cas d’utilisation Gérer service :
Figure 52 - Diagramme de cas d'utilisation <<Gérer service>>
87
Nom Gérer service
Objectif Le site doit permettre à l’administrateur

d’ajouter, modifier et supprimer des
produits
Pré-condition Administrateur authentifié
Post-condition Service ajouté, modifié et supprimé
Scénario Nominal Ajouter service
1. Le système affiche l’interface

d’ajout
2. L’administrateur saisit les données
et valide
3. Le système enregistre le nouveau
service
Modifier service
1. L’administrateur demande de
modifier un service
2. Le système redirige vers la page des
mise-a-jour
3. L’administrateur choisir le service a
modifié
4. Le système enregistre les
modifications
Supprimer service
1. L’administrateur supprime un
service
2. Le système supprime le service de la
base de données
Scénario Alternatif Ajouter produit : produit existant :
2.1 Le système affiche un message
d’erreur
2.2 Le scénario recommence du point 1
du scénario nominal
Tableau 27 - Description textuelle de cas d'utilisation <<Gérer service>>
88
Raffinement de cas d’utilisation Passer réclamation :
Figure 53 - Diagramme de cas d'utilisation <<Passer réclamation>>
Description textuelle de cas d’utilisation << passer réclamation >> pour l’acteur
<<utilisateur>>
Nom Passer réclamation
Acteur Utilisateur
Objectif Le site doit permettre à l’utilisateur

d’envoyer des réclamation
Pré-condition Utilisateur authentifié
Post-condition Réclamation envoyé
Scénario Nominal 1. Le client demande de passer une

réclamation
2. Le système affiche le formulaire
3. Le client saisit son message et
valide
4. Le système affiche un message de
confirmation d’envoi
Tableau 28 - Description textuelle de cas d'utilisation <<Passer réclamation>>
89
Raffinement de cas d’utilisation <<consulter statistique>>
Figure 54 - Diagramme de cas d'utilisation <<Consulter statistique>>
Description textuelle de cas d’utilisation <<consulter statistique>> pour l’acteur

<<administrateur>>
Nom Consulter statistique
Objectif Consulter les statistiques
Pré-condition Administrateur authentifié
Post-condition Les statistiques sont consultées
Scénario Nominal 1. L’administrateur demande au

système de consulter les statiques
2. Le système affiche l’interface de
consultation
3. Le système affiche les statistiques
Scénario alternatif Le système affiche message erreur
Tableau 29 - Description textuelle de cas d'utilisation <<Consulter statistique>>
90
5 Conception
5.1 Conception statique
5.1.1 Diagramme de classe globale :
Le figure ci-dessous présente le diagramme de classe globale :
Figure 55 - Diagramme de classe globale
91
5.1.2 Dictionnaire de données de sprint 3
Les tableaux présentés ci-dessous illustrent le dictionnaire de données associé à notre base de
données.
Utilisateur
Administrateur
92
Projet
Nom CHAR 50 Oui
Tableau 32 - Dictionnaire des données <<projet>>
Service
Titre CHAR 50 Oui
Date Date Oui

création
Tableau 33 - Dictionnaire de données <<service>
Réclamation
Titre CHAR 50 Oui
Contenu Varchar 255 Oui
Date Date Oui
Tableau 34 - Dictionnaire des données <<réclamation>>
93
6 Conception dynamique
6.1 Diagramme de séquence
Figure 56 - diagramme de séquence <<ajouter service>>
94
Figure 57 - diagramme de cas d’utilisation <<passer réclamation>>
95
Figure 58 - diagramme de séquence <<consulter statistique>>
96
6.2 Diagramme d’activité
Diagramme d’activité <<Modifier service >>
La figure ci-dessous présente le diagramme d’activité de la modification d’un service :
Figure 59 - Diagramme d'activité <<Modifier service>>
97
Diagramme d’activité <<Passer réclamation>>

La figure ci-dessous présente le diagramme d’activité de passer une réclamation :
Figure 60 - Diagramme d'activité <<Passer réclamation>>
98
7 Réalisation du sprint
7.2 les interfaces :
Dans cette partie, nous allons présenter quelques interfaces de site afin de montrer le résultat de
ce sprint
7.2.1 Interface Gérer service :
La figure ci-dessous présente l’interface de gérer service
Figure 61 - Interface gérer service
99
7.2.2 Interface consulter statistiques
Figure 62 - Interface consulter statistiques
100
8 Test et validation
Id réclamation Type fonctionnel
Object attendu : l’utilisateur passer une réclamation
Description : après le développement de l’interface de réclamation l’utilisateur va passer une réclamation
Règles métier :
Règle 1 : l’utilisateur accède à l’interface réclamation
Règle 2 : l’utilisateur consulte l’interface de réclamation
Règle 3 : l’utilisateur passer une réclamation
Tableau 35 – Test fonctionnel de l’interface <<réclamation>>
101
9 Conclusion
Au cours de ce chapitre, nous avons présenté le troisième sprint. Pour ce faire, nous avons passé
par la spécification, la conception et la réalisation.
102
Conclusion générale
Ce projet nous a permis d’approfondir nos connaissances théoriques dans la conception et le

développement des sites web.
Ce dernier était bénéfique pour nous dans plusieurs sens. Il nous a permis de
- Nous perfectionner en améliorant nos connaissances en programmation et en conception
- De bien comprendre et mettre en œuvre le déroulement d’un cycle de vie d’un logiciel
Nous avons essayé de réaliser ce projet pour le but de faciliter la demande de création des projets
(Solution IT) et pour connaitre plus d’information à propos notre Startup Data2ai. On a appliqué
au maximum possible les règles de bases permettant d’avoir une application performante. Nous
avons appliqué UML pour concevoir une grande partie de notre travail.
Grâce aux architectures que nous avons utilisées (architecture 3-tiers) notre application peut
avoir des extensions ou des modifications dans le futur.
Notons enfin, nous espérons que ce projet satisfera mon encadrant et les membres de jury, et
servira comme outils pour faciliter les taches aux clients
103
Bibliographie
[1] WampServer https://fr.wikipedia.org/wiki/WampServer

[2] StarUml https://fr.wikipedia.org/wiki/StarUML
[3] Visual Studio code https://fr.wikipedia.org/wiki/Visual_Studio_Code
[4] LucidChart https://fr.wikipedia.org/wiki/Lucidchart
[5] Trello https://fr.wikipedia.org/wiki/Trello
[6] Gantt Project https://fr.wikipedia.org/wiki/GanttProject
[7] Architecture 3-tier
https://cedric.cnam.fr/~farinone/SMB111/annee1011/architectureNTiers.pdf
[8] MVC https://fr.wikipedia.org/wiki/Mod%C3%A8le-vue-contr%C3%B4leur
104
105
106
107

Version Finale

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Version Finale

Transféré par

Droits d'auteur :

Formats disponibles

Rubrique Tunisienne

Ministère de l’Enseignement Supérieure et de la Recherche Scientifique Université

Faculté des Sciences Juridique Economique et de Gestion de Jendouba

Rapport de Projet de Fin d’Etudes

Présenté en vue de l’obtention du

Diplôme de License Fondamentale en Informatique de Gestion

Conception et développement d’un site web responsive pour

Encadrant académique : Mr.

Année universitaire : 2021/2022

J’offre ce modeste travail :

A mes chers enseignants sans exception.

La réalisation de ce projet a été possible grâce aux soutiens de plusieurs

J’adresse mes vifs remerciements à toute personne contribuant de près ou de

Nous tenions à remercie vivement la faculté de sciences juridiques économiques

Mes remerciements le plus sincères à Mr. Sellami Mokhtar, mon encadrant à la

Enfin, mes remerciements à tous mes professeurs. Ensuite, je remercie les

Introduction Générale ............................................................................................................................. 1

Figure 1 - Maquette de la page d'accueil ................................................................................................. 4

Tableau 1 - Etude comparatif de quelque méthodologie......................................................................... 9

De nos jours, l’informatique peut se trouver partout et fait partie du quotidien de

Chapitre 1| Cadre de projet

DATA2AI est une startup du conseil en nouvelles technologies et en nouveaux systèmes IT

Expertises : Data2ai accompagne les entreprises sur l’implémentation d’infrastructures

3 Cahier des charges technique

Liste des pages :

Figure 1 - Maquette de la page d'accueil

Figure 2 - Maquette de la page service

Figure 3 - Maquette de la page contact

Figure 4 - Maquette de la page register

Figure 5 - Maquette de la page login

Comme solution nous proposons de développer un site web responsive"Data2AI",

5.1 Etude comparative de quelques méthodologies

Description Points Forts Points Faibles

RUP - Une méthodologie de Propose des modèles de Couteux à

XP - Représente un ensemble - Itératif. Ne couvre pas les

2TUP S’articule autour de Fait une large place à la Ne propose pas

Scrum - 5 à 9 personnes - Itérative et incrément - Développement

Tableau 1 - Etude comparatif de quelque méthodologie

5.2 Choix de la méthodologie Scrum

Trois piliers soutiennent l’implémentations d’un contrôle empirique de processus : la

• L’adaptation : si un inspecteur détermine qu’un ou plusieurs aspects du processus

5.3 Processus Scrum

La figure si dessous décrit le principe de Scrum qui se résume comme suit :

Figure 6 - Processus Scrum

5.4 Le langage UML

Chapitre 2 | Analyse et spécification des besoins

Ce chapitre va traiter l’environnement matériel et logiciel lié à la phase d’implémentation de

2 Identification des acteurs

Administrateur C’est la personne responsable de contrôler la totalité

Tableau 2 - Identification des besoins

2.3 Analyse des besoins

2.3.1 Besoins fonctionnels

Notre site assurera à l’administrateur les fonctionnalités suivantes :

2.3.2 Besoins non fonctionnels

Futur système doit répondre aux critères suivants :

• Présenter des interfaces ergonomiques.

• Permettre à l’utilisateur un accès simple.

• Assurer l’homogénéité et la cohérence entre les interfaces.

2.4 Diagramme de cas d’utilisation globale

Le diagramme de cas d’utilisation est une représentation graphique du comportement fonctionnel

Figure 7 - Diagramme de cas d'utilisation globale

2.5 Le Backlog du produit

ID Cas d’utilisation User Story Priorité

3 Gérer service En tant qu’administrateur je veux gérer les 1