Vous êtes sur la page 1sur 5

Chapitre II : Analyse et spécification

I. Introduction :
Nous entamons dans cette partie l’étude de notre application « notification de payement
par SMS », et nous commençons par la phase de collecte des besoins.
Les cas d’utilisation constituent un outil clé pour bien dégager les besoins et les acteurs
impliqués dans le système.
Et c’est pour cela qu’on adopte le langage de modélisation UML pour la description des
besoins des utilisateurs.
On distingue deux types de besoins :
 Fonctionnels
 Non fonctionnels.
On appelle besoins l’énoncé de ce que le système devrait faire. L’expression des
besoins présente ce que le système est censé réaliser sans soucier de document celui-là va le
faire.

II. Analyse des besoins :


1. Besoins fonctionnels :
Ils décrivent l’action que doit effectuer un système en réponse à une demande.

L’application :

 Permet à l’utilisateur d’envoyer un ou plusieurs SMS à différents contacts.


 Doit assurer la gestion des contacts et l’historique des SMS envoyer.
 Doit assurer la fiabilité de toutes les mises à jour de la base de données de
l’application.

2. Besoins non fonctionnels :


Ils concernent les besoins en performances, les besoins de sécurité, besoin en esthétique,
etc.…
Vu les services qu’il offre notre application doit répondre aux besoins suivants :
 Ergonomie : une bonne ergonomie qui vise a facilité la saisie et l’obtention de
l’information, avec un minimum d’effort pour l’internaute et sans risque d’erreur.
 Disponibilité : la solution proposée doit garantir une disponibilité maximale des
services offerts.
 Sécurité : le niveau de sécurité doit permettre d’éviter d’altérer les pages, aussi
doit protéger le transfert des données.
 Rapidité : le temps de réponse doit ère assez rapide, les interrogations de la base
des doivent être optimisé au maximum ainsi la technologie d’accès adoptée tiendra
en compte la question du temps.

III. Méthode conceptuelle :


La modélisation consiste à créer une représentation simplifiée d'un problème: le modèle.

.1. Grâce au modèle il est possible de représenter simplement un problème, un concept et


le simuler.

La modélisation comporte deux composantes :

 L'analyse, c'est-à-dire l'étude du problème.


 La conception, soit la mise au point d'une solution au problème.

Le modèle constitue ainsi une représentation possible du système pour un point de vue
donné.

Pour la réalisation de notre conception nous avons utilisé comme logiciels de


conception : Visual Paradigm.

1. Définitions des acteurs :


Pour notre système nous avons identifié un seul acteur primaire :

 L’administrateur : il envoi des SMS, gère la gestion des contacts ainsi que la
consultation et suppression de l’historique.

2. De Diagramme de cas d’utilisation :

a. Diagramme « Diagramme de cas d'utilisation général» :


Les cas d'utilisation (en anglais use cases) permettent de représenter le fonctionnement du
système vis-à-vis de l'utilisateur, c'est donc une vue du système dans son environnement
extérieur.
Figure 1.1 : Diagramme de cas d'utilisation général

b. Cas d'utilisation « Gérer contacts» :

Figure 1.2 : Diagramme de cas d'utilisation « Gérer Contacts »

Description textuelle :
- Cas d’utulisation : Gérer contacts.
- Acteurs primaires : Administrateur
- Description : L’administrateur peut effectuer la saisie et l’enregistrement de nouveaux
contacts, la mise à jour des données et leur suppression.
- Analyse : La réalisation de ce cas d’utilisation se fait comme suit : L’administrateur
doit choisir entre ajouter Modifier ou bien la suppression des données sur un contact.
- Si c’est le premier choix (ajouter) :
 Remplir le formulaire.
- Si c’est le deuxième choix (modifier) :
 Vérifier ensuite si le contact existe ou non,
 Remplir le formulaire avec les nouveaux paramètres.
- Si c’est le troisième choix (supprimer) :
 Vérifier si le contact existe ou non.
 Supprimer les données sur le contact.

c. Cas d’utilisation « Gérer historique » :

Figure 1.3 : Diagramme de cas d'utilisation « Gérer Contacts »

Description textuelle :
- Cas d’utulisation : Gérer Historiques.
- Acteurs primaires : Administrateur.
- Description : L’administrateur peut effectuer une consultation de l’historique des
mesages envoyeés ainsi que la suppression de tout ou une date precise de l’historqiue.
- Analyse : La réalisation de ce cas d’utilisation se fait comme suit : L’administrateur
doit choisir entre Consulter ou bien la suppression de l’historique.
- Si c’est le premier choix (Consulter) :
 Afficher tout l’historique des messages envoyé.
- Si c’est le deuxième choix (supprimer) :
 Vérifier si l’historique existe ou non.
 Supprimer un champ de l’historique ou supprime tout l’historique.

IV. Conclusion :
Dans cette partie, nous avons abordé la phase de spécification, dans laquelle on a
collecté les besoins fonctionnels et non fonctionnels de notre système.
On a aussi identifié les différents acteurs impliqués dans le processus de fonctionnement.
Cependant, il reste à savoir comment ces besoins sont mis en œuvre ? Et par quelle interface
les acteurs interagissent avec notre application.
La réponse de ces questions sera confiée à la partie de conception et c’est le sujet du
chapitre suivant.