Une description de cas d’utilisation explique comment un acteur atteint un objectif en interagissant avec un système. Elle complète un diagramme de cas d’utilisation :

• Diagramme de cas d’utilisation : Montre les acteurs, la portée du système et les relations.

• Description de cas d’utilisation : Explique le comportement détaillé, les conditions, les règles et les résultats.

Un diagramme fournit la carte ; la description fournit l’itinéraire.

1. Qu’est-ce qu’un cas d’utilisation ?

Un cas d’utilisation représente un objectif précieux qu’un acteur externe réalise grâce à un système.

Exemples :

• Le client passe une commande

• L’employé dépose une demande de remboursement de frais

• Le patient prend rendez-vous

• L’administrateur crée un compte utilisateur

• Le client réinitialise un mot de passe

Un bon cas d’utilisation est :

• Orienté vers un objectif

• Précieux pour un acteur

• Décrit du point de vue de l’utilisateur

• Indépendant des mises en page d’écran spécifiques

• Centré sur le comportement observable du système

Noms de cas d’utilisation médiocres et améliorés

Utilisez une courte phrase verbe–nom telle que “Soumettre une demande de remboursement de frais, Suivre l’expédition, ou Approuver une demande de prêt.

2. Concepts clés

2.1 Acteurs

Un acteur est un rôle externe qui interagit avec le système.

Un acteur peut être :

• Une personne

• Une organisation

• Un autre système logiciel

• Un dispositif matériel

• Un déclencheur programmé ou basé sur le temps

Exemples :

• Client

• Agent de support

• Employé d’entrepôt

• Passerelle de paiement

• Service d’envoi d’e-mails

• Administrateur

Un acteur est un rôle, pas nécessairement un individu spécifique. Par exemple, « Client » est généralement préférable à « Jane Smith ».

Acteurs principaux et acteurs de soutien

L’« acteur principal» initie le cas d’utilisation pour atteindre un objectif.

L’« acteur de soutien» assiste le système pendant l’exécution.

Exemple :

• Acteur principal : Client

• Acteur de soutien : Passerelle de paiement

• Cas d’utilisation : Passer une commande

Le client initie la commande, tandis que la passerelle de paiement autorise le paiement.

2.2 Limite du système

La limite du système définit ce qui se trouve à l’intérieur du système modélisé.

Pour une boutique en ligne, la limite peut inclure :

• Parcourir les produits

• Ajouter un produit au panier

• Passer une commande

• Effectuer un paiement

• Suivre une commande

Les éléments suivants sont en dehors de la limite :

• Client

• Passerelle de paiement

• Société de livraison

• Fournisseur d’e-mail

La limite évite toute confusion quant à la responsabilité du système.

2.3 Cas d’utilisation

Un cas d’utilisation doit décrire une interaction complète qui produit un résultat significatif.

Par exemple :

Passer une commande :Un client sélectionne des produits, fournit les informations de livraison, paie la commande et reçoit une confirmation de commande.

« Valider le numéro de carte de crédit » peut être une fonction du système, mais elle est généralement trop petite pour être un objectif utilisateur autonome. Elle peut plutôt faire partie de Passer une commande ou Effectuer un paiement.

2.4 Préconditions

Une précondition indique ce qui doit déjà être vrai avant le début du cas d’utilisation.

Exemples :

• Le client dispose d’un compte actif.

• Le produit est disponible à la vente.

• L’employé est authentifié.

• Le créneau de rendez-vous existe.

• Le panier d’achat contient au moins un article.

Une précondition n’est pas une action effectuée par le cas d’utilisation.

Mauvaise précondition :

Le client se connecte.

Meilleure précondition :

Le client est authentifié.

2.5 Postconditions

Une postcondition indique ce qui est vrai après la fin du cas d’utilisation.

Exemples :

• La commande est enregistrée.

• Le paiement est autorisé.

• Un e-mail de confirmation est envoyé.

• La demande de remboursement a un statut soumis.

• Le compte utilisateur est marqué comme actif.

Les postconditions doivent décrire les résultats, pas les détails d’implémentation.

Mauvaise postcondition :

La commandes table est mise à jour.

Meilleure postcondition :

La commande est stockée et disponible pour l’exécution.

2.6 Scénario de succès principal

Le scénario de succès principal, également appelé le flux de base ou chemin heureux, décrit l’interaction normale réussie.

Chaque étape doit décrire :

1. Une interaction entre l’acteur et le système

2. Une réponse du système

3. Une action métier significative

Exemple :

1. Le client sélectionne des produits.

2. Le système affiche le panier actuel.

3. Le client saisit les informations de livraison.

4. Le système valide les informations de livraison.

5. Le client soumet la commande.

6. Le système demande une autorisation de paiement.

7. La passerelle de paiement autorise le paiement.

8. Le système enregistre la commande.

9. Le système affiche la confirmation de commande.

Évitez les détails spécifiques à l’interface, sauf s’ils sont essentiels à l’exigence.

Étape médiocre :

Le client clique sur le bouton bleu situé dans le coin inférieur droit.

Meilleure étape :

Le client soumet la commande.

2.7 Flux alternatifs

Un flux alternatif décrit une variation valide du scénario principal.

Exemples :

• Le client choisit le retrait en magasin au lieu de la livraison.

• Le client paie avec un mode de paiement enregistré.

• L’administrateur approuve une réclamation avec des conditions.

• L’utilisateur s’authentifie à l’aide d’un code à usage unique.

Les flux alternatifs peuvent se rejoindre au flux principal.

Exemple :

A1. Le client utilise un mode de paiement enregistré
À l’étape 6, le client sélectionne un mode de paiement enregistré. Le système demande une autorisation en utilisant ce mode, puis reprend à l’étape 7.

2.8 Flux d’exception

Un flux d’exception décrit une condition non réussie ou anormale.

Exemples :

• Le paiement est refusé.

• Le produit est en rupture de stock.

• L’authentification échoue.

• Le service externe est indisponible.

• Les données requises sont invalides.

Un flux d’exception doit expliquer :

• Où le problème se produit

• Ce que fait le système

• Ce que l’acteur voit

• Si le cas d’utilisation se termine ou reprend

Exemple :

E1. Le paiement est refusé
À l’étape 7, la passerelle de paiement rejette la transaction. Le système affiche la raison, marque la commande comme impayée et permet au client de sélectionner un autre mode de paiement.

2.9 Relations d’inclusion et d’extension

inclure

Utiliser inclure lorsqu’un cas d’utilisation invoque toujours un autre comportement réutilisable.

Exemple :

• Passer une commande inclut Calculer le total

• Passer une commande inclut Authentifier le client

• Retirer de l’argent inclut Vérifier le code confidentiel

Le comportement inclus est obligatoire.

Passer une commande <<inclure>> Calculer le total

étendre

Utiliser étendre lorsqu’un comportement optionnel ou conditionnel complète un cas d’utilisation de base.

Exemple :

• Passer une commande peut être étendu par Appliquer un code de réduction

• Le paiement peut être étendu par Ajouter un message de cadeau

Le comportement d’extension n’est pas toujours exécuté.

Appliquer un code de réduction <<étendre>> Passer une commande

Une règle utile :

• Inclure : « Cela se produit toujours dans le cadre du cas d’utilisation. »

• Étendre : « Cela peut se produire dans certaines conditions. »

Ne pas utiliser inclure et étendre simplement pour diviser chaque flux en petits morceaux. Une décomposition excessive rend le modèle difficile à comprendre.

2.10 Généralisation

La généralisation représente l’héritage entre les acteurs ou les cas d’utilisation.

Exemple :

• L’employé est un acteur général.

• Le gestionnaire est un acteur spécialisé qui hérite du comportement de l’employé.

Manager --|> Employé

Utilisez la généralisation lorsque l’élément spécialisé est véritablement un type de l’élément généralisé, et non simplement parce que deux éléments partagent quelques étapes.

3. Modèle standard de description de cas d’utilisation

Le modèle suivant fonctionne bien pour les documents d’exigences, les spécifications de projet et les modèles d’analyse.

Identifiant du cas d'utilisation :
Nom du cas d'utilisation :
Objectif :
Périmètre :
Niveau :
Acteur principal :
Acteurs de soutien :
Parties prenantes et intérêts :

Déclencheur :

Préconditions :

Garanties minimales :

Garanties de succès :

Scénario principal de succès :
1.
2.
3.

Flux alternatifs :
A1.
A2.

Flux d'exception :
E1.
E2.

Exigences spéciales :
- Performance
- Sécurité
- Utilisabilité
- Disponibilité
- Conformité

Règles métier :

Exigences relatives aux données :

Fréquence et volume :

Hypothèses :

Questions ouvertes :

Cas d'utilisation liés :

Explication des champs

4. Exemple : Passer une commande

UC-001 — Passer une commande

Objectif :
Permettre à un client d’acheter un ou plusieurs produits.

Périmètre :
Boutique en ligne

Niveau :
Objectif de l’utilisateur

Acteur principal :
Client

Acteurs secondaires :

• Passerelle de paiement

• Service d’inventaire

• Service d’envoi d’e-mails

• Service de livraison

Parties prenantes et intérêts :

• Client : Veut acheter des produits avec succès et recevoir une confirmation.

• Boutique : Veut enregistrer une commande valide et encaisser le paiement.

• Entrepôt : A besoin d’informations précises sur l’exécution.

• Passerelle de paiement : A besoin d’une demande de paiement valide.

• Service de livraison : A besoin d’une adresse de livraison complète.

Déclencheur :
Le client soumet son panier pour le paiement.

Préconditions :

• Le client a au moins un article dans son panier.

• Les produits sont disponibles à la commande.

• Le client fournit une adresse de livraison valide.

• Le système peut communiquer avec le service de paiement.

Garanties minimales :

• Aucune commande impayée n’est traitée comme confirmée.

• Le client est informé si la commande ne peut pas être complétée.

• L’inventaire réservé est libéré si le paiement échoue.

Garanties de succès :

• Le paiement est autorisé.

• La commande est enregistrée.

• Les stocks sont réservés.

• Le client reçoit une confirmation.

• Les informations d’exécution sont mises à disposition de l’entrepôt.

Scénario de succès principal

1. Le client consulte le panier.

2. Le système affiche les produits, les quantités, les prix, les taxes, les frais de livraison et le total.

3. Le client fournit les informations de livraison.

4. Le système valide les informations de livraison.

5. Le client sélectionne un mode de paiement.

6. Le client soumet la commande.

7. Le système vérifie la disponibilité des produits.

8. Le système demande une autorisation de paiement à la passerelle de paiement.

9. La passerelle de paiement autorise le paiement.

10. Le système crée la commande.

11. Le système réserve les produits commandés.

12. Le système envoie une confirmation de commande au client.

13. Le système affiche le numéro de commande et la date estimée de livraison.

Flux alternatifs

A1. Le client utilise une adresse enregistrée

À l’étape 3, le client sélectionne une adresse précédemment enregistrée. Le système affiche l’adresse et passe à l’étape 4.

A2. Le client utilise un mode de paiement enregistré

À l’étape 5, le client sélectionne un mode de paiement enregistré. Le système utilise ce mode et passe à l’étape 6.

A3. Le client choisit le retrait en magasin

À l’étape 3, le client choisit le retrait en magasin au lieu de la livraison. Le système affiche les magasins disponibles et les dates de retrait, puis passe à l’étape 5.

Flux d’exception

E1. Produit indisponible

À l’étape 7, le système détermine qu’un produit est indisponible. Le système identifie le produit indisponible, met à jour le panier et demande au client de revoir la commande.

E2. Le paiement est refusé

À l’étape 9, la passerelle de paiement refuse le paiement. Le système ne confirme pas la commande, libère les réserves d’inventaire, affiche le message d’échec et permet au client de sélectionner un autre mode de paiement.

E3. La passerelle de paiement est indisponible

À l’étape 8, la passerelle de paiement ne répond pas dans le délai d’attente configuré. Le système marque la tentative de paiement comme en attente, informe le client et empêche la soumission de commandes en double.

Règles métier

• Une commande doit contenir au moins un produit.

• La quantité du produit doit être supérieure à zéro.

• Un produit ne peut pas être commandé lorsque le stock disponible est insuffisant.

• Le paiement doit être autorisé avant que la commande ne soit confirmée.

• Les prix et les taxes sont calculés en utilisant les règles de tarification en vigueur.

• Un client peut annuler une commande uniquement avant le début de l’exécution.

Exigences particulières

• Le récapitulatif de la commande doit s’afficher en moins de deux secondes dans des conditions de charge normales.

• Les informations de paiement ne doivent pas être stockées en texte clair.

• Les soumissions en double ne doivent pas créer de commandes en double.

• Le système doit enregistrer une piste d’audit pour les modifications de paiement et de statut de commande.

5. Niveaux de cas d’utilisation

Les descriptions des cas d’utilisation peuvent être rédigées à différents niveaux de détail.

Cas d’utilisation de niveau résumé

Un cas d’utilisation de niveau résumé décrit un processus métier global.

Exemple :

Exécution de la commande client

Cela peut inclure :

• Réception de la commande

• Préparation des produits

• Emballage de la commande

• Expédition de la commande

Cas d’utilisation de niveau objectif utilisateur

C’est généralement le niveau le plus utile pour l’analyse des exigences.

Exemple :

Passer une commande

Il décrit un objectif qu’un acteur principal peut atteindre en une seule séance.

Cas d’utilisation de niveau sous-fonction

Cela décrit un comportement système plus petit et réutilisable.

Exemples :

• Calculer le total de la commande

• Valider le paiement

• Générer la facture

Les cas d’utilisation de niveau sous-fonction sont utiles lorsque le comportement est réutilisé ou techniquement complexe, mais ils ne doivent pas remplacer les cas d’utilisation axés sur l’objectif de l’utilisateur.

6. Rédiger des descriptions de cas d’utilisation de haute qualité

Utiliser un langage centré sur l’acteur

Écrire du point de vue de l’acteur :

Le client soumet une commande.

Éviter un langage centré sur l’implémentation :

OrderController invoque le service de commande.

Ce dernier appartient à la documentation de conception, pas à un cas d’utilisation métier.

Gardez chaque étape atomique

Évitez de combiner trop d’actions :

Le client saisit les détails, sélectionne le mode de paiement, confirme la commande et reçoit un e-mail.

Améliorez-le en séparant l’interaction :

1. Le client saisit les informations de livraison.

2. Le système valide les informations.

3. Le client sélectionne un mode de paiement.

4. Le client confirme la commande.

5. Le système envoie une confirmation.

Décrivez un comportement observable

Un lecteur devrait pouvoir déterminer si la exigence a été implémentée.

Faible :

Le système traite la demande.

Plus fort :

Le système valide la demande, enregistre la réclamation, lui attribue un numéro de réclamation et affiche le statut de soumission.

Évitez un design d’interface utilisateur prématuré

Utilisez :

Le client fournit les informations de livraison.

Plutôt que :

Le client saisit l’adresse dans la zone de texte et clique sur le bouton vert Continuer.

La deuxième version contraint inutilement l’interface.

Gardez le flux principal réussi

Ne remplissez pas le flux de base avec tous les erreurs possibles. Placez les erreurs dans les flux d’exception.

Identifiez les règles métier séparément

Les règles métier s’appliquent souvent à plusieurs cas d’utilisation. Les garder séparés évite des textes répétés et incohérents.

Rendez le comportement d’échec explicite

Pour chaque échec important, spécifiez :

• Si les données sont sauvegardées

• Si une transaction est annulée

• Si l’acteur peut réessayer

• Si un administrateur est notifié

• Si le cas d’utilisation se termine ou reprend

7. Des exigences aux cas d’utilisation

Un flux de travail pratique est :

1. Identifiez le système modélisé.

2. Listez les acteurs externes.

3. Demandez ce que chaque acteur souhaite accomplir.

4. Convertissez chaque objectif en un nom de cas d’utilisation.

5. Définissez la limite du système.

6. Rédigez le scénario de succès principal.

7. Ajoutez les flux alternatifs et d’exception.

8. Ajoutez les règles métier et les exigences spéciales.

9. Dessinez le diagramme de cas d’utilisation.

10. Examinez le modèle avec les parties prenantes.

11. Reliez les cas d’utilisation aux exigences, aux tests et aux artefacts de conception.

Analyse acteur-objectif

Une question utile est :

Quel résultat métier cet acteur attend-il du système ?

8. Notation du diagramme de cas d’utilisation

Les éléments les plus courants sont :

• Acteur :Rôle externe

• Cas d’utilisation :Capacité du système ou objectif de l’acteur

• Limite du système :Périmètre du système

• Association :L’acteur participe à un cas d’utilisation

• Inclure :Comportement réutilisé requis

• Étendre :Comportement optionnel ou conditionnel

• Généralisation :Acteur ou cas d’utilisation spécialisé

Un diagramme de cas d’utilisation ne doit pas tenter de montrer :

• Chaque étape du flux de travail

• Tables de base de données

• Attributs de classe

• Règles métier détaillées

• Dispositions d’écran

• Algorithmes internes

Ces éléments appartiennent aux diagrammes d’activité, aux diagrammes de classes, aux diagrammes de séquence ou aux exigences écrites.

9. Exemple de diagramme PlantUML

L’exemple suivant modélise le Passer une commandecas d’utilisation et le comportement associé.

@startuml
direction left to right

skinparam packageStyle rectangle
skinparam shadowing false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

actor Client
actor "Passerelle de paiement" as Paiement
actor "Service d'inventaire" as Inventaire
actor "Service d'envoi d'e-mails" as Email
actor "Service de livraison" as Livraison

rectangle "Boutique en ligne" {
    usecase "Parcourir les produits" as Parcourir
    usecase "Gérer le panier" as Panier
    usecase "Passer une commande" as Commander
    usecase "Calculer le total de la commande" as CalculerTotal
    usecase "Vérifier la disponibilité des produits" as VerifierStock
    usecase "Autoriser le paiement" as AutoriserPaiement
    usecase "Réserver l'inventaire" as ReserverInventaire
    usecase "Envoyer une confirmation de commande" as EnvoyerConfirmation
    usecase "Suivre la commande" as SuivreCommande
    usecase "Appliquer un code de réduction" as AppliquerRemise
}

Client --> Parcourir
Client --> Panier
Client --> Commander
Client --> SuivreCommande

Paiement --> AutoriserPaiement
Inventaire --> VerifierStock
Inventaire --> ReserverInventaire
Email --> EnvoyerConfirmation
Livraison --> SuivreCommande

Commander ..> CalculerTotal : <<include>>
Commander ..> VerifierStock : <<include>>
Commander ..> AutoriserPaiement : <<include>>
Commander ..> ReserverInventaire : <<include>>
Commander ..> EnvoyerConfirmation : <<include>>

AppliquerRemise ..> Commander : <<extend>>

@enduml

Interprétation

• Le Client initie Passer une commande.

• Passer une commande inclut toujours le calcul, la vérification des stocks, l’autorisation de paiement, la réservation d’inventaire et la confirmation.

• Appliquer un code de réduction est facultatif, donc il étend Passer une commande.

• Les services externes participent à des comportements système spécifiques.

• La limite du système est le Boutique en ligne rectangle.

L’emplacement exact des éléments est contrôlé par le moteur de rendu. Les décisions de modélisation importantes sont les acteurs, les cas d’utilisation, les limites et les relations.

10. Création du diagramme dans Visual Paradigm VPasCode

VPasCode est une plateforme de conversion de texte en diagramme basée sur le navigateur qui prend en charge PlantUML, Mermaid, Graphviz et d’autres formats de diagrammes. Elle offre l’édition de code source et un rendu en direct, permettant au diagramme de se mettre à jour à mesure que le code change.

Flux de travail de base

1. Ouvrez l’éditeur VPasCode.

2. Créez un nouveau diagramme PlantUML.

3. Collez la source PlantUML.

4. Vérifiez que l’éditeur reconnaît la syntaxe PlantUML.

5. Examinez l’aperçu en direct.

6. Modifiez les acteurs, les cas d’utilisation, les relations et le style dans le volet de source.

7. Exportez ou copiez le diagramme rendu.

8. Ajoutez le diagramme à la documentation du projet.

VPasCode prend en charge les diagrammes de cas d’utilisation PlantUML et offre un rendu en temps réel dans le navigateur. Il fournit également des exemples et des options de style pour les diagrammes PlantUML.

Exemple d’invite pour une génération assistée par IA

Si vous utilisez une fonctionnalité de génération de diagrammes par IA, une invite utile est :

Créez un diagramme de cas d'utilisation PlantUML pour une boutique en ligne.

Acteur principal :
- Client

Acteurs secondaires :
- Passerelle de paiement
- Service d'inventaire
- Service d'e-mail
- Service de livraison

Cas d'utilisation principaux :
- Parcourir les produits
- Gérer le panier
- Passer une commande
- Suivre la commande

Passer une commande doit inclure :
- Calculer le total de la commande
- Vérifier la disponibilité des produits
- Autoriser le paiement
- Réserver l'inventaire
- Envoyer une confirmation de commande

Appliquer un code de réduction doit étendre Passer une commande.

Utilisez une limite de système nommée Boutique en ligne.

Traitez le code généré comme un point de départ. Vérifiez si :

• Les acteurs sont véritablement externes

• Les cas d’utilisation représentent les objectifs des utilisateurs

• inclure et étendre sont utilisés correctement

• La limite du système est précise

• Les relations reflètent le comportement réel des affaires

VPasCode prend également en charge la transition entre l’édition de diagrammes basée sur du texte et les outils de modélisation graphique de Visual Paradigm, ce qui peut être utile lorsque les équipes souhaitent une édition basée sur le code source pour la gestion des versions et une édition visuelle pour l’affinement de la mise en page.

11. Maintenance des diagrammes de cas d’utilisation PlantUML

Utilisez des alias significatifs

Les alias facilitent la maintenance des relations :

usecase "Passer une commande" as PlaceOrder
Client --> PlaceOrder

Ajouter des commentaires

' Transaction client principale
usecase "Passer une commande" as PlaceOrder

Les commentaires aident les autres membres de l’équipe à comprendre la source et à maintenir le diagramme.

Gardez le diagramme centré

Si un diagramme contient trop de cas d’utilisation :

• Créez un diagramme de contexte

• Créez des diagrammes séparés par domaine métier

• Utilisez des regroupements par paquet

• Lie les diagrammes connexes via la documentation

• Évitez d’afficher chaque sous-fonction au niveau le plus élevé

Utilisez une dénomination cohérente

Choisissez une convention et appliquez-la de manière cohérente :

• Passer une commande

• Annuler une commande

• Suivre une commande

Évitez de mélanger des styles tels que :

• Passer une commande

• AnnulationDeCommande

• fonction_suivi

Conservez la source avec le projet

Une structure de dépôt typique pourrait être :

docs/
  use-cases/
    UC-001-passer-une-commande.md
    UC-002-suivre-une-commande.md
  diagrams/
    cas-utilisation-boutique-en-ligne.puml

Conserver le .puml source sous contrôle de version rend les modifications révisables et reproductibles.

12. Traçabilité

Un processus d’exigences mature relie les cas d’utilisation aux autres artefacts du projet.

La traçabilité aide à répondre :

• Quelles exigences sont couvertes ?

• Quels cas d’utilisation n’ont pas été testés ?

• Quels composants de conception soutiennent un objectif métier ?

• Qu’est-ce qui est affecté si une exigence change ?

13. Erreurs courantes

Modéliser des composants internes en tant qu’acteurs

Une base de données ou un service interne n’est généralement pas un acteur s’il se trouve à l’intérieur des limites du système.

Un acteur doit être externe au système modélisé.

Traiter les écrans comme des cas d’utilisation

Un écran est un élément d’interface utilisateur, pas nécessairement un objectif utilisateur.

Utiliser :

Soumettre une demande de remboursement de frais

Au lieu de :

Écran de demande de remboursement de frais

Utiliser inclure pour chaque étape partagée

Une formulation partagée seule ne justifie pas un cas d’utilisation inclus. Utiliser inclure lorsque le comportement est obligatoire et significatif de manière indépendante.

Utiliser étendre pour les étapes normales

Si un comportement se produit toujours, il ne doit pas être modélisé comme une extension.

Rédiger des détails d’implémentation

Éviter les références à :

• Contrôleurs

• Tables de base de données

• Points de terminaison de l’API

• Classes

• Méthodes internes

sauf si le document est spécifiquement une conception technique.

Omission du comportement en cas d’échec

Un cas d’utilisation est incomplet s’il explique uniquement le succès. Le rejet de paiement, les données invalides, les délais d’attente, les échecs d’autorisation et les ressources indisponibles doivent être traités.

Rendre les cas d’utilisation trop larges

« Gérer l’entreprise dans son ensemble » n’est pas actionnable. Décomposez les objectifs larges en cas d’utilisation au niveau des objectifs utilisateur.

Rendre les cas d’utilisation trop petits

« Valider le champ » et « Afficher le message » sont généralement des étapes du système, et non des objectifs indépendants de l’acteur.

14. Liste de vérification

Avant d’approuver une description de cas d’utilisation, vérifiez :

Périmètre et acteurs

• La limite du système est-elle claire ?

• Tous les acteurs externes sont-ils identifiés ?

• Les acteurs sont-ils des rôles plutôt que des noms individuels ?

• Les systèmes de support sont-ils modélisés uniquement lorsqu’ils sont externes ?

Qualité de l’objectif

• Le cas d’utilisation apporte-t-il de la valeur à l’acteur principal ?

• Le nom est-il une phrase claire verbe–nom ?

• Le cas d’utilisation est-il à un niveau approprié ?

Qualité du flux

• Le scénario principal décrit-il un résultat réussi ?

• Chaque étape est-elle atomique et observable ?

• Les chemins alternatifs sont-ils documentés ?

• Les chemins d’exception sont-ils documentés ?

• Le comportement de récupération est-il clair ?

Conditions et résultats

• Les préconditions sont-elles testables ?

• Les garanties de succès sont-elles explicites ?

• Les garanties minimales sont-elles définies ?

• Les règles métier sont-elles séparées des étapes procédurales ?

Qualité du diagramme

• Tous les cas d’utilisation sont-ils à l’intérieur de la bonne limite ?

• Les associations d’acteurs sont-elles significatives ?

• Les inclusionsont-elles obligatoires ?

• Les extensionsont-elles optionnelles ou conditionnelles ?

• Le diagramme est-il lisible sans détails excessifs ?

Qualité des exigences

• Chaque étape importante peut-elle être testée ?

• Les exigences non fonctionnelles sont-elles incluses ?

• Les questions non résolues sont-elles enregistrées ?

• Le cas d’utilisation est-il lié aux exigences et aux cas de test ?

15. Structure recommandée des livrables

Pour un ensemble complet de projet, utilisez la structure suivante :

1. Contexte du système
2. Catalogue des acteurs
3. Diagramme de cas d'utilisation
4. Catalogue des cas d'utilisation
5. Descriptions détaillées des cas d'utilisation
6. Règles métier
7. Exigences non fonctionnelles
8. Matrice de traçabilité
9. Questions ouvertes et hypothèses
10. Fichiers source PlantUML

Une description solide de cas d’utilisation est suffisamment précise pour les analystes, compréhensible pour les parties prenantes et testable par une équipe d’assurance qualité. Le meilleur flux de travail consiste à utiliser la description écrite pour établir le comportement, le diagramme de cas d’utilisation pour communiquer la portée et les relations, et PlantUML dans VPasCode pour maintenir le modèle visuel facile à modifier et à maintenir.

Référence

Cette publication est également disponible en English : liste des langues séparées par une virgule, English : dernière langue.