CHAPITRE II : ANALYSE
III.2.1 Expression des
besoins
Pour la mise en oeuvre de notre solution SMS BANKING, il a
fallu que nous recensions les différentes fonctionnalités du
système.
III) III.2.1.1 Les
différents services qui seront proposées aux clients
III.2.1.1.1 Des services
d'information à la demande
Grâce à ces fonctionnalités les clients
peuvent à tout moment demander de recevoir des informations par SM sur
leur téléphone mobile. Pour cela le client envoie un SM contenant
un mot clé spécifique au service dont il veut avoir accès
auquel il ajoute un code personnel (code PIN) qui lui est attribué par
la banque. Ces différents services sont :
· demande de solde,
· demande historique (quatre dernières transactions
sur un compte),
· demande de chéquier,
· demande de virement.
Exemple: pour consulter son solde, il va simplement envoyer un
SM depuis son téléphone contenant :<code service
solde> <code personnel>. Comme exemple, nous pouvons avoir le SM
suivant : D12 A001
III.2.1.1.2 Des
services de notification évènementielle
Ces fonctionnalités permettent aux clients de recevoir
des informations sur leurs téléphones mobiles lorsqu'un
évènement se produit ou une condition est satisfaite. Nous aurons
entre autre :
· alerte par SM après virement d'un salaire,
· alerte par SM après un débit sur un compte,
· alerte par SM pour toutes les transactions
effectuées sur le compte,
· alerte par SM après crédit sur un compte,
· alertes/Information marketing (promotionnelles),
· alerte par SM après dépassement de seuil
minimal,
· alerte de virement spontané,
· alerte par SM après dépassement de seuil
maximal.
Exemple : après virement d'un salaire, un SM est
automatiquement envoyé au client pour l'en informer.
III.2.1.1.3 Des services de
notification périodique
Cette fonctionnalité permet aux clients de recevoir
périodiquement des informations concernant le solde de leurs comptes.
Les fréquences sont les suivantes :
· mensuelle : le client reçoit son solde tous
les 1 er du mois,
· hebdomadaire : le client reçoit son solde
chaque lundi,
· quotidienne : le client reçoit son solde tous
les jours.
III.2.1.2 Gestion des
clients
L'application SMS BANKING devra être capable de
gérer des milliers de numéro de compte, numéro de GSM,
services choisis (solde, alertes virements de salaire, alertes
dépôts, historiques...), paramétrage d'envoi de
l'information pour chaque client, seuils personnalisés,... Comme autres
fonctionnalités, nous aurons :
· importation automatique des comptes des clients
inscrits à SMS BANKING de la base de données bancaire vers la
base de données de SMS BANKING,
· activation et désactivation des comptes clients aux
différents services,
· possibilité de définir les règles de
diffusion des alertes,
· consultation en temps réel des comptes à
partir des options multicritères de recherche.
III.2.1.3 Gestion de la
facturation
SMS BANKING donnera à la banque ou la
coopérative bancaire la liberté de définir sa politique
tarifaire adéquate (facturation mensuelle ou facturation par SM
envoyé au client) et de paramétrer la facturation pour chaque
client.
III.2.1.4 GESTION DES
SM
L'application devra offrir la possibilité de :
· consulter à tout moment de tous les messages
reçus par le système,
· consulter à tout moment de tous les messages
émis par le système,
· rechercher tous les SM envoyés ou reçus par
un client,
· rechercher tous les SM reçu ou envoyé par
le système pendant une période,
· de rechercher les SM entrant et sortant par service.
III.2.1.5 Sécurité
Pour les besoins de sécurité, chaque client de
SMS BANKING doit avoir un code PIN personnel qu'il devra intégrer
à tous ses SM. De plus, en vue de renforcer la sécurité,
les SM ne sont traités que lorsque le numéro de
téléphone du client et le code pin sont justes.
III.2.1.6 Etats et
statistiques
Des états pourront être extraits de l'application et
imprimés ou enregistrés.
· possibilités de tirer des statistiques
individuelles sur les SM des clients,
· possibilités de tirer des statistiques sur les SM
pour une période donnée (SM envoyés, reçus) et les
grouper par service.
III.2.2 Analyse
III.2.2.1 Définition de quelques concepts
· Un cas d'utilisation représente l'image d'une
fonctionnalité du système. Il est déclenché par un
acteur, qui est une entité externe au système et nécessite
que ce dernier lui rende service. Il s'agit donc d'une représentation du
système tel que perçu par les différents utilisateurs.
· Un scénario de cas d'utilisation est le
déroulement d'un cas d'utilisation. Il permet d'échafauder toutes
les hypothèses relatives au cas d'utilisation. Il est
caractérisé par :
o une pré-condition : c'est la condition à
remplir avant que le scénario ne soit déclenché ;
o une post-condition : c'est la condition que doit
vérifier le système à la fin du scénario ;
o un résumé métier : qui
décrit de façon superficielle les principales étapes du
déroulement du cas d'utilisation ;
o le scénario nominal : qui représente le
déroulement du cas d'utilisation de la meilleure des façons
possibles, c'est-à-dire qu'aucun facteur ne nuit à son
déroulement ;
o le scénario alternatif : il s'agit du
déroulement d'un cas d'utilisation lorsqu'une erreur s'est produite
suite au non respect d'une contrainte.
· Un acteur représente un rôle joué
par une entité externe qui interagit directement avec le système
étudié. Cette entité externe peut être un
utilisateur humain, un dispositif matériel ou un autre système.
III.2.2.2 Principaux cas
d'utilisation autour desquels s'organise SMS BANKING
Nous allons présenter ici quelques cas d'utilisation et
les diagrammes de cas d'utilisation qui en d'écoulent.
Consultation du solde du compte : avec
son téléphone mobil, le client envoie un SM ayant un format
spécifique. Si toutes les conditions sont vérifiées, le
client reçoit en retour un SM dans lequel se trouve le solde de son
compte.
Consultation des 4 derniers historiques de compte
: ce cas d'utilisation permet au client de consulter les 4 derniers
historiques de son compte en utilisant son téléphone mobile. Un
SM avec cet historique lui est envoyé
Demande de chéquier : il s'agit ici
pour le client de faire la demande d'un nouveau chéquier en utilisant un
SM. Un premier SM lui est renvoyé pour confirmer que la demande a
été prise en compte. Un second SM lui est renvoyé lorsque
l'utilisateur confirme le traitement de cette demande.
Demande de virement vers un autre compte : ce
cas d'utilisation permet au client de faire la demande de transfert d'argent
vers un compte autre que le sien en utilisant un SM. Un premier SM lui est
renvoyé pour confirmer que la demande a été prise en
compte. Un second SM lui est renvoyé lorsque l'utilisateur confirme le
traitement de cette demande.
Alerte de débit sur un compte : ce cas
d'utilisation permet au système d'alerter le client lorsque son compte
est touché en débit. Un SM lui est envoyé avec le montant
débité.
Alerte de crédit sur un compte : ce
cas d'utilisation permet au système d'alerter le client lorsque son
compte est touché en crédit. Un SM lui est envoyé avec le
montant crédité.
Alerte de virement de salaire sur un compte :
il s'agit ici pour le système d'alerter le client lorsque son compte
est touché en débit. Un SM lui est envoyé avec le montant
viré.
Alerte périodique de solde d'un compte
: grâce à ce cas d'utilisation le système informe
le client quotidiennement, hebdomadairement ou mensuellement du solde de son
compte. Un SM lui est envoyé avec le montant du solde suivant la
périodicité qu'il a choisie.
Alerte de virement spontané sur un compte
: il s'agit ici pour le système d'alerter le client lorsqu'une
somme d'argent est virée sur son compte. Un SM lui est envoyé
avec le montant viré.
Alerte de dépassement de seuil minimal du solde
d'un compte : ce cas d'utilisation permet au système d'alerter
le client lorsque le solde de son compte est inférieure à un
montant minimal qu'il a choisit. Un SM lui est envoyé pour l'en
informer.
Alerte de dépassement de seuil maximal du solde
d'un compte : Ce cas d'utilisation permet au système d'alerter
le client lorsque le solde de son compte est supérieur à un
montant maximal qu'il a choisit. Un SM lui est envoyé pour l'en
informer.
Nous avons pour acteurs :
§ Client mobile : client muni de son
téléphone mobil
§ Utilisateur : personne qui se connecte à un
service spécifique de SMS BANKING avec des droits d'administration sur
ce service.
§ BANK SI (un acteur qui est n'est pas humain) : c est
la base de données de la banque et l'interface de synchronisation entre
elle et la base de données de SMS-BANKING
Les diagrammes des principaux cas d'utilisation sont :
Figure 10 : Diagramme de
cas d'utilisation des services d'informations à la
demande
III.2.2.3 Description
détaillée de quelques cas d'utilisation
Nous avons choisis de ne présenter ici que quelques
scénarii jugés importants. Certains cas d'utilisation sont pris
individuellement décris par les différents scenarii
jusqu'à la présentation des diagrammes de séquence et
d'activité correspondants.
Sommaire d'identification
Titre : Consultation de solde
Résumé : ce cas
d'utilisation permet au client de consulter le solde de son compte à
partir de son téléphone portable.
Acteurs : Client mobile
|
Date de création
|
13/03/2009
|
Date de mise à jour
|
10/04/2009
|
|
Version
|
1.0
|
Responsable
|
DOUANLA TOUOPI F.E
|
Pré conditions : Disposer d'un
crédit de communication permettant l'envoi de SMS, Disposer d'un
téléphone
Post conditions : Un SMS possédant le solde
est renvoyé au client
Description des scénarios
- Scénario nominal
|
1. Le client formate un SMS et l'envoi au numéro de la
carte SIM présente dans le modem connecté à la passerelle
GSM/IP de la banque ou coopérative bancaire
|
|
2. Réception, vérification du format du SMS et
stockage du SMS dans la base de données de SMS BANKING par le
système.
|
|
3. Vérification du code PIN du client par le
système.
|
|
4. Vérification du numéro de
téléphone du client par le système.
|
|
5. Vérification effective de l'inscription du client au
service de consultation de solde par le système.
|
|
6. La vérification si le nombre maximal de SMS a
envoyé au client pour le mois en cours et pour le service de
consultation de solde est atteint par le système.
|
|
7. La récupération du solde du client par le
système.
|
|
8. Formatage du message à retourner au client par le
système.
|
|
9. Insertion dans la table d'historique des SMS par le
système.
|
|
10. Insertion du SMS à envoyer au client dans la table
des SMS sortants par le système.
|
|
11. Mis à jour du statut du SMS entrée (SMS
traité) par le système.
|
|
12. Incrémentation du compteur de SMS (ce compteur
permet de compter le nombre de SMS déjà envoyé au client
durant ce mois. Il est nécessaire pour la vérification du seuil
maximal) pour le service de consultation de solde.
|
|
13. Envoi du SMS avec solde au client par le
système.
|
|
14. Mis à jour du statut du SMS sortant (SMS
envoyé) par le système.
|
- Scénario alternatif
|
E1
|
Le système détecte des erreurs sur le
formatage du SMS. Le scénario E1 démarre au point 2. du
scénario nominal.
|
|
Le système enregistre le SMS avec une remarque :
« Mauvais SMS ». Dans ce cas, le scénario nominal s
arrête au point 2.
|
|
E2
|
Le système détecte que le code PIN du
client est incorrect. Le scénario E2 démarre au point 3. du
scénario nominal.
|
|
Le système met à jour la table des SMS
entrant avec pour remarque : « client
inexistant »
Dans ce cas, le scénario nominal s arrête
au point 3
E3 Le système
détecte que le numéro de téléphone du client
est
incorrect. Le scénario E3 démarre
au point 4. du scénario nominal.
Le système met à jour la table des SMS
entrant avec pour remarque : « client
inexistant »
Dans ce cas, le scénario nominal s arrête
au point 4
|
|
E4
|
Le système détecte que le client n'est
pas inscrit à ce service. Le scénario E4 démarre au point
5 du scénario nominal.
|
Le système met à jour la table des SMS entrant
avec pour remarque : « Client non inscrit au service
spécifié »
Dans ce cas, le scénario nominal s arrête au
point 5
|
E5
|
Le système détecte que le nombre
maximal de SMS du mois courant pour le service de consultation de solde est
atteint. Le scénario E5 démarre au point 6 du scénario
nominal.
|
Le système met à jour la table des SMS entrant
avec pour remarque : « Nombre maximal de SMS
atteint »
Dans ce cas, le scénario nominal s'arrête au
point 6
|
E6
|
Le système n'arrive pas à envoyer le
SMS. Le scénario E6 démarre au point 13 du scénario
nominal.
|
Le système met à jour la table des SMS sortant
avec un statut permettant d'identifier la source d'erreur. Le SMS sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
13.
Figure 11 : Diagramme de
sequence du cas d'utilisation « demande de
solde »
Figure 12 : Diagramme de
cas d'activité du cas d'utilisation « demande de
solde »
Sommaire d'identification
Titre : Demande de chéquier
Résumé : Ce cas
d'utilisation permet au client de faire une demande à partir
chéquier à partir de son téléphone portable.
Acteurs : Client mobile, utilisateur
|
Date de création
|
13/03/2009
|
Date de mise à jour
|
10/04/2009
|
|
Version
|
1.0
|
Responsable
|
DOUANLA TOUOPI F.E
|
Pré conditions : Disposer d'un
crédit de communication permettant l'envoi de SMS, Disposer d'un
téléphone
Post conditions : deux SM sont envoyés au
client. Un pour l'informer que sa demande est bien arrivé et sera
traité puis un second pour l'en informer que sa demande de
chéquier est traité.
Description des scénarios
- Scénario nominal
|
1. Le client formate un SMS et l'envoi au numéro de la
carte SIM présente dans le modem connecté à la passerelle
GSM/IP de la banque ou coopérative bancaire
|
|
2. Réception, vérification du format du SMS et
stockage du SMS dans la base de données de SMS BANKING
|
|
3. Vérification du code PIN du client
|
|
4. Vérification du numéro de
téléphone du client
|
|
5. Vérification effective de l'inscription du client au
service de demande de chéquier
|
|
6. La vérification si le nombre maximal de SMS a
envoyé au client pour le mois en cours et pour le service de demande de
chéquier est atteint.
|
|
7. Insertion de la demande dans la table des transactions
|
|
8. Formatage du premier message à retourner au client
lui informant que sa demande sera traitée
|
|
9. Insertion dans la table d'historique des SMS
|
|
10. Insertion du SMS à envoyer au client dans la table
des SMS sortants
|
|
11. Mis à jour du statut du SMS entrée:SMS
traité
|
|
12. Incrémentation du compteur de SMS (ce compteur
permet de compter le nombre de SMS déjà envoyé au client
durant ce mois. Il est nécessaire pour la vérification du seuil
maximal) pour le service demande de chéquier. Le système extrait
le numéro de téléphone du récepteur
|
|
13. Envoi du premier SMS de confirmation de la demande
|
|
14. Mis à jour du statut du SMS sortant: SMS
envoyé
|
|
15. L'utilisateur confirme le traitement de la demande de
chéquier
|
|
16. Formatage du second message à retourner au client
lui informant que sa demande a été traitée
|
|
17. Insertion dans la table d'historique des SMS
|
|
18. Insertion du SMS à envoyer au client dans la table
des SMS sortants
|
|
19. Mis à jour du statut du SMS entrée: SMS
traité
|
|
20. Incrémentation du compteur de SMS pour le service
demande de chéquier
|
|
21. Envoi du second SMS de traitement de demande
effectué
|
|
22. Mis à jour du statut du SMS sortant: SMS
envoyé
|
- Scénario alternatif
|
E1
|
Le système détecte des erreurs sur le
formatage du SMS. Le scénario E1 démarre au point 2. du
scénario nominal.
|
|
Le système enregistre le SMS avec une remarque :
« Mauvais SMS ». Dans ce cas, le scénario nominal s
arrête au point 2.
|
|
E2
|
Le système détecte que le code PIN du
client est incorrect. Le scénario E2 démarre au point 3. du
scénario nominal.
|
|
Le système met à jour la table des SMS
entrant avec pour remarque : « client
inexistant »
Dans ce cas, le scénario nominal s arrête
au point 3
E3 Le système
détecte que le numéro de téléphone du client
est
incorrect. Le scénario E3 démarre
au point 4. du scénario nominal.
Le système met à jour la table des SMS
entrant avec pour remarque : « client
inexistant »
Dans ce cas, le scénario nominal s arrête
au point 4
|
|
E4
|
Le système détecte que le client n'est
pas inscrit à ce service. Le scénario E4 démarre au point
5 du scénario nominal.
|
Le système met à jour la table des SMS entrant
avec pour remarque : « Client non inscrit au service
spécifié »
Dans ce cas, le scénario nominal s arrête au
point 5
|
E5
|
Le système détecte que le nombre
maximal de SMS du mois courant pour le service de demande de chéquier
est atteint. Le scénario E5 démarre au point 6 du scénario
nominal.
|
Le système met à jour la table des SMS entrant
avec pour remarque : « Nombre maximal de SMS
atteint »
Dans ce cas, le scénario nominal s'arrête au
point 6
|
E6
|
Le système n'arrive pas à envoyer le
premier SMS. Le scénario E6 démarre au point 13 du
scénario nominal.
|
Le système met à jour la table des SMS sortant
avec un statut permettant d'identifier la source d'erreur. Le SMS sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
13.
|
E7
|
L'utilisateur donne un accord négatif à
la demande de chéquier. Le scénario E7 démarre au point
15 du scénario nominal.
|
Formatage du second message à retourner au client lui
informant que sa demande n'a pas été traitée avec la cause
du non traitement.
|
E8
|
Le système n'arrive pas à envoyer le
second SMS. Le scénario E6 démarre au point 21 du
scénario nominal.
|
Le système met à jour la table des SMS sortant
avec un statut permettant d'identifier la source d'erreur. Le SMS sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
21.
Figure 13 : Diagramme de
sequence du cas d'utilisation « demande de
chéquier »
Figure 14 : Diagramme
d'activité du cas d'utilisation demande de
chéquier
Sommaire d'identification
Titre : Alerte crédit compte
Résumé : Ce cas
d'utilisation permet d'envoyer un SM à un client lorsque son compte est
crédité.
Acteurs : Client + mobile, BANK SI
|
Date de création
|
13/03/2009
|
Date de mise à jour
|
10/04/2009
|
|
Version
|
1.0
|
Responsable
|
DOUANLA TOUOPI F.E
|
Pré conditions : Disposer d'un
crédit de communication dans le modem de la banque permettant l'envoi du
SM, le réseau de l'opérateur de téléphonie doit
être opérationnel.
Post conditions : Un SM avec le montant
crédité est envoyé au client
Description des scénarios
- Scénario nominal
|
1. BANK SI met à jour ou effectue un nouvel
enregistrement dans la BD SMS-BANKING avec statut non traité
|
|
2. Le système récupération du nouvel
enregistrement
|
|
3. Le système vérifie si il s'agit d'un
crédit sur un compte
|
|
4. Le système vérifie si le client inscrit au
service « d'alerte en cas de crédit » sur le
compte
|
|
5. Le système vérifie si le nombre maximal de SM
a envoyé au client pour le mois en cours et pour le service d'alerte en
cas de crédit du compte est atteint
|
|
6. Le système formate le message à envoyer au
client avec montant crédité
|
|
7. Le système recherche le numéro de
téléphone du client
|
|
8. Le système insertion SM dans la table d'historique
des SM
|
|
9. Le système insert le SM à envoyer au client
dans la table des SM sortants avec statut (non envoyé)
|
|
10. Mis à jour du Statut de l'enregistrement
(traité)
|
|
11. Le système incrémente le compteur de SM (ce
compteur permet de compter le nombre de SM déjà envoyé au
client durant ce mois. Il est nécessaire pour la vérification du
seuil maximal) pour le service alerte en cas de crédit.
|
|
12. Le système envoie le SM « d'alerte de
crédit du compte » au client
|
|
13. Le système met à jour du statut du SM
sortant: SM envoyé
|
- Scénario alternatif
|
E1
|
Le système détecte que le client n'est
pas inscrit à ce service. Le scénario E1 démarre au point
4 du scénario nominal.
|
Le système met à jour cet enregistrement :
« Client non inscrit au service spécifié »
Dans ce cas, le scénario nominal s arrête au
point 4
|
E2
|
Le système détecte que le nombre
maximal de SM du mois courant pour le service d'alerte en cas de crédit
est atteint. Le scénario E2 démarre au point 5 du scénario
nominal.
|
Le système met à jour cet enregistrement :
« Nombre maximal de SM atteint »
Dans ce cas, le scénario nominal s'arrête au
point 5
|
E3
|
Le système n'arrive pas à envoyer le
SM. Le scénario E3 démarre au point 12 du scénario
nominal.
|
Le système met à jour la table des SM sortant
avec un statut permettant d'identifier la source d'erreur. Le SM sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
12.
Figure 15 : Diagramme de
séquence du cas d'utilisation « alerte credit
compte »
Figure 16 : Diagramme de d'activité du cas d'utilisation
alerte credit compte
Sommaire d'identification
Titre : Alerte virement salaire
Résumé : Ce cas
d'utilisation permet d'envoyer un SM à un client lorsque son salaire est
viré sur son compte.
Acteurs : Client mobile, BANK SI
|
Date de création
|
13/03/2009
|
Date de mise à jour
|
10/04/2009
|
|
Version
|
1.0
|
Responsable
|
DOUANLA TOUOPI F.E
|
Pré conditions : Disposer d'un
crédit de communication dans le modem de la banque permettant l'envoi du
SM, le réseau de l'opérateur de téléphonie doit
être opérationnel.
Post conditions : Un SM avec le montant
viré est envoyé au client
Description des scénarios
- Scénario nominal
|
1. BANK SI met à jour ou effectue un nouvel
enregistrement dans la BD SMS-BANKING avec statut non traité
|
|
2. Le système récupération du nouvel
enregistrement
|
|
3. Le système vérifie si il s'agit d'un virement
salaire sur un compte
|
|
4. Le système vérifie si le client inscrit au
service « virement salaire » sur le compte
|
|
5. Le système vérifie si le nombre maximal de SM
a envoyé au client pour le mois en cours et pour le service d'alerte en
cas de débit du compte est atteint
|
|
6. Le système formate le message à envoyer au
client avec montant viré
|
|
7. Le système recherche le numéro de
téléphone du client
|
|
8. Le système insertion SM dans la table d'historique
des SM
|
|
9. Le système insert le SM à envoyer au client
dans la table des SM sortants avec statut (non envoyé)
|
|
10. Mis à jour du Statut de l'enregistrement
(traité)
|
|
11. Le système incrémente le compteur de SM (ce
compteur permet de compter le nombre de SM déjà envoyé au
client durant ce mois. Il est nécessaire pour la vérification du
seuil maximal) pour le service alerte en cas de virement salaire.
|
|
12. Le système envoie le SM « de virement
salaire » au client
|
|
13. Le système met à jour du statut du SM
sortant: SM envoyé
|
- Scénario alternatif
|
E1
|
Le système détecte que le client n'est
pas inscrit à ce service. Le scénario E1 démarre au point
4 du scénario nominal.
|
Le système met à jour cet enregistrement :
« Client non inscrit au service spécifié »
Dans ce cas, le scénario nominal s arrête au
point 4
|
E2
|
Le système détecte que le nombre
maximal de SM du mois courant pour le service d'alerte en cas de crédit
est atteint. Le scénario E2 démarre au point 5 du scénario
nominal.
|
Le système met à jour cet enregistrement :
« Nombre maximal de SM atteint »
Dans ce cas, le scénario nominal s'arrête au
point 5
|
E3
|
Le système n'arrive pas à envoyer le
SM. Le scénario E3 démarre au point 12 du scénario
nominal.
|
Le système met à jour la table des SM sortant
avec un statut permettant d'identifier la source d'erreur. Le SM sera
renvoyé plus tard.
Dans ce cas, le scénario nominal reprendra au point
12
Figure 17 : Diagramme de
séquence du cas d'utilisation « alerte virement
salaire »
Figure 18 : Diagramme
d'activité du cas d'utilisation alerte virement salaire
| 
