Credit Scoring: L'octroi des Cartes bancaires (PFE)

Chapitre II :

Capture des besoins et

analyse

Ce chapitre a pour principal objectif la spécification des besoins fonctionnels et non fonctionnels de l'application.

Cette étape de conception va nous permettre de préciser l'étude du contexte du futur système en décrivant les façons qu'auront les acteurs de l'utiliser.

1 Contexte du système

Nous avons cherché une solution pour permettre aux organismes financiers émetteurs de mieux évaluer le risque inhérent à l'octroi d'un produit carte. Nous avons donc cherché à définir des critères d'évaluation (relatif à chacun des produits carte) et d'y associer un système de pondération ; et ce, dans l'objectif d'identifier et de mesurer les facteurs de risque conduisant à l'acceptation ou le rejet de la demande.

L'éligibilité d'un client à un produit carte est en fonction de son score par rapport à la classification des produits carte de l'institution.

Le système devrait avoir, pour les organismes financiers émetteurs, les opportunités et les valeurs ajoutées suivantes :

- Maîtrise du risque

- Profitabilité accrue

- Réactivité et pertinence dans le traitement des demandes

Ainsi que les points forts et atouts suivants :

- Solution ouverte

- Multi-produit carte

- Paramétrable : choix des critères d'évaluation et du système de pondération

Quelles sont les contraintes ?

Deux critères importants doivent être pris en considération lors de la conception de la solution :

- La flexibilité : les besoins des clients sont définis au fur et à mesure de l'avancement du projet.

- Extensibilité : de nouveaux besoins peuvent être exprimés par les clients à tout moment.

1.1 Identification des besoins fonctionnels :

Le système comporte quatre acteurs :

- Le client : un client de la banque demandant une carte bancaire.

- Le responsable client : l'administrateur du système.

- Le responsable service : l'agent de la banque.

- L'analyste : l'analyste financier de la banque.

Le système comporte cinq modules, à savoir :

· Module d'authentification : ce module permet d'identifier les utilisateurs de l'application.

· Module création d'une nouvelle demande : ce module permet au client de commander une carte bancaire en ligne.

· Module vérification des données : ce module permet au responsable client de vérifier les conformités des informations du client.

· Module gérer le système : ce module permet au responsable service de gérer la base des règles ainsi que les caractéristiques des cartes bancaires.

· Module évaluation : permet à l'analyste d'évaluer les demandes afin de donner un score à la demande.

1.2 Méthode d'indentification des besoins: Furps+

L'obligation est définie comme « une condition ou une capacité d'un système qui doit être conforme».

Il existe de nombreux types d'exigences. Une façon de classer entre eux est décrit comme le FURPS + modèle [GRA92], en utilisant l'acronyme FURPS de décrire les grandes catégories de besoins avec des sous-catégories,

Comme indiqué ci-dessous :

- Functionality (Fonctionnalité)

- Usability (Facteur humain)

- Reliability (Fiabilité)

- Performance (Performance)

- Supportability (Possibilité de prise en charge)

Le "+" dans FURPS + rappelle à inclure de telles exigences comme: - Contraintes de conception

- exigences de mise en oeuvre

- exigences en matière d'interface

- conditions matérielles.

1.2.1 Fonctionnalités du système :

Identification du client

Le client saisie ses informations

Le client choisi une carte

Identification du responsable client

Le responsable client consulte les demandes de crédit en cours

Le responsable client reçoit la demande de carte du client avec la carte souhaitée Le responsable client vérifie les informations du client

Le responsable client, si besoin, modifie, ajoute les informations du client Identification de l'analyste

L'analyste note les informations du client sans voire les données personnelles du client L'analyste lance le calcule du score

Identification du responsable système

Le responsable système gère la base de règles de pondération

Le responsable système gère les types des cartes dans l'établissement bancaire Le responsable système gère les utilisateurs

1.2.2 Usage :

Les facteurs humains:

Utilisateurs expérimentés dans le domaine informatique Formations des utilisateurs

Interface utilisateur :

Ergonomique

Eviter les couleurs liées au daltonisme

Les instructions doivent être compréhensibles

Guider le client avec des écrans.

Les menus, les icônes sur l'écran doivent être faciles à utiliser.

1.2.3 Fiabilité

L'efficacité : l'application doit fournir des réponses exactes et fiables.

La robustesse : l'application doit respecter des cohérences de traitement des informations.

L'extensibilité : l'application doit être capable de faire face à des charges d'utilisation variables. En effet, la consommation de ressources doit être la plus linéaire et la plus prévisible possible.

L'évolutivité : l'application doit évoluer afin de satisfaire aux exigences de performances croissantes

1.2.4 Performance

La rapidité et performance: Elle doit offrir un temps de réponse minimal pour le téléchargement et l'affichage des pages.

L'écran doit guider les clients pour faciliter l'utilisation et diminuer le temps de traitement de la demande.

Le temps de calcul du score doit être assez cours.

1.2.5 Possibilité de prise en charge

Installer et mettre à jour facilement l'application, la surveiller, localiser les problèmes, Modifier sa configuration si nécessaire.

Installer sans avoir de problèmes.

Supporter l'augmentation de la charge.

Possibilité de modifier les fonctionnalités à des coûts raisonnables. (Extensibilité) Possibilité de comprendre sans efforts excessifs l'organisation interne et le fonctionnement du système et d'y apporter des modifications.

1.2.6 Obligation de mise en oeuvre

La stratégie de sécurité d'authentification ainsi que les politiques de l'intégrité de la base de données seront adaptées à la stratégie de la banque. Cependant l'application doit permettre l'identification des utilisateurs, la fiabilité, la confidentialité et l'intégrité des données.

1.2.7 Exigence d'interface

La convivialité : l'application doit prévoir une facilité d'utilisation et d'accès aux informations.

Interaction : l'application doit respecter et améliorer le dialogue entre Homme et Machine et doit satisfaire les besoins du client.

1.3 Identification des acteurs et des cas d'utilisations

1.3.1 Les acteurs

· Le client

· Le responsable service

· Le responsable client

· L'analyste

1.3.2 Les cas d'utilisations

· S'authentifier

· Créer une nouvelle demande

· Vérifier les informations

· Evaluer la demande

· Gérer le système

1.4 Représentation du modèle de cas d'utilisation initial

Figure 6 : Modèle de cas d'utilisation initial

1.5 Raffinement des cas d'utilisations

1.5.1 Raffinement du cas d'utilisation « s'authentifier »

Ce raffinement présente le diagramme du module « Authentification »

Figure 7 : cas d'utilisation "s'authentifier"

Cas d'utilisation : « S'authentifier »

> Acteurs Principal: Client, responsable client, responsable service, analyste > Pré conditions : pour le client : avoir un compte à la banque, pour les autres : être un employé de la banque

> Post-conditions : utilisateur authentifié

> Description du scénario :

· L'utilisateur s'identifie en saisissant son nom d'utilisateur et son mot de Passe.

· Le système vérifie leurs existences :

- Si le nom d'utilisateur et le mot de passe sont valides, l'utilisateur

sera connecté au système et dirigé vers la page qui lui est destinée
- Si le nom d'utilisateur et le mot de passe sont invalides, une

interdiction d'accès est signalée.

1.5.2 Raffinement du cas d'utilisation « créer une nouvelle demande »

Ce raffinement présente le diagramme du module « créer une nouvelle demande »

Figure 8 : cas d'utilisation "créer une nouvelle demande"

Cas d'utilisation : « Créer une nouvelle demande »

> Acteurs Principal: Client.

> Pré conditions : Client authentifié.

> Post-conditions : Demande effectuée

> Description du scénario : Le client rempli le formulaire puis choisi le carte qu'il souhaite avoir.

1.5.3 Raffinement du cas d'utilisation « vérifier les informations »

Ce raffinement présente le diagramme du module « vérifier les informations »

responsable client vérifier les informations

Figure 9 : cas d'utilisation « vérifier les informations »

Cas d'utilisation : « Vérifier les informations »

> Acteurs Principal: Responsable client.

> Pré conditions : Responsable client authentifié, demande créée. > Post-conditions : vérification effectuée.

> Description du scénario : Le responsable client vérifie la conformité des données que le client a enregistrées.

1.5.4 Raffinement du cas d'utilisation « gérer le système»

Ce raffinement présente le diagramme du module « gérer le système »

gèrer la base de règle

<<extend>>

			<<extend>>

responsable service gèrer le système		gèrer les cartes
		<<extend>>

gèrer les utilisateurs

Figure 10 : cas d'utilisation « gérer le système»

Cas d'utilisation : « Gérer le système »

> Acteurs Principal: Responsable service.

> Pré conditions : Responsable authentifié.

> Post-conditions : aucune.

> Description du scénario : Le responsable service gère la base de règle et

les caractéristiques des cartes.

1.5.5 Raffinement du cas d'utilisation « évaluer la demande»

Ce raffinement présente le diagramme du module « évaluer la demande »

			<<include>>

évaluer la demande noter les informations

analyste

Figure 11 : cas d'utilisation « évaluer la demande»

Cas d'utilisation : « évaluer la demande »

> Acteurs Principal: Analyste.

> Pré conditions : analyste authentifié, informations vérifiées, base de règle mise à jour.

> Post-conditions : évaluation effectuée.

> Description du scénario : L'analyste reçoit les informations pertinentes de la demande à évaluer et note chaque information.

2 Etude de l'architecture :

Après avoir exprimé les besoins fonctionnels et non fonctionnels, nous pouvons maintenant procéder à la définition de l'architecture de notre système et à la réflexion aux choix techniques correspondants.

2.1 Plateforme :

Une plateforme de gestion des processus d'affaires donne de la capacité de définir collectivement les processus, de les déployer en tant qu'applications accessibles

sur le Web et qui sont intégrées aux logiciels et systèmes existants d'une organisation. Elle permet de s'adapter et de s'arrimer aux systèmes des clients, partenaires et fournisseurs.

Cette plateforme permet de s'intégrer avec les systèmes opérationnels existants comme les progiciels de gestion de type ERP, CRM ou SCM et avec les bases de données.

En effet, ce type d'architecture permet non seulement un développement modulaire d'une application mais aussi garantie sont évolutivité.

2.2 Composants d'un BPMS type :

Figure 12 : composant d'un BPMS type

2.3 Architecture n-tiers :

Dans une plateforme de gestion de processus d'affaires, nous adaptons une architecture de 3-tiers (architecture à trois niveaux).

L'architecture trois tiers est l'application du modèle le plus général qu'est le multi-tiers et c'est également une extension du modèle client/serveur.

L'architecture logique du système est divisée en trois niveaux ou couches :

· Couche présentation

· Couche métier

· Couche accès aux données

Plus spécifiquement c'est une architecture partagée entre :

· Un client, c'est-à-dire l'ordinateur demandeur de ressources, équipée d'une interface utilisateur chargée de la présentation ;

· Le serveur d'application (appelé également middleware), chargé de fournir la ressource mais faisant appel à un autre serveur ;

· Le serveur de données, fournissant au serveur d'application les données dont il a besoin.

Requêtes

Envoi de

Requête
SQL

Envoi de

Réponses

Client Serveur Serveur de bases

d'application de données

Niveau 1 Niveau2 Niveau3

Figure 13 : Architecture Trois Tiers

3 Conclusion

Ce chapitre nous a permis de mieux connaître et comprendre nos besoins fonctionnels et non fonctionnels par l'étude et le raffinement des différents cas d'utilisation. Ce qui nous donne la possibilité de passer à l'analyse de ces cas qui sera traitée dans le prochain chapitre.