Résumé : Ce cas d'utilisation permet
à un client de gérer police d'assurance
Date : 09/11/2016 Date de mise
à jour : 09/11/2016
Versions : 0.1
Responsable : DJYAMO Azore
Précondition : Le manager s'est
authentifié
Scénario nominal (N1):
N1.1- Le Guichetier demande le formulaire d'enregistrement de
police d'assurance
N1.2- Le système affiche le formulaire
N1.3- Le Guichetier renseigne les champs (A1,
E1)
N1.4- Le système confirme le succès de
l'opération
|
Scénario nominal (N2):
N2.1- Le Guichetier sélectionne une police puis demande
une mise à jour de champs
N2.2- Le système affiche les champs éditables
N2.3- Le Guichetier édite les champs ciblés (A2)
N2.4- Le système confirme le succès de la mise
à jour
|
Scénario nominal (N3):
N3.1- Le Guichetier sélectionne la police à
supprimer
N3.2- Le système demande une confirmation de l'action (A3,
E3)
N3.3- Le Guichetier supprime la police
Conception des systèmes décisionnels basée
sur l'analyse des processus métiers
N3.4- Le système confirme le succès de
l'opération
Post-condition :
3. Le devis est affiché
Scénario alternatif :
A1. Une donnée des champs est incorrecte
a. Le système affiche un message à l'utilisateur
l'informant de l'erreur
b. Retour au point N1.2 du scénario nominal
A2. Une donnée des champs est incorrecte
a. Le système affiche un message à l'utilisateur
l'informant de l'erreur
b. Retour au point N2.3 du scénario nominal
A3. La police sélectionnée n'est pas celle
ciblée
a. Le Guichetier annule l'opération
b. Retour au point N3.1 du scénario nominal
|
Scénario d'exception :
E1. La police avait déjà été
enregistrée
N1.4- Le système affiche un message indiquant que cette
police existe déjà
Le cas d'utilisation se termine en
échec.
E3. Le Guichetier renonce à la suppression
N3.4- Le Guichetier annule l'opération
Le cas d'utilisation se termine en
échec.
|
3.2 Expression des besoins non fonctionnels
L'expression des besoins non fonctionnels a pour objet de
formaliser et de détailler la partie « technique » de ce qui a
été produit au cours de l'étude préliminaire. Il
s'agit des besoins qui caractérisent le système. Ce sont des
besoins en matière de performance, de type de matériel ou le type
de conception. Ces besoins peuvent concerner les contraintes liées
à l'implémentation (langage de programmation, de système
d'Exploitation...) ou à l'interopérabilité
générale. En effet, ces besoins peuvent être fixés
par le client (fonctions optionnelles), ou par le développeur
(contraintes d'implémentation). Dans cette optique, notre application
devra satisfaire les spécifications suivantes :
Pour l'application web :
+ Pouvoir supporter un nombre élevé de
requêtes client simultanées;
+ Utiliser une base de données relationnelle ;
+ Les informations sensibles comme les mots de passe seront
chiffrés ;
+ Offrir des services de sécurité ;
+ Offrir une interface conviviale et optimisée ;
+ Fonctionner en architecture applicative 3-tiers;
Pour le système décisionnel :
> De disposer d'un SGBD robuste et open source ; >
D'utiliser des outils ETL open source ;
DJYAMO Azore - Mémoire de fin de cycle Master
CSI/IAI-siège/2015-2016 Page | 54
+
+ supprimer ()
DJYAMO Azore - Mémoire de fin de cycle Master
CSI/IAI-siège/2015-2016
Page | 55
Conception des systèmes décisionnels basée
sur l'analyse des processus métiers
> D'utiliser des outils de reporting open source ;
> D'être capable d'extraire, de traiter et de
transférer des données de sources divers et de type varié
;
> De disposer d'une sécurité adaptée
;
> Être performant pour le calcul d'agrégats sur
de gros volumes de données (exploration de données,
reporting)
> Être appréhendable par un utilisateur final,
en particulier pour formuler facilement des requêtes (exploration de
données)
> Être suffisamment performant au chargement pour
répondre aux sollicitations de mise à jour (ETL)
> Être évolutif en fonction des
évolutions amont (sources transactionnels) et aval (besoins
d'exploitation) (ETL, métadonnées) ;
| 
