Capture des besoins fonctionnels
From All4Dev
Contents |
Objectifs
- identifier les cas d'utilisation du système par ses acteurs
- décrire les cas d'utilisation
- organiser les cas d'utilisation
- identifier les classes candidates du modèles d'analyse
Quand?
- après l'étude préliminaire
- en parallèle à la capture des besoins techniques
- avant l'analyse (branche fonctionnelle)
Élements mis en jeu
- messages, acteurs, modèles de contexte dynamique
- acteurs principal, acteur secondaire
- cas d'utilisation, description préliminaire d'un cas d'utilisation,
- diagramme de cas d'utilisation,
- fiche de description textuelle d'un cas d'utilisation,
- scénario, enchainement, digramme d'activités
- inclusion, extension et généralisation des cas d'utilisation
- package de cas d'utilisation,
- classes candidates, responsabilités, diagramme de classes participantes,
- traçabilité des cas d'utilisation, avec les besoins fonctionnels, incrément.
Cas d'utilisation
Définition
Un cas d'utilisation représente:
- un ensemble des séquences d'actions
- réalisés par le système
- produisant un résultat intéressant, une valeur ajoutée «notable», pour un acteur particulier.
Un cas d'utilisation modèlise:
- un service rendu par le système.
- sans spécifier comment
L'ensemble des cas d'utilisation doivent:
- décrire exhaustivement les exigences fonctionnelles,
Chaque cas d'utilisation:
- correspond à une fonction métier du système
- selon le point de vue d'un de ses acteurs
Méthode
Pour chaque acteur identifié durant l'étude préliminaire, en utilisant les messages identifiés:
- rechercher les différentes intentions métier avec lesquelles il utilise le système
- déterminer dans le cahier des charges les services fonctionnels attendus du système
Pour chaque cas d'utilisation candidat:
- vérifier qu'il fournit une valeur ajoutée «notable», dans le cadre de son métier,
- contrôler qu'un évènement externe au système en déclenche l'exécution.
distinguer acteur principal et acteur secondaire
- l'acteur principal est
- celui pour qui le cas d'utilisation produit la plus value métier;
- généralement, c'est lui qui déclenche, le cas d'utilisation.
- acteurs secondaires sont les autres participants du cas d'utilisation
- sollicités pour des informations complémentaires
- consultent ou surveillent le système
Établir une première description succinte de chaque cas d'utilisation candidat
- intention de l'acteur
- actions qu'il effectue
Diagramme d'utilisation: détailler les rôle (pincipa ou secondaire) et les sens des associations
- par défaut le rôle de l'acteur est principal. Sinon indiquer explicitement que c'est secondaire sur son association;
- si un acteur a pour rôle unique de consommerles informations du système, sans en modifier l'état point de vue niveau métier, représentez une flèche vers l'acteur, sur son association.
Éviter la prolifération des cas d'utilisation
- un cas d'utilisation décrit plusieurs scénarios
- se resteindre à une vingtaine de cas
Pièges
un cas d'utilisation n'est ni une transaction, ni une fonction: ne pas descendre trop bas en terme de granularité. Un cas d'utilisation ne doit pas se réduire à une seule séquence ou à une simple action.
ne pas mélanger IHM et cas d'utilisation: les cas d'utilisation doivent être indépendants des interfaces et des moyens techniques. Ils visent une description métier.
ne pas faire de décomposition fonctionnelle:
- nature fonctionnelle des cas d'utilisation,
- difficulté de savoir à quel niveau de détail s'arrêter.
Décrire les cas d'utilisation
Conseils
Utilisez le style de description adapté
- description des cas d'utilisation pour le client
- description des cas d'utilisation pour le programmeur
Fiches de description des cas d'utilisation:
- Sommaire d'identification
- titre
- but
- résumé
- date
- version
- responsable
- acteurs
- Description des enchainements
- enchainements nominaux
- enchainements alternatif
- exception
- préconditions
- postconditions
- Besoins IHM (optionnel)
- contrainte interface homme-machine
- Contraintes non fonctionnelles (optionnel)
- fréquences
- volumétrie
- disponibilité
- fiabilité
- intégrité
- confidentialité
- performance
- concurrence
Complétez les descriptions textuelles avec des diagrammes dynamiques simples
- Pour les cas d'utilisations
- diagramme d'activités, pour les activités qui se déroulent en parallèle
- diagramme d'états, pour modéliser les déroulements évenementiels
- Scénarios particuliers
- diagramme de séquence
- diagramme de collaboration
Organiser les cas d'utilisation
- ajouter des relations entre cas d'utilisation:
- d'inclusions
- d'extensions
- de généralisation/spécialisation
- regrouper les cas d'utilisation en Package
Relation «include» entre cas d'utilisation:
- Le cas de base incorpore explicitement un autre cas.
- Le cas inclus n'est jamais exécuté seul, mais uniquement en tant que partie
- Cette relation est utilisée pour factoriser un comportement commun présent dans plusieurs cas d'utilisation
- Exemple: l'authentification
Relation «extend» entre cas d'utilisation:
- Le cas de base incorpore un autre cas, à un endroit spécifié.
- Le cas de base peut fonctionner tout seul, ou être aussi complété par un autre.
- Utilisé pour séparer le comportement optionnel.
Relation de généralisation:
- Les cas d'utilisation peuvent être hiérarchisés par généralisation/spécialisation.
- Les cas d'utilisation enfant héritent de certains comportement de leur parent.
Conseils
- On peut généraliser aussi les acteurs
- Regroupement des cas d'utilisation par:
- domaine d'expertise
- acteur (si chaque cas d'utilisation ne fait pas intervenir plusieurs acteurs)
- lot de livraison
Définition
- Un package UML est un espace de nommage qui peut contenir:
- des éléments d'un modèle
- des diagrammes qui représentent les éléments du modèle
- d'autres packages
- Dans un package, on trouve des éléments qui:
- représentent un ensemble fortement cohérent
- sont généralement de même nature et de même niveau sémantique.
Identifier les classes candidates
Conseils
Deux objectifs (par Jacobson):
- dialoque avec le client sur son expression préliminaire de besoins grâce à une description fonctionnelle,
- préparer la modèlisation orientée objet.
Nous entrons maintenant dans la deuxième étape:
- Mettre à jour les principales abstractions du système sous forme d'objets et de classes,
- tout en dialoguant avec le client,
- pour obtenir un concensus sur les concepts clés
- Les premières classes identifiés dans cette classe doivent être des concepts connus des utilisateurs du sytème: les objets métiers.
- L'analystes doit ensuite identifier les concepts «applicatifs» liés à l'informatisation (ex: Transmissions comptable, Profil utilisateur, etc.)
Pour chaque objet, vérifier ses propriété:
- identité,
- propriété,
- comportement,
Puis définir ses responsabilités
Définition
Une responsabilité est un contrat, une obligation pour une classe. Les propriétés d'une classe (attributs, opérations, association) lui permettent de remplir ses responsabilités.
- Chaque classe doit avoir au moins une responsabilité
- mais elle doit en avoir un nombre limité: inférieur à 5.
Méthodologie
Pour chaque cas d'utilisation représenter dans un diagramme statique les classes et les associations qui interviennent. Nous crééerons ainsi les «diagrammes de classes participantes». La réunion de ces diagrammes constituent le squelette du modèle statique d'analyse.
Valider et consolider
La validation inclut une phase de présentation au futurs utilisateurs, qui devront répondre aux questions suivantes:
- les frontières du système sont-elles bien définies?
- les acteurs sont-ils tous pris en compte (au moins une fois)?
- chaque d'utilisation a-t-il un processus de déclenchement?
- le niveau d'abstraction des cas d'utilisation est-il homogène?
- toutes les fonctionnalités du ssytème sont-elles traitées?
Méthodologie
Traçabilité des cas d'utilisation avec l'expression des besoins
- ligne: cas d'utilisation avec découpage par scénario
- colone: liste des exigences
Utilisation des Cas d'Utilisation pour définir les incréments
- identifier les cas d'utilisation les plus critques en terme de risque
- le client doit affecter une priorité fonctionnelle à chaque cas
- le chef de projet doit alors établir une priorité générale
- prendre en compte les dépendances entre cas d'utilisation
- développer plutôt les cas factorisés (<<include>>)
- développer plutôt les cas qui étendent (<<extend>>)
Conclusion
Cette phase a pour objectif de
- compléter le recueil initial des besoins effectués pendant l'étude préliminaire (utilisation des cas d'utilisation de la notation UML).
- préparé l'analyse orienté objet: identification des classes candidates du modèle statique d'analyse.
- Identifier les cas d'utilisation
Utilisation de:- Cahier des charges
pour produire - Fiches de description
- Diagrammes dynamiques
- Cahier des charges
- Décrire les cas d'utilisation
Production de:- Fiches de description
- Diagramme dynamique
- Organiser les cas d'utilisation
Production de:- Package de spécification fonctionnelle
- Identifier les classes candidates
Production de:- Diagrammes de classes
- Valider et consolider
Production de:- Diagrammes de cas d'utilisation raffinés
- Traçabilité
