V.1. INTRODUCTION
L'objectif de l'application est de faciliter le suivi de
distribution des produits pétroliers auprès des clients. Au
niveau de ce chapitre, qui constitue la première phase du processus
unifié « incubation », nous détaillons et analysons les
besoins fonctionnels et non fonctionnels de notre projet.
V.2 CAPTURE DES BESOINS
V.2.1. Besoins fonctionnels
Un besoin fonctionnel spécifie l'action qu'un
système doit être capable d'effectuer, hors contrainte physique :
besoin spécifiant un comportement d'entrée/sortie d'un
système (17).
La gestion du circuit de distribution des produits
pétroliers doit être assurée durant toutes ses phases,
dès l'initiation jusqu'à la clôture. La première
étape est la réception des commandes par les clients contenant
toutes les spécifications détaillées, puis la publication
d'un programme de livraison. Une fois le programme de livraison publié,
il faut procéder à l'exécution de programme de livraison
et l'analyse de ce dernier permet d'ordonner les livraisons aux clients.
Dans ce contexte notre application de gestion du circuit de
distribution des produits pétroliers, implémente les
fonctionnalités suivantes :
- Le suivi de la distribution : chaque responsable de la
direction de la distribution peut consulter la situation d'un circuit de
distribution, ou bien la liste de tous les clients dont on doit livrés
les produits pétroliers.
- La gestion de commande : le responsable chargé de la
gestion du mouvement de produit doit informer celui qui gère le circuit
de distribution du niveau de stock dans le dépôt.
(17) MORLEY C., LEBLANC B. et HUGUES J., UML pour
l'analyse d'un système d'information, Le
cahier des charges du maître d'ouvrage, Dunod, Paris,
2000.
Mémoire dirigé par Eric WANGI
NGOY
M F I T I G r a c e P a g e | 60
- L'élaboration des produits dans le stock : le
chargé de l'élaboration des produits en stock doit
présenter à celui qui est chargé de la commande de la
situation générale de chaque produit dans le
dépôt.
- Le chargé de suivi des instructions : doit informer
le responsable de la gestion de la distribution du respect des instructions ou
non en ce qui concerne le programme du dispatching des produits auprès
de clients.
V.2.2. Besoins non fonctionnels
Un besoin non fonctionnel est besoin spécifiant des
propriétés du système, telles que les contraintes
liées à l'environnement et l'implémentation, les exigences
en matière de performances, de dépendances de plate-forme, de
facilité de maintenance, d'extensibilité et de fiabilité
(18).
Dans notre système, on distingue les besoins non
fonctionnels suivant :
- Sécurité : la plateforme doit assurer la
sécurité pour les utilisateurs (Authentification).
- Convivialité : ergonomie des interfaces homme machine
et facilité d'utilisation.
- Contrôle : saisie contrôlée selon les choix
prédéfinis.
- Gagner du temps à l'intérieur de l'entreprise.
V.3. ANALYSE DES BESOINS V.3.1. Modèle cas
utilisation
La spécification des besoins représente
l'ensemble des services que doit fournir le logiciel à son utilisateur
(19). Selon le processus unifié chaque service est
modélisé sous un cas d'utilisation, pour élaborer à
la fin un diagramme UML de cas d'utilisation. Chaque cas d'utilisation est
décrit sous une forme textuelle représentant un scenario nominal
(ensemble des actions à réaliser pour atteindre l'objectif).
Dans cette partie, nous allons dégager tous les acteurs
en les décrivant. Ensuite, nous allons exprimer dans des phrases les
principales actions du système et des acteurs. Enfin, nous allons
représenter et décrire
(18) LAI M., UML : La notation unifiée de
modélisation objet - De Java aux EJB, Dunod, Paris, 2000
(19) Idem
Mémoire dirigé par Eric WANGI
NGOY
M F I T I G r a c e P a g e | 61
les différents diagrammes des cas d'utilisation pour
donner une vue externe sur notre système.
V.3.1.1. Identifications des acteurs
Un acteur est une personne, un matériel ou un logiciel
qui interagit directement avec le système pour réaliser une
tâche. Ainsi, un acteur peut consulter et/ou modifier directement
l'état du système en émettant et/ou recevant des messages
susceptibles contenir des données.
Notre système comprend plusieurs utilisateurs que nous
citons : le responsable de la direction, le responsable du mouvement des
produits, le chargé du dispatching commercial, le chargé de suivi
de traitement des instructions et le chargé de l'élaboration des
stocks dans les dépôts de l'intérieur.
- Le responsable de la direction de distribution
(RDD): le système lui offre la possibilité de s'authentifier
et gérer les activités faites par le responsable du mouvement des
produits, le chargé de suivi de traitement des instructions, le
chargé de l'élaboration des stocks dans les dépôts
de l'intérieur et le chargé du dispatching commercial.
- Responsable adjoint de l'assurance du respect des
procédures du service de distribution (CRASD): traite des
vignettes, c'est-à-dire contrôler les factures de consommations
des carburante par les entités de SEP, fait le suivi des sorties des
clients de dépôts et de bases, c'est-à-dire il s'agit de
toutes les sorties des produits pétroliers réaliser dans les
dépôts pour le compte des sociétés commerciales,
établi des commandes carburants pour le compte des entités,
dépôts et bases de SEP, fait le suivi des consommations de
dépôts.
- Le responsable du mouvement des produits (RMD) :
émet les bons et établi les programmes dans un
système de gestion de base des données (SGBD) appelés
SUN.
a) Le chargé du dispatching commercial (CDC):
fait l'établissement du dispatching qui découle du
traitement des instructions.
b) Le chargé de suivi de traitement des
instructions (CSI) : fait le suivi des établissements du
dispatching.
c) Le chargé de l'élaboration des stocks
dans les dépôts de l'intérieur (CES) : élabore
des stocks par produit et par sociétés commerciales dans chaque
province et fait la facturation des services demandés aux
sociétés commerciales.
M F I T I G r a c e P a g e | 62
| 
