Carte mentale de recueil des besoins : modèle gratuit pour analystes

Carte mentale de recueil des besoins : modèle gratuit pour analystes

Le canevas MindMap interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.

Comment lire cette carte mentale

• Commencez par « Parties prenantes » et « Besoins métier » pour voir qui est concerné et pourquoi. « Besoins utilisateurs » décrit le besoin du point de vue de l'utilisateur, et « Exigences fonctionnelles » et « Exigences non fonctionnelles » le traduisent en ce que le système doit faire et avec quelle qualité.
• Les flèches en pointillés suivent le raisonnement. Par exemple, une capacité sous « Priorité » est justifiée par la mesure de réussite de « Résultat visé », et un besoin de sécurité dans « Sécurité et confidentialité » peut entrer en conflit avec une limite technique de « Limites techniques ».

Parties prenantes

« Parties prenantes » ouvre la carte, car chaque exigence a quelqu'un derrière elle. Listez sous « Sponsors » ceux qui financent, sous « Utilisateurs finaux » ceux qui utiliseront le résultat, et sous « Approbateurs et support » ceux qui doivent l'approuver ou le soutenir.

Interrogez tous ceux de « Utilisateurs finaux », pas seulement leur responsable. Une erreur fréquente est de rédiger les exigences à partir de la description du sponsor d'un travail qu'il ne fait plus.

Besoins métier

« Besoins métier » explique pourquoi le projet existe. « Problème à résoudre » est le problème ou l'opportunité, « Résultat visé » le résultat qui serait un succès, et « Mesure de réussite » la mesure qui le prouve.

Chaque exigence ailleurs sur la carte doit remonter à un élément d'ici. Si ce n'est pas le cas, demandez quel besoin elle sert ou supprimez-la.

Besoins utilisateurs

« Besoins utilisateurs » consigne ce que les gens ont besoin d'accomplir. Écrivez « Tâches à accomplir » sous forme de tâches du point de vue de l'utilisateur, et notez sous « Difficultés actuelles » les difficultés de la façon de travailler actuelle.

« Contexte d'utilisation » décrit la situation dans laquelle les utilisateurs travaillent, par exemple sur un téléphone, dans un lieu bruyant ou sous contrainte de temps. Ces détails décident souvent davantage de la conception que les tâches elles-mêmes.

Exigences fonctionnelles

« Exigences fonctionnelles » liste ce que le système doit faire. « Capacités principales » sont les capacités principales, « Règles de gestion » les règles qu'il doit appliquer, et « Interfaces » les interfaces avec d'autres systèmes ou équipes.

Formulez chacune de façon testable, par exemple : le système envoie une confirmation en moins d'une minute. Prenez « Énoncé testable » comme modèle pour rédiger le détail.

Exigences non fonctionnelles

« Exigences non fonctionnelles » couvre le niveau de qualité attendu du système. « Performance » fixe la vitesse et la capacité, « Sécurité et confidentialité » traite de la sécurité et de la confidentialité, et « Ergonomie et accès » de l'ergonomie et de l'accessibilité.

Ce sont les exigences qu'on oublie de demander et sur lesquelles on se dispute après le lancement. Donnez à chacune un chiffre ou une norme dans la mesure du possible.

Contraintes

« Contraintes » liste les limites que la solution ne peut pas franchir. « Budget et délais » sont le budget et les délais, « Limites techniques » les limites techniques comme les systèmes existants, et « Juridique et politique interne » les obligations légales ou de politique interne.

Confrontez tôt chaque exigence à « Limites techniques ». Une exigence en conflit avec une contrainte ferme est une décision pour le sponsor, pas une tâche pour l'équipe.

Comment les branches sont reliées

Les besoins descendent. « Besoins métier » donne la raison, « Besoins utilisateurs » le point de vue de l'utilisateur, et « Exigences fonctionnelles » et « Exigences non fonctionnelles » sont les exigences qui en découlent. Une exigence sans source dans les trois premières branches est à supprimer.

« Contraintes » repousse vers le haut. Une contrainte peut rendre un besoin inabordable, ce qui vous renvoie à « Besoins métier » pour demander si un résultat plus modeste est acceptable, et à « Parties prenantes » pour le valider.

Où s'arrête la carte mentale et où commencent les autres diagrammes

Utilisez la carte mentale pour recueillir et organiser. Pour décrire comment le travail circule aujourd'hui et comment il devrait circuler, dessinez une cartographie de processus ou un logigramme, et utilisez un diagramme en couloirs quand les exigences dépendent de passages de relais entre équipes.

Un organigramme hiérarchique peut documenter la structure des parties prenantes et des approbations, et un diagramme de Gantt prend le relais quand les exigences deviennent une livraison planifiée.

Relations et enseignements clés

• Chaque exigence doit remonter à un besoin métier et à une partie prenante.
• Les besoins utilisateurs s'écrivent sous forme de tâches, et les exigences fonctionnelles sous forme de comportements testables.
• Les exigences non fonctionnelles sont celles qui manquent le plus souvent dans les premières versions.
• Les contraintes sont décidées par des personnes, elles apparaissent donc aussi sous les parties prenantes.
• Une exigence sans priorité sera traitée comme aussi urgente que toutes les autres.

Quand utiliser ce visuel

• Préparer des entretiens avec les parties prenantes et consigner les réponses sur une carte partagée.
• Relire un projet de document d'exigences pour repérer les catégories manquantes avant validation.
• Cadrer un petit outil interne pour lequel une spécification complète serait excessive.

Comment cela fonctionne

1. Identifier les personnes

   Renommez « Besoins du projet », puis listez les parties prenantes sous « Parties prenantes » et repérez celles que vous n'avez pas encore rencontrées. Menez les entretiens avant de remplir les autres branches.

2. Consigner les besoins tels qu'entendus

   Placez les raisons sous « Besoins métier », les tâches des utilisateurs sous « Besoins utilisateurs » et le comportement du système sous « Exigences fonctionnelles ». Notez la source dans chaque nœud pour pouvoir revenir la vérifier.

3. Vérifier les limites et les conflits

   Comparez chaque exigence avec « Exigences non fonctionnelles » et « Contraintes », tracez des liens là où elles entrent en conflit, et portez les conflits ouverts aux parties prenantes listées dans « Parties prenantes ».

Questions fréquentes

Quelle différence entre exigences fonctionnelles et non fonctionnelles ?

Les exigences fonctionnelles disent ce que fait le système, par exemple créer une facture ou envoyer une alerte. Les exigences non fonctionnelles disent avec quelle qualité : vitesse, sécurité, disponibilité, accessibilité. Les deux sont nécessaires, et les non fonctionnelles se découvrent en général tard si on ne les demande pas directement.

Pourquoi commencer par les parties prenantes plutôt que par les fonctionnalités ?

Parce que chaque exigence a un responsable qui peut l'expliquer et, au besoin, la modifier. Partir des fonctionnalités donne une liste que personne ne peut défendre ni hiérarchiser. Partir des personnes indique qui interroger et qui doit se mettre d'accord quand deux exigences entrent en collision.

Quel niveau de détail pour les exigences sur une carte mentale ?

Assez pour les reconnaître et en discuter, assez court pour être parcouru d'un coup d'œil. Utilisez l'idée pour un énoncé court et la note pour la source ou la condition de test. Quand une branche devient trop chargée, déplacez-la dans une spécification d'exigences ou un backlog de récits utilisateurs.

Les parties prenantes peuvent-elles relire directement la carte ?

Oui. Partagez le diagramme avec les relecteurs, laissez-les commenter des exigences précises et utilisez l'historique des versions pour garder trace de ce qui a changé entre les tours de relecture. La validation est ainsi plus fiable que des documents envoyés par e-mail dans les deux sens.

Partir de cette carte des besoins

Ouvrez le modèle comme votre propre canevas, nommez le projet et commencez par lister les parties prenantes que vous devez rencontrer.

Partir de cette carte des besoins