Réponse.

Historique de la question :

Avec l'augmentation de l'échelle et de la complexité des projets informatiques, il est souvent arrivé que les exigences du client commercial soient présentées sous forme de souhaits abstraits qui, lors de leur transmission à l'équipe de développement, se transformaient en quelque chose de différent. Cela est dû à un fossé dans la terminologie, les attentes et le niveau d'abstraction entre les affaires et l'informatique.

Problème :

Sans une réflexion sur l'étape de décomposition, les exigences deviennent soit incomplètes (des détails critiques sont omis), soit excessivement floues (impossible à évaluer et à réaliser), ou bien elles sont complètement déformées à cause de pièges lexicaux, de terminologie non prise en compte et d'interprétations divergentes.

Solution :

L'analyste système décompose systématiquement chaque exigence : il formalise les termes commerciaux, traduit les objectifs commerciaux en fonctions et tâches, décrit les scénarios utilisateurs et le comportement du système, et les relie aux critères d'acceptation/cas de test. Il est important d'utiliser des modèles (UML, BPMN), des glossaires, des check-lists et un examen direct entre les équipes.

Caractéristiques clés :

Construction d'un glossaire de termes en collaboration avec le client
Utilisation de diagrammes et de formulations atomiques d'exigences
Traduction des exigences en critères d'acceptation et cas de test

Questions piégeuses.

Peut-on laisser les souhaits commerciaux sous forme libre avec des retouches ultérieures lors de la phase de développement ?

Non, il y a un fort risque de malentendus et d'erreurs de mise en œuvre.

Faut-il arriver à des détails de mise en œuvre (par exemple, comment stocker les données) lors de l'analyse ?

Non, l'analyse concerne "quoi" et "pourquoi", et non "comment". Les détails techniques relèvent de la responsabilité de l'architecture et du développement.

Une exigence équivaut-elle toujours à un module/fonctionnalité ?

Non, il est souvent nécessaire de décomposer - les grandes exigences sont divisées en sous-fonctions et user stories avec des critères d'acceptation distincts.

Erreurs typiques et anti-patrons

Mélange du langage commercial et des termes techniques sans glossaire
Description des exigences sous forme de "souhaits flous"
Violation de l'atomicité - une exigence contient de nombreuses entités différentes

Exemple de la vie réelle

Cas négatif : Le client a transmis une liste de souhaits "L'utilisateur doit voir toute l'analyse des ventes", et a été copié dans le cahier des charges sans modification.

Avantages :

Rapidité de préparation de la documentation

Inconvénients :

Pas clair quelles métriques spécifiques et sous quel angle sont nécessaires
Retouches constantes

Cas positif : L'analyste a interrogé le client, a établi une liste des métriques nécessaires, a défini les rôles des utilisateurs, a développé des prototypes de rapports, a convenu d'un glossaire de termes.