Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

INTRODUCTION La capture des besoins fonctionnels est la première étape de la br

INTRODUCTION La capture des besoins fonctionnels est la première étape de la branche gauche du cycle en y. Elle formalise et détaille ce qui a été ébauche au cours de l’étude préliminaire. Un besoin fonctionnel spécifie une fonction que le système ou un composant du système doit accomplir et dépend donc de ce dernier (fonctionnalités du système). Dans notre projet, 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 et enfin la validation et la consolidation. I. CAS D’UTILISATION Définition Avant de faire l’identification des cas d’utilisation, il est nécessaire de définir ce que l’on entend par cas d’utilisation. En effet, un cas d’utilisation est une fonctionnalité qui sert à répondre aux questions <<pourquoi le système va être utilise, quel service va-t-il rendre>>. Il sert aussi à exprime le comportement du système en termes d’action et de réaction selon le point de vue de l’utilisateur. Cette fonctionnalité constitue un moyen de déterminer les besoins du système et doit pouvoir renvoyer un résultat observable qui est utile pour l’utilisateur du système. Autrement dit, le cas d’utilisation regroupe une famille de scenario ou chaque scenario est un traitement particulier du système. Type de cas d’utilisation On distingue plusieurs types de cas d’utilisation correspondant à diffèrent usages. - Le cas d’utilisation concret : c’est la forme la plus courante. Les scenarios en décrivent la séquence des interactions en détails, étape par étape, telles qu’elles sont vues par l’utilisateur. La conséquence est que l’enchainement des actions est alors pris comme un fait accompli, sans que l’ergonomie qui en résulte ne soit jamais remis en question. - Le cas d’utilisation paramétré regroupe plusieurs cas similaires.la description est alors générique et permet la prise en compte légères différences par le biais des paramètres - Le cas d’utilisation essentiel (<< essential use case >> en anglais) parfois appelé cas d’utilisation abstrait est une forme épurée qui ne se réfère qu’aux intentions de l’utilisateur et sans aucune idée préconçue sur la technique qui sera utilisée, la chronologie des interactions ou la mise en œuvre - Le cas d’utilisation métier (« business use case « en anglais) est un cas d’utilisation dans le cadre d’un modèle d’affaire. Le système considéré n’est alors pas un système informatique mais un processus métier ou une entreprise. Les cas d’utilisation du système informatique en seront déduits dans un deuxième temps. II. IDENTIFICATION DE CAS D’UTILISATION Il s’agit de décrire exhaustivement les exigences fonctionnelles du système. Par conséquent chaque cas d’utilisation correspond à une fonction métier du système. Aussi, pour identifier les cas d'utilisation, il faut se placer du point de vue de chaque acteur et déterminer comment et surtout pourquoi il se sert du système. Ainsi il faudra éviter les redondances et limiter le nombre de cas en se situant au bon niveau d’abstraction (par exemple ne pas réduire un cas à une action). Notons que les cas d’utilisation est représenté par une ellipse contenant le nom du cas (un verbe à l’infinitif), suivi d’un complément du point de vue de l’acteur (et non pas du point de vue du système) et optionnellement d’un stéréotype. <<Stéréotype>> Nom du cas Pour un exemple plus explicite on prendra le cas de notre marché en ligne. On peut avoir des cas d’utilisation comme ; Créer un compte Ajouter une boutique Enregistrer un achat Ajouter un produit S’authentifier Enregistrement d’information pour livraison Préparer une livraison Effectuer le paiement Consulter panier NB : Nous devons faire en sorte de ne pas descendre trop bas dans l’identification des cas et surtout ne pas se limiter à la seule transaction dans le sens de la manipulation informatique tels que (Ajouter, Supprimer, Modifier) III. IDENTIFICATION DES ACTEUR PRINCIPAUX ET DES ACTEUR SECONDAIRE Qui est un acteur ? En génie logiciel, et plus particulièrement en UML, un acteur est une entité intervenant dans un système informatique qui interagir avec le système échangeant de l’information (en entrée et en sortie). On trouve les acteurs en observant les utilisateurs directs du système. Nous en distinguons deux (2) type d’acteur qui sont les acteurs principaux et les acteurs secondaire. Les acteurs principaux L’acteur est dit « principal » pour un cas d’utilisation lorsque le cas d’utilisation rend service à cet acteur. C’est-à-dire lorsqu’il agit directement sur le système pour ce cas d’utilisation (la relation avec le cas d’utilisation est illustrée par le trait liant le cas d’utilisation et l’acteur dans un diagramme de cas d’utilisation). Un acteur principal obtient donc un résultat observable du système. Les acteurs secondaires Les autres acteurs sont dits « secondaires ». Un cas d’utilisation a au plus un acteur principal, et un ensemble ‘éventuellement vide’ d’acteurs secondaires. Un acteur secondaire est sollicité pour des informations complémentaires. C’est-à-dire il est nécessaire pour le bon fonctionnement du système mais n’est pas forcément celui pour qui le système est construit. Un acteur est généralement représenté à l’aide d’un bonhomme allumette au-dessus ou en dessous duquel est écrit son nom. Figure 1 : Symbole de représentation d’un cas d’utilisation Figure 2 : Représentation d'un acteur En considérant le projet du marché en ligne, nous pouvons recenser les acteurs suivants : - Comme acteurs principaux, nous avons les commerciaux, l’administrateur, les clients. - Comme acteurs secondaires nous avons les livreurs. Exemple pratique : Toujours basée sur notre plateforme de marche en ligne, le tableau ci- dessous liste les différents cas d’utilisation ainsi que les acteurs et les message émis et reçus. Cas d’utilisation Acteur principal Acteur secondaire Message émis et reçus Créer un compte Acheteur Commercial Emet : Demande de créer un compte Reçoit : Message de confirmation Ajouter une boutique Commercial Emet : Demande d’ajouter une boutique Enregistrer un achat Acheteur Commercial Emet : Liste des produits Reçoit : Facture Ajouter un produit Commercial Emet : Demande d’ajouter un produit S’authentifier Acheteur Commercial Emet : Demande d’authentification Enregistrement d’information pour livraison Acheteur Commercial Emet : Information saisir Reçoit : Message de validation Préparer une livraison Commercial Système Emet : Numéro et code de livraison Effectuer un paiement Acheteur Emet : Coordonnées du compte bancaire ou numéro de paiement mobile Reçoit : Message de confirmation Consulter le panier Acheteur Commercial Emet : Demande de consultation Reçoit : Liste des produit contenues dans son panier Consulter liste produits Acheteur Commercial Emet : Demande de liste ou un Catalogue Reçoit : listes des produits en vente Tableau 1 : Tableau des acteurs principaux et secondaire IV. DESCRIPTION DES CAS D’UTILISATION Comme nous l’avons vu précédemment un cas d’utilisation est une fonctionnalité du système qui produit un résultat observable pour un utilisateur potentiel du système. Durant cette étape, chaque cas d’utilisation sera décrit par l’intention but (le rôle du cas d’utilisation/ a quoi il sert) suivi de l’acteur dans l’exécution du cas d’utilisation et les actions élémentaires qu’il peut effectuer. Un nom ne suffit pas à comprendre le détail de ce que recouvre un cas d’utilisation. Il est donc nécessaire d’adjoindre à chaque cas d’utilisation une description détaillée. Il doit préciser quand ont lieu les interactions entre acteurs et système, et quels sont les messages échangés. Avantages et limites  Avantages Les cas d’utilisations sont efficaces pour le recueil des exigences sur la base des scenarios d’utilisation d’un système car ils se focalisent sur les interactions acteurs /système selon les choix de leurs utilisateurs. Ils permettent également de préparer les tests de recette basées sur l’utilisation du système.  Limites Selon certains auteurs, les cas d’utilisation ne peuvent à eux-seuls piloter les processus de développement car ils ne tiennent pas compte des règles métier transverses. Lorsque celles-ci peuvent être prise en compte et intégrées aux cas d’utilisation, elles risquent d’être masquées par les interactions entre les acteurs et le système. Les deux cas de figures peuvent alors causer des problèmes lorsque les règles de métier doivent être adaptées. Toutefois ces risque sont relativiser, car de nombreux modelés de description proposent d’identifier les règles métiers a part, et de faire explicitement référence à ces règles dans le cas d’utilisation lorsque c’est opportun. Ci-dessous nous allons donner le but des différents cas d’utilisation et les différentes actions qui peuvent être effectué sur ses cas d’utilisation. Noms des cas d’utilisation Buts Actions Authentification Autorise l’accès a certaine ressource sécurise. Accéder à des informations sur le site. Créer un compte D’entre les éléments qui Entrer des identifient propre a l’identité chaque personne pour adhère aux le système. la personne. Ajouter une boutique Entre sur la plateforme pour y-il ajouter une boutique. Confirme la création, supprimé la boutique, Modifier la boutique. uploads/Finance/ expose-si-in3.pdf