Appréhendez ce qu’est une revue d’exigences
Imaginez une flamme sous une cloche : elle manque d’air. Elle s'essouffle et va s’éteindre.
Retirez le dôme, et vous la verrez de nouveau prendre vie. Éclairer les alentours et onduler doucement. Désormais, remplacez cette flammèche par une exigence, et la cloche par une question. Vous avez la démonstration parfaite de ce qui se passe lorsque vous vous posez une question sur une exigence. Une exigence ne peut être considérée valide tant qu’une question / zone d’ombre plane à son sujet.
Dans un contexte agile, les équipes sont réduites, l’accès aux informations et les échanges avec les autres membres de l'équipe sont facilités. Vous serez tenté de poser directement vos questions à l’oral.
Le conseil que je peux vous donner, c’est de noter tous ces points.
L’intérêt est de laisser une trace de ce que vous vous êtes demandé, et vous pourrez vous en servir de base dans vos échanges, travaux, ou même bilan de projet.
Ce document a plusieurs objectifs ; entre autres :
faciliter la collaboration : C’est un moyen de favoriser la collaboration entre les différents membres de l’équipe. Il permet d’ouvrir le dialogue, de partager des idées et de travailler ensemble pour améliorer les exigences ;
aligner les parties prenantes : Il permet de s’assurer que toutes les parties prenantes ont la même compréhension des exigences. Cela permet d’éviter les malentendus et les divergences d’interprétation, et de s’assurer que tout le monde est d’accord ;
documenter les décisions : C’est une mesure pour documenter les décisions prises au sujet des exigences. Cela permet de suivre l’évolution des exigences au fil du temps, et de disposer d’un historique des décisions prises.
Vous pouvez classer vos questions par criticité, en vous basant par exemple sur la criticité de la fonctionnalité ou de l’exigence concernée :
critique : bloque totalement la compréhension ;
majeure : un doute plane mais n’est pas bloquant ;
mineure : une remarque mineure (fautes de frappe, etc.).
Rédigez vos remarques
Prenez votre plume, il est temps de rédiger !
Lors de la revue d’exigences, il est important de noter toutes les remarques pertinentes pour assurer la qualité du produit final.
Voici quelques conseils pour rédiger ces remarques :
Soyez précis : décrivez clairement le problème ou l'ambiguïté que vous avez identifié dans les exigences.
Donnez des exemples : si possible, étayez vos remarques par des exemples concrets.
Proposez des solutions : si vous avez des idées pour améliorer l'exigence, n'hésitez pas à les partager.
Priorisez : il est important de hiérarchiser les remarques en fonction de leur impact potentiel sur le produit final.
Soyez constructif : essayez de rester objectif et d'adopter une approche constructive. Le but de la revue d'exigences est d'améliorer la qualité du produit final, pas de critiquer les membres de l'équipe. La bienveillance est l’un des meilleurs carburants pour avancer en équipe.
Utilisez un outil de suivi : pour assurer le suivi des remarques, il est recommandé d'utiliser un outil de suivi tel qu'un système de gestion de projet ou de suivi de problèmes, ou un tableur type Excel, qui fera tout aussi bien l’affaire.
Voici un exemple de la forme que peut prendre ce document :
Numéro de la question | Exigence | Demandeur | Criticité | Date de la demande | Commentaire | État | Version du document | Répondant | Date de la réponse | Réponse |
1 | EX-1 | Martin | Critique | 02/01/2023 | Une coquille à dû se glisser à la place de l’URL du WS ? | Traité | v.1 | Adrien | 09/01/2023 | Spec mise à jour |
Partagez votre revue d’exigences
Dès que vous estimez avoir fait le tour de vos questions et remarques, vous pouvez partager le contenu avec les parties prenantes.
Cela peut d’abord passer par :
L’équipe de test :
Commencez par partager votre revue avec vos pairs.
Le double bénéfice est qu’ils pourront peut-être répondre à certaines de vos questions, et améliorer leur compréhension quand ils liront à leur tour les spécifications.
L’équipe projet :
Mutualisez ensuite vos réflexions entre l’équipe (développeurs, PO, bureau d’étude, etc.) et l’équipe avec qui vous travaillez.
Il est fort probable qu’elle travaille sur le sujet depuis plus longtemps que vous, et a donc eu plus de temps pour approfondir ses connaissances du projet.
L'équipe métier :
Pour finir, vous pouvez envoyer à l’équipe métier qui, elle, aura la réponse, ou ira la chercher / la définir.
Ciblez donc bien vos interlocuteurs ; pour vous aider à vous y retrouver, voici un exemple de périmètre traité par chacun d’entre eux :
Interlocuteur | Périmètre | Exemples de sollicitations |
Développeurs | Développement du projet |
|
PO | Pilote la réalisation du produit |
|
AMOA | Traduit en solution technique les besoins fonctionnels de la MOA |
|
MOA | Définit les besoins métiers de l’application |
|
À retenir : chaque membre de l’équipe projet a sa spécificité, les développeurs par exemple ont leur réflexion plus axée sur l’aspect technique de la solution, alors que pour un testeur, le fonctionnel sera plus présent (sans négliger toutefois la partie technique !).
Encore une petite anecdote pour illustrer mes propos juste au-dessus : Il nous était demandé d’ajouter un filtre de recherche sur un site de vente en ligne, pour des produits de beauté, en fonction du type de peau (sèche, normale ou grasse).
Les développeurs ajoutent donc l’option de filtrage, basée sur une liste déroulante pour que les utilisateurs puissent sélectionner leur type de peau.
De leur point de vue, ils avaient tout à fait raison, et c'est ce qui était décrit dans les spécifications.
Toutefois, l’aspect fonctionnel entre en jeu : certains de ces produits pouvaient correspondre à plusieurs types de peau. Or, de la manière dont c'était développé, un produit n’apparaissait que dans un seul filtre. Ce qui pouvait induire en erreur les futurs clients.
Un sujet qui est revenu sur la table des discussions, et qui a trouvé une solution par la suite de nos échanges.
À vous de jouer !
Contexte
Vous vous familiarisez avec le contenu des spécifications. Toutefois, vous remarquez que des éléments ne sont pas très précis, ou sont même manquants !
Faites pointer la lumière vers ces zones d’ombre pour les éclaircir, et que vous puissiez lever les doutes à leur sujet.
Consignes
Reprenons les spécifications et le travail d’analyse que vous avez effectués.
Votre mission est de poser les questions et de faire les remarques nécessaires pour lever vos doutes et résoudre les ambiguïtés :
rédigez votre revue d’exigences ;
rédigez un mail pour communiquer à toutes les parties prenantes les informations clés relevées dans votre revue.
En résumé
Ce document a plusieurs objectifs : faciliter la collaboration, aligner les parties prenantes et documenter les décisions.
Utilisez un format type tableur Excel pour noter vos remarques.
Soyez clair, précis et synthétique dans vos remontées.
Communiquez votre document en interne à l’équipe de test ou agile avant de le diffuser plus largement.
Restez bienveillant dans vos remarques.
Vous avez exposé toutes les zones d’ombre que vous avez pu relever, il est désormais temps d’attendre le retour client afin de compléter votre document, et de savoir si votre niveau de compréhension est satisfait.
