Vos exigences sont-elles suffisantes ?

Introduction

Que vous développiez un logiciel, lanciez un nouveau produit ou exécutiez un projet, la qualité de vos exigences est un facteur clé qui permet au développement de se dérouler avec un risque raisonnable. Cependant, comment juger si les exigences sont suffisantes ?

Il n’existe pas de recette pour une exigence parfaite. Les défis courants qui compromettent la qualité d’une exigence sont l’ambiguïté, l’incomplétude, l’incohérence et la volatilité. Dans certains cas, les attentes des parties prenantes peuvent même sembler contradictoires. Néanmoins, le spectacle doit continuer et parfois, l’équipe doit encore procéder au développement en fonction des exigences du « mi-cuit ». En tant que gardien des exigences, l’objectif du Business Analyst ou du Product Owner est de surmonter les défis susmentionnés et de fournir suffisamment de clarté et d’orientation pour procéder à la phase de développement. Cela dépend également de la capacité de risque du projet : le risque de devoir procéder à d’importantes retouches imprévues en raison de l’inadéquation des exigences doit être minimisé en consacrant suffisamment de temps et d’efforts à la création des exigences.

Malheureusement, il n’y a pas de voyant vert indiquant que toutes vos conditions préalables sont remplies. D’après mon expérience en tant qu’analyste commercial, l’un des plus grands défis a été de déterminer si toutes les exigences pertinentes ont été correctement formulées et présentées. Alors, en tant qu’analyste commercial, comment pouvons-nous déterminer si nos exigences sont « suffisamment bonnes » pour servir de base solide ? L’équipe de développement (développeurs, testeurs, concepteurs, architectes…) peut vous aider ici.

Niveaux de spécification

Tant la quantité que la qualité des informations proposées peuvent définir une exigence « assez bonne ». Un ensemble complet d’exigences mal écrites et erronées est inutile, tandis qu’un ensemble minimal d’exigences parfaitement rédigées pourrait être dépourvu d’informations dont les développeurs et les testeurs pourraient avoir besoin.

Trois aspects de l’exhaustivité des critères viennent à l’esprit : le type d’informations fournies, l’étendue des connaissances et le niveau de détail de chaque élément.

• • Types d’informations. Même si les fonctionnalités dont les clients ont besoin pour atteindre leurs objectifs constituent la priorité principale des équipes de projet, un ensemble d’exigences efficaces va bien au-delà. De plus, les exigences relatives aux attributs de qualité, les limitations de conception et de mise en œuvre, les règles métier, les spécifications des interfaces externes, les sources et types de données, etc. doivent être comprises par les développeurs. Il ne suffit pas d’avoir simplement une liste d’exigences fonctionnelles ou de user stories.
  • Gamme de compétences : Cette dimension inclut toutes les données d’exigences présentes dans une spécification. Couvre-t-il tous les besoins connus des utilisateurs ou simplement les plus importants ? Tous les aspects qualité pertinents ont-ils été couverts ? Le lecteur sait-il si cela couvre l’ensemble des attentes ou s’il existe des lacunes qu’il devra combler ? S’il n’est pas complet, tous les lecteurs verront-ils les mêmes lacunes ? Les exigences supposées et implicites mais qui ne sont pas explicitement énoncées risquent d’être oubliées.
  • exhaustivité des informations : Le niveau de précision et de détail proposé pour chaque demande fait l’objet de la troisième dimension. Les exceptions potentielles (circonstances d’erreur) sont-elles identifiées et comment le système doit-il y répondre, spécifié dans les exigences ? Est-ce qu’ils couvrent aussi simplement les trajectoires heureuses d’un comportement typique ? La norme couvre-t-elle la désinstallation et la réinstallation des logiciels, la réparation des installations qui tournent mal et l’application de mises à jour et de correctifs si elle parle d’un trait de qualité tel que l’installabilité ? Les exigences, tant fonctionnelles que non fonctionnelles, doivent être suffisamment détaillées dans la solution réelle pour permettre une vérification.

Quel montant est « suffisant » ?

Déterminer si votre exigence est « suffisante » dépend de plusieurs facteurs, notamment la nature et la complexité du projet, les besoins et les attentes des parties prenantes, ainsi que l’étape du cycle de vie du projet. Bien qu’il n’y ait pas de réponse universelle, il existe certaines mesures que nous pouvons prendre (en tant qu’analystes commerciaux) pour prendre une décision : inviter certains développeurs, testeurs, architectes et autres parties prenantes à examiner les exigences et à juger si les informations Le document fourni est suffisamment détaillé et clair pour que chacun puisse faire du bon travail.

Conclusion

Peu importe à quel point un analyste commercial estime que les exigences sont excellentes, la qualité des exigences est dans l’œil du spectateur – dans ce cas, des personnes qui devront réellement travailler sur ces exigences. Alors, demandez toujours l’avis et les commentaires de ces parties prenantes internes pour déterminer si vos exigences sont « assez bonnes ».

VOUS TROUVEZ CECI UTILE ? PARTAGEZ-LE