Comment rédiger des cas d'utilisation efficaces

Publié: 2015-08-21

Comment rédiger des cas d'utilisation efficaces

Les cas d'utilisation sont largement utilisés pour documenter la logique métier et les processus système. Mais il y a beaucoup d'opinions sur leur utilité et sur la manière dont elles devraient être structurées. Dans certains projets, les développeurs ne regardent jamais les cas d'utilisation en disant qu'ils sont verbeux ou qu'ils n'en comprennent vraiment pas grand-chose. Que peut faire un analyste métier pour rendre les cas d'utilisation vraiment efficaces ?

La plupart d'entre nous savent que les cas d'utilisation décrivent le processus métier et sont les spécifications des interactions entre le système et les acteurs pour des objectifs particuliers. Un document de cas d'utilisation est différent d'un document d'exigences et n'est pas identique à un document de conception.

Examinons les deux exemples de cas d'utilisation de l'exigence. Selon vous, lequel d'entre eux est le meilleur.

Exemple 1

Détails du cas d'utilisation commentaires

Nom du cas d'utilisation – Commander des tickets

Le nom est bon. Il donne clairement une indication de ce que le cas d'utilisation

Objectif – Le client réserve avec succès des billets pour le match de football sur le site Web

Description - L'acteur visite le site Web, visualise le
horaire, sélectionne le match
et sièges, réserve le
billet et effectue le paiement du match de football

L' objectif et la description sont clairement mentionnés.
Cela aidera les concepteurs
et les développeurs comprennent quel est le
objectif de leurs documents de conception et de leur code

Acteurs – Client, Représentant du service client
Conditions préalables – Le système est opérationnel.
Déclencheur - L'acteur a accédé au système pour réserver des billets.
Post-condition - L'acteur est en mesure de réserver des billets. Le système met à jour les informations.

Tous les autres détails de cas d'utilisation tels que les acteurs,
conditions préalables, post-conditions et
déclencheur sont mentionnés, ce qui aidera le
conception et développement de l'application plus facile.

Flux principal – Étapes

  1. L'acteur accède au site Web et sélectionne pour réserver des billets
  2. Le système affiche les informations de réservation
  3. L'acteur confirme les détails du match (Plus de détails dans la spécification de l'interface utilisateur)
  4. L'acteur confirme les détails du siège (plus de détails dans les spécifications de l'interface utilisateur)
  5. Le système confirme la disponibilité
  6. Le système présente un formulaire pour obtenir des informations sur l'utilisateur
  7. L'acteur donne des informations à l'utilisateur (Détails dans un autre cas d'utilisation)
  8. Le système présente un formulaire pour les informations de paiement
  9. L'acteur donne des informations de paiement (Détails dans un autre cas d'utilisation)
  10. Le système confirme les détails et donne un identifiant de réservation
  11. L'acteur enregistre le ticket
  12. L'acteur quitte le système.

Cas d'utilisation inclus

- Effectuer le paiement

– Générer un ID de réservation

Cas d'utilisation étendus

– Générer une note d'échec de paiement

– Billet imprimé

Les étapes du flux principal sont claires mais
Les détails de l'interface utilisateur sont omis. Détails de l'interface utilisateur dans le cas d'utilisation
concernant la sélection et la correspondance des sièges
la sélection peut compliquer le cas d'utilisation.
Le cas d'utilisation montre clairement ce que l'acteur doit faire et ce que le système fera
Le processus de paiement est détaillé dans un
différents cas d'utilisation afin que les tâches puissent être
facilement décomposé en différents composants de conception.
Les cas d'utilisation inclus et étendus sont nommés
pour que l'on puisse
les consulter pour plus de détails.

Flux alternatif

-annuler les billets

  1. L'acteur annule la transaction
  2. Le système annule la transaction

Flux d'exceptions

-Billets non disponibles pour le match sélectionné/sièges sélectionnés

1. Le système affiche un message d'erreur

Les flux alternatifs et exceptionnels sont détaillés.

* Le cas d'utilisation peut être plus détaillé en termes de références et de flux alternatifs et exceptionnels. Cet exemple vise à mettre en évidence ce qui devrait être inclus dans un cas d'utilisation bien écrit.

Exemple - 2

Détails du cas d'utilisation commentaires

Nom du cas d'utilisation - Commande de billets

Le nom n'est pas du point de vue de l'utilisateur et ressemble à une définition de processus métier.

Description - L'acteur visite le site Web, consulte le calendrier, sélectionne le match et les sièges, réserve le billet et effectue le paiement du match de football

L'objectif du cas d'utilisation est manquant. Les concepteurs, les analystes de test et les développeurs ne comprendront pas pourquoi cette fonctionnalité doit être développée.

Acteurs – Client, Représentant du service client
Déclencheur - L'acteur a accédé au système pour réserver des billets.
Post-condition - L'acteur est en mesure de réserver des billets. Le système met à jour les informations.

Les conditions préalables manquent.

Principales étapes du flux

  1. Le client accède au site Web et sélectionne l'option "Réserver des billets" pour réserver des billets
  2. Le système affiche la liste des correspondances dans une liste déroulante.
  3. Le représentant du service à la clientèle sélectionne dans la liste déroulante
  4. Le système affiche les détails des sièges dans une carte des sièges
  5. L'acteur sélectionne les sièges. Si les sièges ne sont pas disponibles et qu'un message d'erreur s'affiche.
  6. L'acteur donne les détails du paiement
  7. L'acteur réserve le billet sinon annule le billet.
  8. Le système génère un identifiant de réservation en utilisant le prénom du client et un numéro à 4 chiffres généré aléatoirement

Cas d'utilisation inclus
- Effectuer le paiement

Dans les étapes du cas d'utilisation, certaines références à des éléments d'interface utilisateur réels peuvent dérouter le lecteur. Les flux alternatifs sont écrits dans le flux principal, ce qui rend difficile la compréhension de l'ensemble du processus.
L'acteur est désigné par de nombreux noms - « client, acteur et représentant du service client, ce qui prête à confusion ».
La génération de l'identifiant de réservation est expliquée ici bien qu'elle ne concerne pas les acteurs liés à la commande de billets.
Il n'y a pas de flux alternatifs, de flux d'exception et aucune mention de tous les cas d'utilisation associés.

Ce cas d'utilisation manque de clarté et de détails et n'aidera pas l'équipe à développer correctement la fonctionnalité.

Ce qui devrait être dans un cas d'utilisation Ce qui ne devrait pas être dans un cas d'utilisation
  1. Nom
  2. Descriptif/Objectif
  3. Conditions préalables
  4. Gâchette
  5. Flux de base et flux alternatifs
  6. Scénarios d'exception
  7. Conditions de poste
  8. Exigences particulières le cas échéant
  9. Lien vers les détails de l'interface utilisateur et d'autres modèles/diagrammes associés
  1. Détails d'implémentation
  2. Traitement interne
  3. Prérogatives non fonctionnelles
  4. Les détails de l'interface utilisateur doivent être effectués simultanément avec les cas d'utilisation, mais dans un document séparé

.

Quelques conseils à suivre pour rédiger des use cases utiles :

  1. Rédigez les étapes du cas d'utilisation du point de vue de l'acteur.
  2. Les cas d'utilisation ne doivent pas comporter de détails de conception et d'architecture. Il doit se concentrer sur le processus métier.
  3. Il est préférable que les étapes du cas d'utilisation soient écrites de manière ordonnée dans le temps
  4. En fonction des exigences et de la complexité, décidez si les opérations CRUD (créer, lire, mettre à jour et supprimer) doivent être conservées dans des cas d'utilisation distincts ou si elles peuvent être combinées en un seul.
  5. Il est important de donner des références vers et depuis les flux alternatifs, les flux d'exception, les cas d'utilisation inclus et les cas d'utilisation étendus afin que la conception métier soit complète.
  6. Choisissez un modèle (défini par le projet, défini par l'entreprise ou tout modèle détaillé) et suivez la structure pour tous les cas d'utilisation.
  7. Il est important d'avoir des diagrammes de cas d'utilisation.
  8. En Agile, nous avons des histoires d'utilisateurs pour capturer les exigences. Les user stories peuvent être détaillées à l'aide de cas d'utilisation lean de manière itérative.
  9. Les validations doivent être détaillées.

Après avoir écrit un cas d'utilisation, posez ces questions et c'est un cas d'utilisation efficace si la réponse est "Oui" à toutes les questions -

  1. L'utilisateur saura-t-il quand le flux métier présent dans le cas d'utilisation sera exécuté ?
  2. Est-il clair qui effectuera quelle étape du cas d'utilisation ?
  3. La description de la logique métier est-elle telle qu'il y a suffisamment d'informations pour l'analyse, la conception, le développement et les tests ?
  4. Existe-t-il des références appropriées entre le flux principal et les flux alternatifs et exceptionnels ?
  5. Existe-t-il un diagramme de cas d'utilisation ?

Les cas d'utilisation sont un moyen efficace de saisir les exigences et de documenter formellement les processus métier s'ils sont bien rédigés. Toute l'équipe doit être entraînée à utiliser des cas d'utilisation pour effectuer ses tâches. Les cas d'utilisation et les diagrammes de cas d'utilisation sont un excellent moyen de discuter des processus métier avec les clients. Il est préférable d'avoir un modèle de cas d'utilisation standard avec des directives sur la rédaction des cas d'utilisation. Les cas d'utilisation écrits de cette manière seront appréciés par tous les membres de l'équipe du projet et les parties prenantes.