Capture les besoins fonctionnels : plateforme de e-commerce

Les 14 étapes pour créer une plateforme de e-commerce (avec cas)

Le BenchMarking : Définition, offre du marché et analyse

Partie 2: BenchMarking

1. BenchMarking : définition

« Le BenchMarking (en français: analyse comparative) est une technique de gestion de la performance qui consiste à étudier les différentes techniques de gestion et d’organisation des autres entreprises afin de s’inspirer et d’en tirer les meilleurs » [UNIVLI 10].

2. Etude de l’offre du marché

Avant de développer une nouvelle plateforme de commerce électronique, il est indispensable et très préférable de débuter avec une étude des solutions déjà disponibles sur le marché afin de pouvoir choisir la meilleure solution en termes de coût et fonctionnalités.

Il faut être stratégique avant de créer une nouvelle plateforme, et notre stratégie c’est de procéder par « BenchMarking », qui consiste à choisir les meilleures solutions et d’en faire une comparaison afin d’extraire les points forts (coût, fonctionnalités, délai, qualité, simplicité…etc.) de chacune pour les adapter a notre solution si le besoin le réclame.

Présentation des outils de Benchmarking

3. Analyse Comparative

Concernant les plates‐formes e-commerce, il existe plusieurs solutions sur le marché et dans le cadre de notre analyse nous avons choisi les solutions qui nous paraissaient les plus complètes en termes de fonctionnalités; nous avons donc préparé un comparatif entre ces dernières:

Liste fonctionnalité BoutikOne WIZISHOP CyberShop Notre plateforme

Tableau04. BenchMarking entre les solutions e‐commerce [WIZSH 10/BOUTO 10/CYBSHO 10]

4. Choix de la solution

Nous avons réalisé notre étude comparative sur les solutions existantes sur le marché, en choisissant les meilleures d’entre elles en termes de coût mais surtout de fonctionnalités, car le but était recenser toutes les fonctionnalités possibles afin de connaître le besoin du marché, la situation des concurrents et de pouvoir s’inspirer et se placer dans le marché.

La solution qu’on va élaborer n’est pas l’une des solutions précédentes, mais plutôt une toute nouvelle plateforme qu’on va développer sauf qu’on va tenir compte de toutes les fonctionnalités citées ci‐dessus (voir Tableau.) puis en choisir celles qui peuvent correspondre à notre besoin et les intégrer dans notre propre solution.

Chapitre 1 : Capture des besoins

1. Capture des besoins fonctionnels

Nous allons procéder selon la méthode UML qui consiste à recenser et modéliser les différents processus métiers afin de migrer facilement vers une architecture objet d’un point de vue statique et dynamique.

Cette analyse présente une abstraction totale étant indépendante de toute technologie ou implémentation.

La spécification des besoins va nous permettre d’avoir une meilleure approche des utilisateurs, des fonctionnalités et de la relation entre les deux. Elle sera sous forme de cas d’utilisation.

Pour cela nous allons procéder ainsi:

• Identification des acteurs du nouveau système.
• Identification des cas d’utilisations.
• Description des cas d’utilisations.
• Regroupement des cas d’utilisation en paquetages.

1.1. Identification des acteurs

Dans UML on n’utilise pas le terme d’utilisateurs mais d’acteurs. Un acteur d’un système est une entité externe à ce système qui interagit (saisie de données, réceptions d’informations,…) avec lui.

Les acteurs permettent de cerner l’interface que le système va offrir à son environnement.

Un acteur regroupe plusieurs utilisateurs qui ont le même rôle. Et pour trouver un acteur il faudra identifier les différents rôles que vont devoir jouer ses utilisateurs.

Afin de faciliter l’identification, on peut imaginer ceci: tout ce qui est à l’extérieur et interagit avec le système est un acteur, tout ce qui à l’intérieur est une fonctionnalité à réaliser.

Les différents acteurs du système étudié sont:

• Service commercial.
• Service administratif.
• Client.

1.2. Identification des objectifs et cas d’utilisations

Un cas d’utilisation décrit sous la forme d’actions et de réactions, le comportement d’un système d’un point de vue utilisateur.

Il doit apporter une valeur ajoutée à l’acteur concerné. Chaque cas d’utilisation contient une liste de fonctionnalités qu’on va détailler dans la partie suivante.

On va tout d’abord déterminer les objectifs qui vont nous permettre de déduire les cas d’utilisation et tout cela:

Tableau05. Identification des objectifs fonctionnels et des cas d’utilisation associés.

1.3. Description des cas d’utilisation

Après avoir listé tous les cas d’utilisations, on va maintenant faire une description textuelle de chaque cas et le décrire séparément afin d’avoir une idée plus détaillée sur le fonctionnement de chacun d’eux.

La description qu’on va élaborer est structurée comme suit:

• Titre du cas d’utilisation.
• Pré‐conditions.
• Scénario nominal.
• Exceptions.
• Post‐conditions.

1.3.1. Cas d’utilisation: « Identification »

Précondition de l’identification

• L’utilisateur saisit ses droits d’accès (login et mot de passe)

Acteurs de l’identification

• Tous les acteurs.

Scénario nominal de l’identification

1. Identification

• L’utilisateur saisit ses droits d’accès.
• Le système vérifie si les champs ne sont pas vides, si erreur alors Exception1.
• Il vérifie ensuite si les informations sont valides, si erreur alors Exception2.
• Le système contrôle si c’est un nouvel acteur, ou un acteur désactivé.
• Le système redirige l’acteur vers son espace selon son rôle.

2. Inscription

• L’utilisateur introduit les informations demandées dans le formulaire et valide son inscription.
• Le système vérifie si les champs obligatoires sont renseignés. Si erreur alors exécuter Exception3.
• Le système vérifie si les informations sont valides, si erreur alors Exception4.
• Il vérifie si le pseudo et l’email existent ou pas, si oui alors Exception5.
• Le système envoie un mail de confirmation.

Exceptions de l’identification

1. Exception1: message d’erreur « Un champ est vide ». L’acteur s’authentifie une 2^ème fois.
2. Exception2: message d’erreur « login et mot de passe doivent avoir au moins 6 caractères ». L’utilisateur s’authentifie une 2ème fois.
3. Exception3: un message d’erreur contenant: « Un champ obligatoire est vide ». L’acteur doit remplir les champs obligatoires.
4. Exception4: message d’erreur « login et mot de passe doivent avoir au moins 6 caractères ». L’acteur doit revérifier les champs.
5. Exception5: un message d’erreur contenant: ou bien c’est un champ qui est vide, ou bien le nom existe déjà. L’utilisateur est invité à corriger son erreur et revalider.

Postcondition

• Ouverture de l’espace personnel

Figure12. Diagramme d’activités des cas d’utilisation « Identification ».

Suivi des rôles et des utilisateurs dans l’e-commerce

1.3.2. Cas d’utilisation : « Suivi des rôles»

Acteurs de suivi des rôles

• Administrateur.

Précondition de suivi des rôles

• l’acteur doit être authentifié.
• Les utilisateurs doivent être membres.

Scénario nominal de suivi des rôles

1. Consulter les utilisateurs par rôle

• L’acteur sélectionne un rôle.
• Le système affiche la liste des utilisateurs correspondant à ce rôle.

2. Changer le rôle d’un utilisateur

• L’acteur saisit un nom d’utilisateur.
• Le système lui suggère une liste d’utilisateurs à chaque mot tapé.
• L’acteur choisit un utilisateur, et le système lui affiche ses infos ainsi que la possibilité de changer son rôle.
• Il valide le changement.

Postcondition de suivi des rôles:

• Rôles mis à jour.
• Mise à jour de la base de données.

Figure13. Diagramme d’activités des cas d’utilisation « gestion des rôles ».

1.3.3. Cas d’utilisation : « Suivi des utilisateurs»

Acteurs de suivi des utilisateurs

• Administrateur, commercial

Précondition de suivi des utilisateurs

• L’acteur doit s’authentifier.

Scénario nominal de suivi des utilisateurs

1. Ajouter utilisateur

• L’acteur(Administrateur) saisit les informations concernant le nouvel utilisateur du système.
• Si erreur alors Exception1.

2. Mise à jour informations utilisateur

• L’acteur choisit l’utilisateur concerné.
• Il met à jour les informations qu’il veut modifier et valide la procédure, si erreur alors Exception1.

3. Consulter fiche utilisateur

• L’acteur affiche la liste des utilisateurs et choisit l’utilisateur qu’il veut consulter.
• Il affiche les informations relatives à cet utilisateur.

4. Désactiver un utilisateur

• L’acteur choisit l’utilisateur qu’il veut désactiver.
• Il désactive son compte. Le système place cet utilisateur dans la liste des anciens utilisateurs et exécute Exception2.

Exceptions de suivi des utilisateurs

1. Exception1: le message indique que l’utilisateur existe déjà ou l’acteur a oublié un champ à remplir, il est donc invité à réinscrire l’utilisateur.
2. Exception2: la suppression est seulement logique (on change la valeur du statut ainsi que le pseudo et le mot de passe).

Postcondition de suivi des utilisateurs

• Mise à jour de la base de données.

Figure14. Diagramme d’activités des cas d’utilisation « gestion des utilisateurs ».

1.3.4. Cas d’utilisation: « Suivi des clients »

Acteurs de suivi des clients

Client.

Précondition de suivi des clients

• L’acteur doit s’authentifier.

Scénario nominal de suivi des clients

1. Mise à jour des informations

• Le client accède à son espace perso et choisit d’afficher ses informations personnelles.
• Il met à jour les informations concernées.
• Il valide les changements, et si erreur alors Exception1.

2. Consulter profil

• Le client sélectionne la rubrique à consulter dans son profil (achats, commandes, compte…).
• Il consulte la rubrique sélectionnée.

3. Désactiver compte

• Le client choisit de désactiver son compte.
• Il coche la cause de la désactivation.
• Il valide l’opération et le système le déconnecte en le renvoyant vers la page accueil. Exception2

Exceptions de suivi des clients

1. Exception1: un champ est vide ou invalide, le client doit revoir ses modifications.
2. Exception2: La désactivation est seulement logique (On utilise un champ « statut » et on met sa valeur à « désactivé »).

Postcondition de suivi des clients

• Mise à jour de la base de données.

Figure15. Diagramme d’activités des cas d’utilisation « gestion des clients ».

e-Commerce : gestion des catégories, marques et produits

1.3.5. Cas d’utilisation: « Gestion des catégories»

Acteurs:

• Commercial.

Précondition

L’acteur doit s’authentifié.

Scénario nominal

1. Ajouter une catégorie

• L’acteur remplit les champs du formulaire.
• Le système vérifie si un champ est vide, invalide ou catégorie existante, si erreur alors Exception1.
• Il valide l’ajout de la nouvelle catégorie.

2. Modifier une catégorie

• L’acteur sélectionne la catégorie qu’il veut modifier.
• Il met à jour les informations concernées par la modification et valide, si erreur alors Exception1.

3. Liste des produits par catégorie

• L’acteur sélectionne une catégorie.
• Le système lui affiche a liste des produits appartenant à cette catégorie.

4. Supprimer une catégorie

• L’acteur choisi la catégorie qu’il veut supprimer.
• S’il valide alors Exception2.

Exceptions:

1. Exception1: un message d’erreur apparaît relatif à l’erreur rencontrée.
2. Exception2: les produits de la catégorie supprimée sont toujours disponibles dans la liste des produits avec sans catégorie renseignée.

Postconditions:

• Catalogue mis à jour.
• Mise à jour de la base de données.
  
  Figure16. Diagramme d’activités des cas d’utilisation « Gestion des catégories ».

1.3.6. Cas d’utilisation: « Gestion des marques»

Acteurs de gestion des marques

• Commercial.

Précondition de gestion des marques

• L’acteur doit s’authentifié.

Scénario nominal de gestion des marques

1. Ajouter une marque

• L’acteur remplit les champs du formulaire.
• Le système vérifie si un champ est vide, invalide ou marque existante, si erreur alors Exception1.
• Il valide l’ajout de la nouvelle marque.

2. Modifier une marque

• L’acteur sélectionne la marque qu’il veut modifier.
• Il met à jour les informations concernées par la modification et valide, si erreur alors Exception1.

3. Liste des produits par marque

• L’acteur sélectionne une marque.
• Le système lui affiche la liste des produits appartenant à cette marque.

4. Supprimer une marque

• L’acteur choisit la marque qu’il veut supprimer.
• S’il valide alors Exception2.

Exceptions de gestion des marques

1. Exception1: un message d’erreur apparaît relatif à l’erreur rencontrée.
2. Exception2: les produits de la marque supprimée sont toujours disponibles dans la liste des produits avec sans marque renseignée.

Postconditions de gestion des marques

• Catalogue mis à jour.
• Mise à jour de la base de données.

Figure17. Diagramme d’activités des cas d’utilisation « Gestion des marques ».

1.3.7. Cas d’utilisation: « Gestion des produits»

Acteurs de gestion des produits:

• Administrateur, Client, Commercial

Précondition de gestion des produits:

• L’acteur doit s’authentifié

Scénario nominal de gestion des produits:

1. Ajouter produit

• L’acteur (administrateur ou commercial) saisi les informations obligatoires du formulaire. Si la catégorie ou la marque n’existe pas alors Exception1.
• Il valide l’ajout, si erreur alors Exception2.

2. Mise à jour des informations d’un produit

• L’acteur (administrateur ou commercial) choisi dans la liste, le produit qu’il veut modifier.
• Il met à jour les informations relatives à ce produit et valide l’opération, si erreur alors Exception2.

3. Taxe des produits

• L’acteur sélectionne le produit concerné.
• Il choisi la catégorie dans laquelle il va l’affecter.
• Il valide l’ajout.
• Si erreur alors Exception2.

4. Consulter fiche produit

• L’acteur choisit dans la liste le produit qu’il veut consulter.
• Le système affiche tous les détails du produit.

5. Liste des produits

• L’acteur choisit dans le menu d’afficher la liste de tous les produits avec leurs descriptions minimales.

6. Trier les produits par critères

• L’acteur choisit de lister tout les produits.
• Il choisit un critère de listage (quantité, prix, ordre alphabétique, catégorie, marque…)

7. Changer la catégorie d’un produit

• L’acteur sélectionne le produit concerné.
• Il choisit une nouvelle catégorie à lui attribuer puis valide.
• Un message de validation apparaît.

8. Changer la marque d’un produit

• L’acteur sélectionne le produit concerné.
• Il choisit une nouvelle marque à lui attribuer puis valide.
• Un message de validation apparaît.

9. Suppression produit

• L’acteur (administrateur ou commercial) sélectionne le produit qu’il veut enlever de la liste.
• Il lance l’opération de suppression.
• Une fenêtre de validation s’affiche.
• S’il valide alors Exception3.

Exceptions de gestion des produits:

1. Exception1: L’acteur peut créer sur la même page, une nouvelle catégorie et/ou marque et le système la prend en charge directement.
2. Exception2: Le produit existe déjà ou l’acteur à oublié de remplir un champ, l’acteur est donc invité à recréer le produit.
3. Exception3: si le produit est commandé et non livré alors la suppression doit être seulement logique (on utilisera un champ « disponible » et on met sa valeur à ‘non’).

Postconditions de gestion des produits:

• Mise à jour de la base de données.

Figure18. Diagramme d’activités des cas d’utilisation « gestion des produits ».

Suivi des fournisseurs et du stock – Capture des besoins

1.3.8. Cas d’utilisation: « Suivi des fournisseurs»

Acteurs de Suivi des fournisseurs:

Administrateur, commercial.

Précondition de Suivi des fournisseurs:

L’acteur doit s’identifier.

Scénario nominal de Suivi des fournisseurs:

1. Ajout fournisseur

• L’acteur saisit les informations nécessaires dans le formulaire et valide l’ajout.
• Le système vérifie si les champs sont renseignés, si non alors Exception1.
• Le système vérifie si le nom existe déjà, si oui alors Exception2.
• Un message de confirmation s’affiche et l’acteur est invité à consulter la liste.

2. Mise à jour des informations d’un fournisseur

• L’acteur choisit le fournisseur dans la liste.
• Il modifie les informations concernées et valide.
• Le système vérifie si les champs sont renseignés et invalides, sinon Exception1.
• Un message de confirmation de modification s’affiche.

3. Liste des fournisseurs

• L’acteur choisit d’afficher la liste des fournisseurs.
• Le système affiche les informations relatives aufournisseur.

4. Liste des produits par fournisseur

• L’acteur choisit de consulter l’historique des fournitures.
• Le système affiche la liste des produits (nom, quantité, date…) par fournisseur.

Exceptions de Suivi des fournisseurs:

1. Exception1: Un champ obligatoire et vide ou invalide, l’acteur est invité à corriger l’erreur.

Post‐condition de Suivi des fournisseurs:

La base de données est à jour.

1.3.9. Cas d’utilisation: « Suivi du stock»

Acteurs de suivi du stock:

Administrateur, commercial, technique.

Précondition de suivi du stock:

L’acteur doit s’authentifié.

Scénario nominal de suivi du stock:

1. Ajouter une entrée en stock

• L’acteur (commercial) reçoit la livraison.
• Il choisit d’ajouter une entrée en stock.
• Il saisit les informations nécessaires sur un produit entré(fournisseurs, date, quantité, prix d’achat).
• Il ajoute le produit à la liste.
• S’il y a un autre produit entré alors il le rajouter sinon il valide.

2. Ajouter une sortie de stock

• L’acteur (commercial) choisit d’effectuer une sortie de stock.
• Il choisi la commande concerné par la sortie de stock.
• Il valide la sortie et la commande est mise à jour.

3. Consultation de l’état du stock

• L’acteur (commercial, administrateur, technique) choisi de consulter l’état actuel su stcock).
• Le système affiche un état du stock courant.

Postconditions de suivi du stock:

Mise à jour de la base de données.

Figure19. Diagramme d’activités des cas d’utilisation « gestion du stock ».

1.3.10. Cas d’utilisation: « Marketing»

Acteurs de Marketing:

• Commercial, Administrateur.

Pré‐condition de Marketing:

• L’acteur doit s’authentifié.

Scénario nominal de Marketing:

1. Afficher les nouveautés

• L’acteur consulte la liste des produits selon leurs statuts nouveautés.
• Il coche le produit qu’il veut afficher comme nouveau.
• Si un produit est déjà coché alors le système affiche le produit le plus récent.

 2. Solder un produit

• L’acteur consulte la liste des produits.
• Il choisi le produit à solder.
• Il attribue un pourcentage(%) sur le prix du produit.
• Le système affiche le prix de base ainsi que le nouveau prix.

Post‐conditions de Marketing:

• Affichage des nouveautés et soldes sur la plateforme.
• Mise à jour de la base de données.

Figure20. Diagramme d’activités des cas d’utilisation « gestion marketing ».

1.3.11. Cas d’utilisation: « Recherche»

Acteurs de recherche:

• Tous les acteurs.

Pré‐condition de recherche

• Accès à la plate‐forme.

Scénario nominal de recherche:

1. Rechercher guidée d’un produit

• L’acteur entre faire une recherche par marques ou catégorie.
• Le système lui affiche la liste catégories ou marques, alors il choisi la catégorie ou la marque correspondante.
• Le système recherche les produits correspondants et les affiche.

2. Rechercher par mot‐clé

• L’acteur se positionne sur la barre de recherche.
• Il saisi le mot‐clé du libellé recherché.
• Si la liste des produits correspondants au mot‐clé saisi s’affiche alors il choisi son produit, sinon le mot clé ne correspond à aucun libellé.

Post‐condition de recherche

• Recherche effectuée.

1.3.12. Cas d’utilisation: « Panier»

Acteurs de panier:

• Clients.

Pré‐condition de panier:

• L’acteur doit se rendre sur le catalogue.

Scénario nominal de panier

1. Ajouter un produit au panier

• L’acteur affiche le catalogue par catégories ou pas marques.
• Il choisi le produit concerné.
• Il peut consulter les détails du produit ou de l’ajouter dans le panier.
• S’il ajoute alors un tableau s’affiche contenant les produits sélectionnés.

2. Lister les produits disponibles dans le panier

• L’acteur termine ses courses et affiche les produits qu’il a mis dans son panier.
• Le tableau contient le prix, taxe, prix de livraison de chaque produit.
• Si l’acteur est d’accord alors valider la commande.

3. Retirer un produit du panier

• Dans la liste des produits présents dans le panier, le client supprime un produit de cette liste.
• Le système met à jour le prix total ainsi que la nouvelle liste de produits.

4. Personnaliser le contenu du panier

• Avant de passer la commande, le client doit renseigner les quantités de chaque produit.
• Le système vérifie si les quantités demandées sont disponibles dans le stock, si non alors Exception1.
• Le client peut valider sa commande.

5. Vider le panier

• L’acteur choisit de vider son panier.
• Il lance l’opération de vidage du panier.
• S’il valide alors Exception2.

Exceptions de panier:

1. Exception1: le client est redirigé vers une page lui expliquant que le produit n’est pas disponible temporairement et qu’il le sera bientôt.
2. Exception2: tous les produits seront supprimés et le montant du panier devient nul.

Post‐conditions de panier:

• Commande prête à être lancée.
• Mise à jour de la base de données.

Figure21. Diagramme d’activités des cas d’utilisation « Panier ».

1.3.13. Cas d’utilisation: « Suivi des commandes»

Acteurs de suivi des commandes:

Administrateur, Client, Commercial.

Précondition de suivi des commandes:

• L’acteur accède à l’application.
• Panier contenant des produits.

Scénario nominal de suivi des commandes:

1. Passage une commande avec livraison

• Le système affiche la liste des produits.
• L’acteur valide sa commande, s’il n’est pas authentifié alors Exception1.
• Si l’acteur n’est pas un client alors Exception2.
• L’acteur est invité à choisir une adresse de livraison ou il peut laisser son adresse personnelle.
• Il choisit d’être livré ou pas.
• Il sélectionne un mode de paiement et affiche un résumé de l’opération.
• Il confirme la commande.

2. Liste des commandes par tri

• L’acteur sélectionne le choix d’afficher la liste des commandes.
• Le système lui retourne une liste de commandes qui peut être triée par date, statut, prix, mode de livraison…

3. Mise à jour de l’état d’une commande

• Le commercial affiche la liste des commandes selon leurs statuts.
• Il met à jour l’état d’une commande dans le cas d’un début et d’une fin de livraison.
• Il valide le changement.

4. Suivi d’une commande

• Le client accède à son espace perso et consulte l’historique de ses commandes.
• Il consulte le statut de la commande (en cours, livré…)

Exceptions de suivi des commandes:

1. Exception1: le système le redirige vers une page d’identification, si c’est un nouveau client alors allé à Inscription, sinon aller à Identification.
2. Exception2: l’acteur doit être un client pour pouvoir faire des achats.

Postconditions de suivi des commandes:

• Commande passée.
• Etat de commande mis à jour.
• Mise à jour de la base de données.

Figure22. Diagramme d’activités des cas d’utilisation « gestion des commandes ».

1.3.14. Cas d’utilisation: « Paiement en ligne»

Acteurs de paiement en ligne:

• Clients

 Précondition de paiement en ligne:

• Commande passée.
• Clients disposant d’une carte de paiement bancaire CIB

Scénario nominal de paiement en ligne :

1. Choisir l’adresse de livraison

• Après la validation de la commande, le client est redirigé vers la page livraison.
• Il choisit de garder son adresse personnelle pour la livraison ou de saisir une nouvelle adresse.
• Ensuite il choisit d’être livré ou pas.
• Il valide.

2. Choisir le mode de paiement

• Le client valide la livraison et accède au paiement.
• Il a le choix entre le paiement classique « Paypal » ou le nouveau mode de paiement « Plateforme de la Satim».
• S’il choisit Paypal alors il sera redirigé vers leur site sinon vers la plateforme Satim.

3. Paiement de la commande

• Une fois la commande passée, l’acteur doit impérativement payer sa commande afin que cette dernière soit prise en compte.
• Il choisit donc le type de carte avec laquelle il va payer.
• Il saisit son numéro de compte, le code confidentiel de 4 chiffres ainsi que le mois et l’année de la date d’expiration de carte.
• Il valide son paiement, et le compte est débité automatiquement.

Postconditions de paiement en ligne:

• Commande payée et le compte de la société est crédité.
• Mise à jour de la base de données.

Figure23. Diagramme d’activité du cas d’utilisation « Paiement en ligne ».

1.3.15. Cas d’utilisation: « Facturation»

Acteurs de facturation:

• Clients, commercial.

Précondition de facturation:

• Paiement effectué sur commande.

Scénario nominal de facturation:

1. Réception de la facture

• Après avoir effectué le paiement, le client est livré et reçoit un e‐mail.
• Il trouve le lien qui conduit vers une page contenant sa facture.
• Il sélectionne le lien et ouvre la page de la facture.

Postconditions de facturation:

• Transaction terminée.
• Mise à jour de la base de données.

1.3.16. Cas d’utilisation: « Statistiques»

Acteurs:

• Administrateur.

Précondition:

• L’acteur doit s’authentifié.

Scénario nominal :

1. Les statistiques de la boutique

• L’acteur choisit de consulter les statistiques relatives à sa boutique.
• Le système lui affiche toutes les statistiques concernant la plateforme.
• Il peut ne choisir qu’un type de statistiques.

Postconditions :

• Statistiques consultées.

1.4. Organisation des cas d’utilisation

Nous allons maintenant organiser nos cas d’utilisation en paquetages de manière à ce qu’on puisse regrouper les cas qui ont le plus de relations entre eux à savoir:

1.4.1. Le package « administration »

• Identification.
• Suivi des rôles.
• Suivi des utilisateurs.
• Statistiques.

1.4.2. Le package « achat en ligne »

• Suivi des clients.
• Panier.
• Commandes.
• Recherche.

1.4.3. Le package « gestion de paiement en ligne »

• Paiement en ligne.
• Facturation.

1.4.4. Le package « gestion commerciale »

• Gestion des catégories.
• Gestion des marques.
• Gestion des produits.
• Suivi des fournisseurs.
• Suivi du stock.
• Marketing.

1.5. Utilisation de PowerAMC

L’utilisation de l’outil dans cette partie nous a servi à modéliser les cas d’utilisation par des diagrammes d’activités pour ensuite les regrouper dans les packages vus précédemment.

Afin de profiter de la puissance de l’outil et éliminer les redondances, nous avons adopté une démarche qui consiste à organiser les acteurs, cas d’utilisation, activité, classes…etc. en packages et par type de diagrammes.

En vue métier, les acteurs, cas d’utilisation et les activités ont été stéréotypéspuis regroupés dans des sous‐packages selon leurs stéréotypes.

1.6. Identification des classes candidates

Figure24. Diagramme de classes candidates.