Réponse.

Contexte de la question : Aux premières étapes d'un projet, le client formule souvent des exigences vagues ou contradictoires que l'analyste doit transformer en exigences claires et vérifiables pour la mise en œuvre ultérieure.

Problème : Des exigences vagues entraînent une incohérence de compréhension entre l'entreprise et l'équipe de développement, ce qui augmente le nombre de retours de tâches, de bugs et d'utilisateurs insatisfaits.

Solution :

Organisation d'ateliers et de sessions de clarification : l'analyste anime une réunion avec le client, utilise des techniques de clarification (Example Mapping, Event Storming, Story Mapping).
Utilisation de prototypes et de wireframes : la modélisation visuelle aide l'entreprise à exprimer plus précisément ses attentes.
Clarification progressive jusqu'aux critères de terminaison (Definition of Ready) : décomposition en sous-tâches, formalisation des scénarios, collecte des edge-cases.

Caractéristiques clés :

Clarification progressive — un processus continu, incluant des cycles de questions et de vérifications rapides (feedback loop).
Implication de plusieurs participants pour considérer différents points de vue.
L'analyste documente les options et les contraintes, même en cas de « exigences brutes ».

Questions piégeuses.

« Peut-on se fier uniquement aux paroles du client lors de la collecte d'exigences vagues ? »

Non, il est important d'utiliser des exemples, des diagrammes, des maquettes et de poser des questions supplémentaires pour identifier les véritables besoins.

« Est-il suffisant de valider les clarifications d'exigences une seule fois ? »

Non, la validation est un processus itératif : au fur et à mesure que des détails apparaissent, les exigences doivent être revues et validées.

« Est-il toujours possible de préciser les exigences sans impliquer les utilisateurs finaux ? »

Non, la participation des utilisateurs réels est parfois essentielle pour identifier les edge-cases et les scénarios d'utilisation qui ne sont évidents ni pour l'entreprise ni pour la TI.

Erreurs fréquentes et anti-patterns

Essayer de mettre en œuvre une exigence vague sans formalisation.
Ignorer les sessions de clarification.
Documenter les exigences uniquement par écrit, sans visualisation ni exemples.

Exemple de vie

Cas négatif : Le client a demandé un « mécanisme de recherche pratique » — cela a été noté et nous avons commencé à mettre en œuvre « comme d'habitude ».

Avantages :

Démarrage rapide de la tâche.

Inconvénients :

Le résultat n'a pas satisfait l'utilisateur ; une autre recherche et des filtrages étaient requis.

Cas positif : Pour une tâche similaire, l'analyste a organisé un atelier, a recueilli des scénarios utilisateur et a dessiné des prototypes.