CHAPITRE II

ANALYSE ET SPECIFICATION DES BESOIN

Sacko Mohamed Génie logiciel système d’information 1

Introduction
Ce chapitre se concentre sur une phase clé de la méthode Scrum : la planification du projet, la
définition des fonctionnalités et leur regroupement en incréments. Nous abordons ici l'une des
pratiques les plus discutées de Scrum, le "Sprint zéro", qui est essentiel pour poser des bases
solides à un nouveau projet et permettre à une nouvelle équipe de se former et d'apprendre à
travailler ensemble. En effet, le Sprint zéro représente une période d'exploration, de justification
et d'organisation. Dans ce chapitre, nous détaillerons les besoins et les fonctionnalités,
identifierons les différents acteurs, établirons le "Product Backlog" du produit initial et
planifierons les autres sprints.

1 Spécification des besoins :

1.1 Identification des acteurs :

Définition de l’acteur.
Dans notre système nous avons principalement 3 acteurs qui sont:

-Secrétaire : Est une personne qui utilise le système pour gérer les rendez-vous, les
informations administratives des patients, etc.

- Médecin principal: Utilisateur qui supervise l'activité médicale et administrative des

autres médecins et de la secrétaire.

-Patient : C’est un utilisateur final du système, qui peut consulter ses informations
médicales, prendre des rendez-vous, etc.

1.2 Spécifications des besoins fonctionnels :

Les spécifications fonctionnelles définissent les interactions entre le système et les différents
acteurs mentionnés précédemment. Pour détailler ces spécifications, nous utiliserons le
diagramme de cas d'utilisation global.
Cas d’utilisation globale :

Un diagramme de cas d'utilisation est un type de diagramme UML (Unified Modeling

Language) utilisé pour représenter les interactions entre les acteurs externes et un système
logiciel. Il met en évidence les différentes fonctionnalités du système du point de vue des
utilisateurs (les acteurs) et montre comment ces utilisateurs interagissent avec le système pour
accomplir certaines tâches ou atteindre des objectifs spécifiques.

Sacko Mohamed Génie logiciel système d’information 2

1.3 Spécifications des besoins non fonctionnels :

Les spécifications des besoins non fonctionnels décrivent les exigences qui ne sont pas
directement liées aux fonctionnalités spécifiques du système. Ces spécifications définissent les
contraintes et les propriétés que le système doit respecter pour être considéré comme satisfaisant
du point de vue des utilisateurs et des parties prenantes.
Notre système doit répondre aux contraintes suivantes :
Sécurité : L’application doit être sécurisée, les informations ne doivent pas être accessibles
à tout le monde, l’accès à l’application est possible à partir d’un login et un mot de passe.
Disponibilité : La plateforme doit être disponible à tout moment et pour tous les utilisateurs.
Convivialité : L’application doit être simple et facile à manipuler.

Performance : L’application doit être performante c’est-à-dire que le système doit réagir
dans un délai précis, quel que soit l’action d’utilisateur.
L’extensibilité : Dans le cadre de ce travail, l’application devra être extensible, c’est-à dire
que le gestionnaire de l’application pourra avoir la possibilité d’ajouter ou de modifier
de nouvelles fonctionnalités.

Sacko Mohamed Génie logiciel système d’information 3

 Maintenance : le code source de l’application doit être clair pour faciliter sa maintenance.

2.3 Planning du traitement des cas d’utilisation :

2.3.1 Exigence et Importance :

L’exigence peut être définie comme le besoin qu’un système doit remplir. Par ailleurs, la
description de notre application peut clarifier les exigences sus-énumérées. Lors de
l’énumération de l’ensemble des fonctionnalités, nous avons observé que certains besoins sont
plus prioritaires que d’autres. Généralement, les fonctionnalités qui vont être validées au
premier serviront à la réalisation de celles qui leurs succèderont. De ce fait, et pour une
démarche bien structurée et non frustrante, il faut bien décomposer les exigences par priorité ou
importance, par exemple : Importance Faible, Importance Moyenne et Importance Élevée.

2.3.2 Les risque :

Le risque est un événement possible qui peut affecter la démarche choisie, et ceci par la
création des redondances entre des parties qui sont; au préalable; indépendantes. Dans ce cas,
il vaut mieux regrouper ces parties pour ne pas menacer la passation d’un Sprint à un autre.

2.4 Pilotage de projet avec SCRUM :

2.4.1 Équipe et rôles :

L’équipe SCRUM comprend différents membres remplissant des rôles :

• Scrum Master : Il est le leader du projet, ses principales responsabilités sont de maintenir un
environnement de travail positif et développer une solide culture de travail.

• Product Owner : Il est l'utilisateur principal et le propriétaire du projet.

• Scrum Team : C'est l'équipe responsable du développement de ce projet.

Le Tableau ci-dessus représente notre équipe SCRUM :

Prénom et Nom Rôle

Mr Abbes Madjid Product Owner

Mme Hadded Leila SCRUM Master

Sacko Mohamed Scrum Team

Table 2.1 – Les rôles SCRUM de notre équipe

Sacko Mohamed Génie logiciel système d’information 4

 2.4.2 Le backlog du produit :

Le Backlog est défini comme un tableau qui comprend toutes les fonctionnalités attendues du
projet pour un utilisateur. Plus précisément, c’est le travail demandé à faire par l’équipe
Scrum. Durant l’actuel sprint (Sprint 0), nous allons apprendre à connaître les besoins de
chaque utilisateur de notre plateforme. Durant la réalisation du projet, il est très important
d’alimenter le backlog au fur et à mesure pour ne pas oublier des fonctionnalités permettant
de répondre parfaitement aux besoins de l’utilisateur

Id User Story Id tâche Tâche Priorité

exigence
1 S’inscrire
2 S’authentifier
3 Gestion des rendez vous
4 Gérer ses rendez vous
5 Gestion et Suivi des
Dossiers Médicaux
En tant patient, je veux pouvoir m’inscrire à
1.1 travers un formulaire d’inscription sur la
plateforme
En tant que secrétaire, je dois pouvoir
1.2 m’inscrire à travers un formulaire
d’inscription
En tant que Médecin principal, je dois
m’authentifier par mon identifiant, mon de
2.1 numéro téléphone ou mon adresse email et un
mot de passe avant de faire des tâches
administratives du system.
En tant secrétaire, je dois m’authentifier
par mon identifiant, mon de numéro
2.2 téléphone ou mon adresse email et un mot
de passe avant de faire des tâches
administratives du system.
En tant que Patient, je dois m’authentifier
par mon identifiant, mon de numéro
2.3
téléphone ou mon adresse email et un mot
de passe.
En tant que Médecin, je dois pouvoir gérer
3.1
les rendez-vous des clients
En tant que secrétaire, je dois pouvoir
3.2
gérer les rendez-vous des clients.
En tant que patient, je dois pouvoir gérer
4.1
mes propres rendez-vous.
En tant que Médecin, je dois pour
5.1 gérer les dossiers médicaux.

En tant que Patient je dois pouvoir

6 Faire une Réclamation 6.1
faire une réclamation

Sacko Mohamed Génie logiciel système d’information 5


7 Gestion des Stocks
8 Gestion de la comptabilité
Gestion des fiches des
patients
Contacter un médecin
En tant que secrétaire, je dois pouvoir
7.1
gérer le stock
En tant que médecin principal, je dois
pouvoir gérer le stock
En tant que Secrétaire, je dois pouvoir
8.1
gérer la comptabilité
En tant que médecin principal, je dois
8.2
pouvoir gérer la comptabilité
9.1 En tant que Médecin, je dois pouvoir gérer
les fichiers des patients
En tant que Secrétaire
z je dois pouvoir gérer les
fichiers des patients1
1
1
1
10.1 En tant que patient je peux contacter le
médecin par email, téléphone direct ou part
message

11 Gestion des utilisateurs 11.1 En tant que médecin principal, je dois

pouvoir gérer les utilisateurs.

Table 2.2 – Backlog de notre projet

2.4.3 Structure et découpage du projet :

Dans ce qui suit, nous présentons le découpage de notre projet en des incréments, nommés
« Sprint ». Un Sprint dure en général de trois à quatre semaines. Fonctionnellement, il est
caractérisé par une publication sur la production de différentes tâches effectuées. Dans la figure
N◦4.3, nous allons détailler les différentes Sprints qui vont aboutir au développement de notre
projet.

Sacko Mohamed Génie logiciel système d’information 6

Sprint 1 Sprint 2 Sprint 3

• S’inscrire • Gestion et suivi des dossiers médicaux • Gestion des stocks

• S’authentifier • Faire une réclamation •Gestion de la comptabilité

• Gestion des rendez-vous • Gestion des utilisateurs

• Gérer ses rendez vous

• Gestion des fiches des patients

• Contacter le médecin

Figure 2.3 – Sprints

Conclusion :

Durant ce chapitre, nous avons établi la planification de notre projet. En effet, nous avons
défini les spécifications des besoins en suivant les recommandations de la méthodologie
SCRUM. Ainsi, nous avons identifié les différents rôles de l’équipe de notre projet. Après, nous
avons proposé le Product Backlog qui contient la liste des fonctionnalités attendues du produit
en vue. Ensuite, nous avons proposé le découpage des Sprints. Dans le chapitre suivant, nous
allons enchaîner à présent avec notre premier sprint en détaillant les différentes fonctionnalités
qui le décrivent.

Sacko Mohamed Génie logiciel système d’information 7