Piloter le développement logiciel réussi grâce à l’approche pilotée par les cas d’utilisation : modèles et exemples du monde réel

L’approche pilotée par les cas d’utilisation est une méthodologie qui se concentre sur la définition des exigences et fonctionnalités du système du point de vue de ses utilisateurs. Il s’agit d’une approche centrée sur l’utilisateur qui met l’accent sur l’identification des besoins, objectifs et comportements des utilisateurs afin de garantir que le système en cours de développement répondra à leurs attentes. Dans cette approche, les cas d’utilisation sont utilisés pour décrire le comportement du système en réponse aux interactions des utilisateurs. Les cas d’utilisation sont des scénarios qui décrivent comment le système est utilisé dans différentes situations.

Avantages

L’approche pilotée par les cas d’utilisation offre plusieurs avantages, notamment :

• Meilleure compréhension des besoins et exigences des utilisateurs
• Définition claire du comportement et des fonctionnalités du système
• Détection précoce des problèmes et conflits potentiels
• Amélioration de la communication entre les parties prenantes
• Répartition efficace des ressources et des efforts
• Priorisation efficace des fonctionnalités et des exigences

Un guide étape par étape pour le développement des cas d’utilisation

Voici un modèle de processus de développement de cas d’utilisation de haut niveau, réutilisable, que vous pouvez adapter et personnaliser selon les besoins de votre équipe :

1. Identifiez les parties prenantes et leurs exigences :Commencez par identifier toutes les parties prenantes impliquées dans le projet, puis recueillez leurs exigences. Cela peut inclure les utilisateurs finaux, les propriétaires d’entreprise et d’autres membres de l’équipe.
2. Priorisez les exigences :Une fois que vous disposez d’une liste d’exigences, priorisez-les en fonction de leur importance et de leur impact sur le projet. Cela vous aidera à vous concentrer d’abord sur les besoins les plus critiques.
3. Définissez le périmètre :Sur la base des exigences prioritaires, définissez le périmètre du projet. Cela inclut la définition des fonctionnalités et des caractéristiques que le projet comportera.
4. Créez les cas d’utilisation :Les cas d’utilisation sont des descriptions de la manière dont un utilisateur interagit avec le système pour atteindre un objectif spécifique. Créez des cas d’utilisation qui décrivent les différents scénarios dans lesquels le système sera utilisé.
5. Revoyez et affinez les cas d’utilisation :Revoyez les cas d’utilisation avec les parties prenantes et affinez-les en fonction de leurs retours. Cela peut impliquer l’ajout ou la suppression d’étapes, la mise à jour des exigences ou la clarification des détails.
6. Créez des user stories :Les user stories sont des descriptions brèves d’une fonctionnalité ou d’une caractéristique du point de vue de l’utilisateur final. Créez des user stories basés sur les cas d’utilisation que vous avez développés.
7. Estimez l’effort :Estimez l’effort nécessaire pour développer chaque user story. Cela vous aidera à planifier le calendrier du projet et l’allocation des ressources.
8. Priorisez les user stories :Priorisez les user stories en fonction de leur importance et de leur impact sur le projet.
9. Planifiez les sprints :Sur la base des user stories prioritaires, planifiez les sprints de développement. Chaque sprint doit inclure un ensemble de user stories pouvant être terminées dans le cadre du délai du sprint.
10. Réviser et affiner : Revue du progrès de chaque sprint et affinement des cas d’utilisation et des histoires d’utilisateur selon les besoins.
11. Tester et valider : Tester le système pour s’assurer qu’il répond aux exigences et valider qu’il répond aux besoins des parties prenantes.
12. Déployer et surveiller : Une fois le système testé et validé, le déployer en production et le surveiller en cas de problèmes ou de bogues.

Il s’agit simplement d’un modèle général que vous pouvez adapter selon les besoins spécifiques de votre équipe et les exigences du projet. Vous pouvez également utiliser des outils de gestion de projet agile tels que Jira ou Trello pour vous aider à gérer le processus et suivre les progrès.

Modèles de documents agiles pour l’approche des cas d’utilisation

Document d’analyse des parties prenantes

Voici un exemple de document d’analyse des parties prenantes pour la description du problème que vous avez fournie :

Document d’analyse des parties prenantes : Application bancaire mobile

Partie prenante	Rôle	Intérêts	Besoins
Clients	Utilisateurs finaux de l’application bancaire mobile	Expérience bancaire facile à utiliser, sécurisée et pratique	Capacité à consulter les soldes des comptes, effectuer des virements entre comptes et payer des factures via l’application mobile
Employés de la banque	Support client et gestion du système backend	Système backend efficace et sécurisé	Capacité à gérer de fortes volumes de transactions, facile à maintenir et à dépanner
Propriétaires d’entreprise	Parties prenantes souhaitant améliorer la satisfaction client et réduire les coûts	Satisfaction accrue des clients, réduction des coûts et suivi des indicateurs d’utilisation	Capacité à suivre l’utilisation par les clients, les niveaux de satisfaction et analyser les indicateurs d’utilisation afin d’améliorer l’application mobile

Ce document d’analyse des parties prenantes identifie les différentes parties prenantes impliquées dans le projet, leurs rôles, leurs intérêts et leurs besoins. Il fournit une image claire de ce que chaque partie prenante souhaite atteindre grâce au projet, ainsi que ses priorités. Ce document peut servir de point de référence tout au long du projet et peut être mis à jour lorsque de nouvelles parties prenantes sont identifiées ou lorsque les besoins des parties prenantes évoluent.

Modèle de collecte des exigences

Voici un exemple de modèle de collecte des exigences pour la description du problème que vous avez fournie :

Modèle de collecte de besoins : application bancaire mobile

Description de la demande	Niveau de priorité	Critères d’acceptation	Nom du partie prenante
Capacité à visualiser les soldes des comptes	Élevé	L’utilisateur doit pouvoir voir les soldes actuels de tous les comptes associés à son profil	Clients
Capacité à transférer de l’argent entre les comptes	Élevé	L’utilisateur doit pouvoir transférer de l’argent entre les comptes en utilisant l’application mobile	Clients
Capacité à payer les factures	Élevé	L’utilisateur doit pouvoir payer les factures via l’application mobile	Clients
Système backend efficace	Élevé	Le système backend doit être capable de gérer de fortes volumes de transactions et être facile à maintenir	Employés de la banque
Suivi des indicateurs d’utilisation	Moyen	L’application doit être capable de suivre les indicateurs d’utilisation et les niveaux de satisfaction des clients	Propriétaires d’entreprise

Ce modèle de collecte de besoins aide à recueillir les exigences des parties prenantes en définissant chaque exigence, son niveau de priorité, les critères d’acceptation et le nom de la partie prenante associée. Ce modèle peut être utilisé pour capturer les exigences lors d’entretiens, de sondages et de groupes de discussion avec les parties prenantes. Il garantit que toutes les exigences sont recueillies, prioritaires et alignées sur les intérêts et besoins des parties prenantes. Le modèle peut être mis à jour lorsque de nouvelles exigences sont identifiées ou lorsque les niveaux de priorité des exigences existantes changent.

Matrice de traçabilité des exigences

Voici un exemple de matrice de traçabilité des exigences pour la description du problème que vous avez fournie :

Matrice de traçabilité des exigences : application bancaire mobile

ID de l’exigence	Description de la exigence	Nom du partie prenante	Statut	Référence au document de conception	Référence au document de test
R1	Capacité à visualiser les soldes des comptes	Clients	Mis en œuvre	Conception de l’interface 1.1	Cas de test 1.1
R2	Capacité à transférer de l’argent entre les comptes	Clients	En cours	Conception de l’interface 1.2	Cas de test 1.2
R3	Capacité à payer les factures	Clients	Non commencé	Conception de l’interface 1.3	Cas de test 1.3
R4	Système backend efficace	Employés de banque	Mis en œuvre	Conception du backend 2.1	Cas de test 2.1
R5	Suivi des métriques d’utilisation	Propriétaires d’entreprise	En cours	Conception d’analyse 3.1	Cas de test 3.1

Cette matrice de traçabilité des exigences permet de suivre l’évolution des exigences tout au long du projet. Elle associe chaque exigence à sa description, au nom du partie prenante, à son statut et aux références des documents de conception et de test. La matrice garantit que toutes les exigences sont prises en compte et fournit une méthode claire pour suivre l’état de mise en œuvre de chaque exigence. Elle peut servir de point de référence pendant le développement et les tests pour s’assurer que toutes les exigences ont été satisfaites et testées. La matrice peut être mise à jour au fur et à mesure que le projet progresse et que de nouvelles exigences sont ajoutées ou que les exigences existantes évoluent.

Document de persona utilisateur

Voici un exemple de document de persona utilisateur pour la description du problème que vous avez fournie :

Document de persona utilisateur : Application bancaire mobile

Nom de la persona : Sarah

Contexte :

Sarah est une graphiste âgée de 29 ans qui travaille dans une agence de design en ville. Elle est très à l’aise avec les technologies et utilise son téléphone mobile pour presque tout, y compris la banque. Elle est toujours en déplacement et préfère utiliser son application mobile pour gérer ses finances, car cela lui fait gagner du temps.

Démographie :

• Âge : 29
• Sexe : Féminin
• État civil : Célibataire
• Profession : Graphiste
• Localisation : Urbain

Objectifs :

• Être en mesure d’accéder rapidement et facilement à ses soldes de compte
• Être en mesure de transférer de l’argent entre ses comptes sans difficulté
• Être en mesure de payer ses factures à temps en utilisant l’application mobile

Défis :

• Sarah possède plusieurs comptes bancaires et trouve parfois difficile de suivre ses soldes sur tous ces comptes.
• Elle s’inquiète de la sécurité de ses informations financières et souhaite s’assurer que son application bancaire mobile est sécurisée.

Citation :

« J’adore utiliser mon application mobile pour gérer mes finances. Cela me fait gagner beaucoup de temps et d’efforts. Je veux simplement pouvoir accéder rapidement et facilement à mes soldes, transférer de l’argent entre mes comptes et payer mes factures à temps. »

Ce document de persona utilisateur permet de créer un profil détaillé d’un utilisateur typique de l’application bancaire mobile. Il fournit des informations sur le contexte, les caractéristiques démographiques, les objectifs, les défis et les citations de l’utilisateur. Ce document peut servir de point de référence lors de la conception et des tests de l’application mobile, afin de s’assurer que l’application répond aux besoins de ses utilisateurs cibles. Le document peut être mis à jour lorsque de nouvelles personas utilisateur sont identifiées ou que les besoins des personas existants évoluent.

 

Liste des cas d’utilisation candidats

Sur la base de la description du problème que vous avez fournie, voici une liste des cas d’utilisation candidats pour l’application bancaire mobile :

1. Visualiser les soldes des comptes – Les utilisateurs doivent pouvoir voir leurs soldes actuels pour tous les comptes associés à leur profil.
2. Transférer de l’argent entre les comptes – Les utilisateurs doivent pouvoir transférer de l’argent entre leurs comptes en utilisant l’application mobile.
3. Payer les factures – Les utilisateurs doivent pouvoir payer leurs factures via l’application mobile.
4. Configurer les paiements automatiques – Les utilisateurs doivent pouvoir configurer des paiements automatiques pour les factures récurrentes.
5. Déposer des chèques – Les utilisateurs doivent pouvoir déposer des chèques en utilisant l’application mobile.
6. Trouver les guichets automatiques et agences proches – Les utilisateurs doivent pouvoir trouver les guichets automatiques et agences bancaires proches en utilisant l’application mobile.
7. Signaler les cartes perdues ou volées – Les utilisateurs doivent pouvoir signaler les cartes perdues ou volées en utilisant l’application mobile.
8. Contacter le service client – Les utilisateurs doivent pouvoir contacter le service client via l’application mobile.
9. Visualiser l’historique des transactions – Les utilisateurs doivent pouvoir visualiser leur historique des transactions pour tous les comptes associés à leur profil.
10. Configurer des alertes pour le compte – Les utilisateurs doivent pouvoir configurer des alertes pour les soldes faibles, les transactions importantes et d’autres activités du compte.

Ces cas d’utilisation couvrent une gamme de fonctionnalités que les utilisateurs pourraient attendre d’une application bancaire mobile. Chaque cas d’utilisation représente une action ou une tâche spécifique qu’un utilisateur peut effectuer dans l’application. Ces cas d’utilisation peuvent être utilisés pour élaborer des histoires utilisateur, des cas de test et d’autres éléments du projet. Ils peuvent également être priorisés en fonction des besoins et des intérêts des parties prenantes impliquées.

 

Cas d’utilisation prioritaires

Voici un exemple de tableau qui priorise les cas d’utilisation selon leur taille, leur priorité et leurs objectifs/valeurs pour l’application bancaire mobile :

Cas d’utilisation	Taille	Priorité	Objectif/Valeurs
Visualiser les soldes des comptes	Petit	Élevée	Confort, Accès à l’information
Transférer de l’argent entre les comptes	Moyen	Élevée	Confort, Efficacité
Payer les factures	Moyen	Élevée	Confort, Efficacité
Configurer les paiements automatiques	Moyen	Moyen	Confort, efficacité
Déposer des chèques	Moyen	Moyen	Confort, efficacité
Trouver les guichets automatiques et les agences proches	Petit	Moyen	Confort, accès à l’information
Signaler les cartes perdues ou volées	Petit	Moyen	Sécurité, prévention des fraudes
Contacter le service client	Petit	Moyen	Service client, satisfaction
Consulter l’historique des transactions	Moyen	Faible	Gestion des dossiers, accès à l’information
Configurer les alertes de compte	Moyen	Faible	Confort, sécurité

Ce tableau liste chaque cas d’utilisation, ainsi que sa taille (petit, moyen ou grand), sa priorité (élevée, moyenne ou faible) et l’objectif ou la valeur qu’elle représente (par exemple, confort, accès à l’information, sécurité, etc.). La taille du cas d’utilisation est déterminée par la quantité d’effort nécessaire pour le mettre en œuvre, tandis que la priorité repose sur l’importance du cas d’utilisation pour le succès du projet. L’objectif ou la valeur permet de fournir un contexte pour chaque cas d’utilisation et d’expliquer pourquoi il est important. Ce tableau peut être utilisé pour guider le développement de l’application bancaire mobile et s’assurer que les cas d’utilisation les plus critiques sont correctement priorisés.

Exemple de description de cas d’utilisation

Voici un exemple de description de cas d’utilisation pour le cas d’utilisation « Consulter les soldes des comptes » :

Nom du cas d’utilisation : Visualiser les soldes des comptes

Acteurs :

• Client

Description : Le client souhaite visualiser les soldes de ses comptes via l’application bancaire mobile. Ce cas d’utilisation permet au client de vérifier rapidement et facilement les soldes de ses comptes sans avoir à se rendre dans une agence bancaire ou à un guichet automatique.

Préconditions :

• Le client dispose d’un compte valide auprès de la banque.
• Le client a téléchargé et installé l’application bancaire mobile sur son smartphone ou sa tablette.
• Le client est connecté à son compte bancaire mobile.

Flux principal :

1. Le client ouvre l’application bancaire mobile.
2. Le client sélectionne l’option « Visualiser les soldes des comptes » dans le menu principal.
3. L’application affiche une liste des comptes du client, accompagnée du solde actuel de chaque compte.
4. Le client examine les soldes des comptes.

Flux alternatifs :

• Si le client ne possède qu’un seul compte, l’application peut afficher automatiquement le solde du compte sans afficher la liste des comptes (étape 3).
• Si le client possède plusieurs comptes, mais que l’application est incapable de récupérer les soldes des comptes, un message d’erreur est affiché au client.

Postconditions :

• Le client a consulté les soldes de ses comptes.
• Le client peut choisir d’effectuer d’autres actions dans l’application bancaire mobile ou de se déconnecter de son compte.

Exceptions :

• Si l’application bancaire mobile est indisponible ou ne fonctionne pas correctement, le client ne pourra pas visualiser les soldes de ses comptes.
• Si le client a oublié ses identifiants de connexion, il devra réinitialiser son mot de passe ou contacter le service client pour obtenir de l’aide.
• Si le compte du client est fermé ou inactif, il ne pourra pas visualiser les soldes des comptes.