Contexte de la question :
Les exigences complexes sont souvent formulées à un niveau d'abstraction élevé ou contiennent de multiples conditions et exceptions cachées. Si ces exigences ne sont pas décomposées et clarifiées, cela peut entraîner des interprétations divergentes entre le client, les développeurs et les testeurs.
Problème :
Des exigences ambiguës ou insuffisamment décomposées entraînent le fait que l'équipe "devine" elle-même les détails. En conséquence, la valeur commerciale peut ne pas être réalisée ou être déformée, et il devient beaucoup plus difficile et coûteux de corriger cela.
Solution :
L'analyste système effectue une analyse détaillée des exigences en utilisant des techniques de décomposition (diagramme de cas d'utilisation, diagramme d'activité, récits utilisateurs selon la méthode INVEST, event storming, arbre de décomposition). Il est important de former des scénarios (flux de base / alternatifs / exceptionnels), de construire des tables de décision et des matrices de transitions, et à la fin, de vérifier chaque "nœud" à l'aide d'exemples de cas limites en collaboration avec le client. Après décomposition, l'analyste assemble toutes les parties, en analysant les points d'intégration et en assurant la cohérence.
Caractéristiques clés :
Un simple texte décrivant le scénario d'une User Story est-il suffisant ?
Non, seules les user stories ne suffisent pas : des diagrammes de séquence, des exemples de cas limites, des maquettes UI et des tables de décision sont nécessaires pour une logique d'affaires complexe.
La décomposition garantit-elle automatiquement l'absence de contradictions entre les exigences ?
Non, la décomposition doit être accompagnée de la consolidation des exigences conflictuelles, de revues régulières et d'analyses des dépendances.
Peut-on confier la décomposition uniquement aux développeurs ou testeurs ?
Non, l'analyste est responsable de l'exhaustivité de la décomposition. Si cette tâche est confiée à d'autres rôles, cela entraîne une multitude d'interprétations et de divergences.
Cas négatif :
Le client commercial a écrit "Le système doit calculer la remise pour chaque client de manière individuelle". Un modèle rigide de remises a été mis en œuvre. Lors des tests, il s'est avéré qu'il y avait plus d'une dizaine de paramètres cachés, qui n'avaient pas été identifiés lors de la formalisation.
Avantages :
Inconvénients :
Cas positif :
L'analyste a organisé un atelier de Event Storming, a identifié tous les paramètres et conditions de calcul. Il a construit une table de décision et des diagrammes de séquence, a validé avec le client des exemples de cas limites. L'exigence est devenue claire et vérifiable, les erreurs ont été identifiées avant le début du développement.
Avantages :
Inconvénients :