Vous êtes sur la page 1sur 22

CHAPITRE

2 Analyse et spécification des besoins

Introduction
Ce chapitre sera organisé en trois volets importants.
Tout d’abord, nous détaillons dans un premier temps les exigences fonctionnelles de
l’application, à savoir les fonctionnalités requises par l’utilisateur. Nous ajoutons ensuite des
exigences non fonctionnelles.
Par la suite, nous détaillons les différentes étapes de la démarche que nous allons adopter afin
d’aboutir au modèle des cas d’utilisation.
Finalement, nous allons décrire de façon détaillée les cas d’utilisation par : des fiche-type
pour chacun et des représentations graphiques UML très utile : le diagramme de séquence.

L’application coté utilisateur


L’objectif est de collecter, analyser et définir les besoins de haut niveau et les caractéristiques
du futur site Web. On se focalise sur les fonctionnalités requises par les utilisateurs, et sur la
raison d’être de ces exigences. Nous rajoutons les besoins non fonctionnelles nécessaires au bon
fonctionnement du système.
Le détail de la description de ces besoins se trouve dans la partie Spécification détaillée des
cas d’utilisation

Exigence fonctionnelles

La solution devra regrouper toutes les fonctionnalités nécessaires de recherche, de découverte


détaillée, de sélection et de réservation d’évènement.
Recherche : La première étape pour l’utilisateur consiste à trouver le plus rapidement possible
un évènement ou un produit recherché dans l’ensemble du catalogue. Les références de cet
évènement (ou produit) pouvant être plus ou moins précises, il faut lui fournir plusieurs méthodes
de recherche différentes.
L’utilisateur pourra ainsi sélectionner un critère (destination, organisateur, type, etc.). Les
résultats de la recherche seront disponibles sur une page particulière, et devront pouvoir être
facilement parcourus et reclassés.
Découverte : Chaque évènement publié sur le site sera présenté en détail sur sa propre page.
On y trouvera en particulier :
* une image (pour la majorité des évènements),

* son prix et sa disponibilité,


De plus, on trouvera les fiches détailles de chaque participants inscris dans un tel évènement.
Réservation et paiement : Le participant peut accéder au formulaire de réservation, dans
lequel il saisit ses coordonnées et les informations nécessaires au paiement.
Pour garantir la sécurisation et la confidentialité des échanges, il est impératif que l’envoi des
données se fasse de manière cryptée.

Exigence non fonctionnelles

Exigences de qualité

Pour attirer un utilisateur sur notre site et ensuite le fidéliser, il est important de répondre aux
exigences de qualité suivantes :
Ergonomie sobre et efficace : Réserver un évènement sur le Web ne doit pas prendre
beaucoup de temps ou demander une maîtrise de mathématiques ! La mise en page du
site facilitera au maximum la démarche à l’aide d’une présentation claire et intuitive. Les
sites trop riches et trop complexes n’incitent pas aux réservations, car ils demandent un
effort intellectuel important et non souhaité.
— Formulaire de réservation simple : Très souvent, l’utilisateur cale au moment de
réservation, car la conception et la présentation du formulaire est assez complexe.
Donc il faut adopter des styles particulièrement soignées pour ne pas rebuter les utilisateurs
de notre site.
— Sécurité : Se doter d’un système sécurisé est une chose primordiale dans la réalisation de
notre site.
En effet, vu la pertinence des informations (numéro carte bancaire et mot de passe)
circulant, il s’avère judicieux de garantir la sécurité de notre site.

Exigences de performance

—Le système doit pouvoir gérer les comptes de plus de 10 000 clients,
—Le site web doit supporter plus de 1000 connexions simultanées,
—Le catalogue d’évènement doit pouvoir comprendre plus de 10 000 titres,
—Aucune recherche ne doit prendre plus de 5 secondes.

Spécification des exigences d’après les cas d’utilisation


L’expression préliminaire des besoins donne lieu à une modélisation par les cas d’utilisation
qui va aboutir à la construction d’un modèle des as d’utilisation qui :
—Comprend une collection des cas d’utilisation,

—Caractérise le comportement de l’ensemble du système et ses acteurs (dans leur interaction).

Ainsi, la démarche que nous allons adopter afin d’aboutir ce modèle est schématisé par la

figure
2-1
FIGURE 2.1 – Synoptique de la démarche de construction du modèle de cas d’utilisation
Identification des acteurs

Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou une chose
qui interagit avec un système. [6]
Durant notre analyse, nous avons identifié les acteurs suivants :
—Administrateur : Rôle des acteurs qui sont en charge du bon fonctionnement et de la
maintenance du site,
—Organisateur : Rôle des acteurs qui sont responsables du contenu rédactionnel du site
(évènements, annonces et publications),
—Internaute : La personne qui demande des prestations auprès du site et qui est responsables
du contenu rédactionnel aussi (publications, et annonces).
Nous allons également prendre en compte le système informatique, à savoir le système
Paiement-Sécurisé qui assure le paiement de toutes les réservations effectuées.

Identification des cas d’utilisation

Lors de notre analyse des besoins, nous avons pu identifier pour chaque acteur les cas
d’utilisation importants que nous montrerons ci-dessous et nous les modélisons par la suite grâce
au modèle des cas d’utilisation.
Débutant par l’acteur le plus important dans notre application : l’administrateur, ces cas
d’utilisation principaux ont été bien mis en évidence par l’expression de besoins préliminaire, à
savoir :
—Maintenir le portail,
—Mise à jour des comptes utilisateurs.
—Mise à jour des évènements : Recherche, consultation, suppression, publication.
—Mise à jour des articles.
—Mise à jour des annonces (vente et location de matériels).

On obtient un diagramme préliminaire (voir figure 2-2) en représentant les cas d’utilisation reliés
par des associations à leur acteur.
FIGURE 2.2 – Cas d’utilisation principaux de l’administrateur

Ensuite, l’intention métier selon lequel l’organisateur utilise le système est identifiée comme suit :
—Mise à jour des évènements : Création, modification, Recherche, consultation et suppression,
—Mise à jour des annonces: Création, modification, Recherche, consultation et suppression,
—Mise à jour de profil: Ajouter des publications, Ajouter et modifier ces cordonnés
, Ces cas d’utilisation sont illustrés par un diagramme préliminaire (voir figure 2-3)

FIGURE 2.3 – Cas d’utilisation principaux de l’organisateur


Finalement, les cas d’utilisation de l’internaute seront comme suit :
—Chercher un évènement,
—Consulter les évènements,
—Réserver un évènement, qui fait intervenir le système « PaimentSécurisé »
—Évaluer et commenter un évènement.
—Mise à jour des annonces: Création, modification, Recherche, consultation et suppression,
—Mise à jour de profil: Ajouter des publications, Ajouter et modifier ces cordonnés
Ces cas d’utilisation sont illustrés par un diagramme préliminaire (voir figure 2-4)

FIGURE 2.4 – Cas d’utilisation principaux de l’internaute

Structuration en packages

Dans le but de l’organisation générale et la décomposition du système en des parties plus


facilement observables, nous allons regrouper les cas d’utilisation en des ensembles fonctionnels
cohérents.
Pour achever ce travail, nous utilisons le concept général d’UML, le package.
Les acteurs ont été regroupés dans trois packages séparés. L’organisation générale du modèle
des cas d’utilisation sera schématisée par la figure suivante (voir figure 2-5).
FIGURE 2.5 – Organisation des cas d’utilisation et des acteurs en packages

Affinement du modèle de cas d’utilisation


.
À tout moment, le visiteur peut choisir de créer un compte, afin de devenir participant.
Le participant a la possibilité de mettre à jour son profil :
- Les informations le concernant (nom, prénom, adresse électronique, etc.) stockées par le
site web.
-Les publications
Aussi l’authentification de l’internaute lui donne la possibilité de publier et consulter les
annonces de vente et location et la possibilité de faire une recherche d’un évènement qui
peut donner lieu à sa consultation et sa réservation.
Enfin, l’authentification du participant est nécessaire pour la recherche, la consultation et la
réservation d’un évènement, l’ajout et la consultation des annonces, ainsi pour la gestion de
son propre profil.
Nous mentionnons également l’importance du système externe de Paiement sécurisé,
nécessaire au moment de la réservation en ligne.
Le diagramme devient alors celui de la figure 2.6.

FIGURE 2.6 – Relations entre cas d’utilisation des internautes


—Relations entre cas d’utilisation des organisateurs
Les différentes possibilités de Mise à jour des évènements seront modélisées plus finement
par une relation de généralisation telle que l’ajout, la suppression et la modification d’un
événement (CRUD).

FIGURE 2.7 – Relations entre cas d’utilisation des organisateurs

—Relations entre cas d’utilisation du l’administrateur


Pour ce diagramme, nous pouvons relier les cas d’utilisation de l’administrateur par des
relations d’inclusion : la mise à jour d’un évènement nécessite absolument une recherche
de celui-ci.
FIGURE 2.8 – Relations entre cas d’utilisation du l’administrateur

Spécification détaillée des exigences


Nous allons maintenant décrire de façon détaillée les cas d’utilisation que nous trouvons
importants grâce à une fiche-type pour chaque cas d’utilisation. Nous compléterons cette
description textuelle par une représentation graphique UML très utile : le diagramme de séquence
« système ».
Description textuelle des cas d’utilisation

—S’authentifier

TABLE 2.1 – Description textuelle de S’authentifier

Nom S’authentifier
Acteur Principal Administrateur, Organisateur et internaute
Objectif Accéder au fonctionnalités du site.
Pré-conditions L’acteur existe dans la base de données
1.L’acteur demande le formulaire de connexion
2.Le système affiche le formulaire d’identification
Scénario 3.L’acteur remplit le formulaire avec l’ensemble des
nominal informa- tions nécessaires à son identification
4.Le système vérifie les informations saisies et le redirige
vers son espace approprié.

Scénario 1.L’acteur saisit des informations incohérentes.


alternatif 2.Le système renvoie un message d’erreur.

—Créer un évènement

TABLE 2.2 – Description textuelle de Créer un évènement

Nom Créer un évènement


Acteur Principal Organisateur
Objectif Créer un nouveau évènement
Pré-conditions Organisateur authentifié
1.l’organisateur demande le formulaire d’ajout d’un
nouveau évènement
2.le système affiche le formulaire demandé
Scénario
nominal 3.l’organisateur saisit les informations relatives à chaque
évè- nement
4.le système vérifie les données et affiche le résultat de la
tache.

Scénario 1.L’organisateur saisit des informations. incohérentes


alternatif 2.Le système renvoie un message d’erreur.
—Chercher un évènement

TABLE 2.3 – Description textuelle de Chercher un évènement

Nom Chercher un évènement


Acteur Principal Participant
Objectif Recherche d’un événement
Pré-conditions Liste des évènements disponible
1.l’acteur affiche l’onglet de recherche et selectionne un
critère.
Scénario
2.le système renvoie une fiche détaillée de l’évènement
nominal choi- sie.
3.l’acteur consulte la page affiché

Scénario Néant
alternatif

—Réserver un évènement

TABLE 2.4 – Description textuelle de Réserver un évènement

Nom Réserver un évènement


Acteur Principal Participant
Objectif Participer à un évènement
Pré-conditions participant authentifié
1.le participant cherche un évènement
2.le système affiche l’évènement sélectionné.
Scénario 3.le participant demande la participation
nominal 4.le système renvoie la page du panier.
5.le parcicipant choisie le nombre de places à réserver

Scénario 1. le nombre de places disponibles est égale à 0


alternatif

Diagrammes de séquence système

Dans cette section, nous décrivons le comportement du système par des Diagrammes de
séquence système (DSS) où ce dernier est vu comme une boîte noire.
Le système est donc vu de l’extérieur par les acteurs sans préjuger de comment il sera réalisé.
La boîte noire décrite seulement en phase de conception.
Le fonctionnement d’un cas d’utilisation est notamment décrit sous la forme d’une séquence
de messages échangés entre les acteurs et le système Dans ce qui suit, nous présentons les DSS
des cas d’utilisation importants en tenant compte des règles suivantes :
—La notation avec la flèche pleine représente des messages synchrones, c’est-à-dire des appels
où l’émetteur se bloque en attente de la réponse. Dans le cas contraire, on parle de message
asynchrone, et on le représente par une flèche évidée.
—la flèche pointillée partant du système à l’étude représente un retour au sens UML. Cela
signifie que le message en question est le résultat direct du message précédent par une
relation forte de cause à effet. En général, on ne fait figurer que les retours intéressants et
non triviaux.
—la notation des bandes blanches le long des lignes verticales (appelées lignes de vie)
représente l’activation de l’élément en question. Le système informatique n’est actif que
lorsqu’il est sollicité par un acteur, alors que les acteurs sont a priori toujours actifs. Cette
notation est optionnelle, mais aide à mieux comprendre la flèche pointillée du message de
retour. Toutefois, dans un souci de simplicité, nous ne l’utiliserons pas pour les autres DSS.
—La flèche qui reboucle sur le système (enregistrement Commande) permet de représenter
graphiquement un comportement interne majeur sur lequel on veut mettre l’accent. Il ne
faut cependant pas en abuser car ce n’est pas l’objectif premier de ce type de diagramme dit
d’interaction.

— S’authentifier : Rappelons que pour passer à une authentification, le membre doit demander
la page de connexion. Ce dernier saisie ses paramètres d’identification et par la suite il sera
dirigé vers son espace approprié.
La pré-condition du cas d’utilisation peut également être matérialisée graphiquement grâce
au symbole d’état sur la ligne de vie.
Il est même possible de représenter également le cas d’erreur où le système ne trouve pas
des membres correspondant à la requête. Il suffit d’ajouter un cadre alt, (pour indiquer que
les messages de succès ou d’erreur). Le diagramme devient alors comme sur la figure 2.9.
FIGURE 2.9 – DSS de s’authentifier

—Créer un évènement

FIGURE 2.10 – DSS de Créer un évènement


—Chercher un évènement

FIGURE 2.11 – DSS de chercher un évènement

—Réserver un évènement

FIGURE 2.12 – DSS de réserver un évènement


Classement des cas d’utilisation

Après tout ce travail d’identification des cas d’utilisation, nous pouvons maintenant les
classifier en tenant compte des deux facteurs suivants :
La priorité fonctionnelle,
Le risque technique, estimé par le chef de projet.
Le tableau suivant illustre cette démarche.
TABLE 2.5 – Classement des cas d’utilisation

Cas d’utilisation Priorit Risq Itération


é ue #
S’authentifier Haute Haut 1
Créer un compte Haute Haut 5
Créer un évènement Haut moye 2
n
Gérer son compte Moyen Moy 7
ne en
Consulter un Moyen Moy 6
évènement ne en
Chercher un Haute Haut 3
évènement
Évaluer et commenter Bas Bas 8
Réserver un Haute Haut 4
événement

Au niveau des risques techniques, le chef de projet a classé au plus haut la création des
évènements, à cause des problèmes liés à leur disponibilité régulière dans la base de données. De
même, le processus d’authentification est noté avec un risque haut à cause des problèmes de
confidentialité de données.

Conclusion
Comment recueillir tous les besoins des acteurs du système d’information, et rien que leurs
besoins réels ? Comment se mettre d’accord sur la spécification des exigences ? Comment
aboutir à un modèle de cas d’utilisation ?, toutes ses questions ont été annoncé dans ce chapitre.
La question qui se pose maintenant Comment le système fonctionne t-il ?, objet du troisième
chapitre Conception détaillé

Vous aimerez peut-être aussi