Réponse.

Historique de la question :

Les premières phases des projets sont souvent accompagnées d'une incertitude quant aux objectifs commerciaux et aux solutions architecturales, c'est pourquoi l'analyste système est confronté au problème de déterminer le niveau de détail optimal des exigences. Un choix erroné mène soit à une sur-conception (overengineering), soit à une ambiguïté des tâches et à une incompréhension au sein de l'équipe.

Problème :

Certains intervenants exigent de voir les détails "à l'avance", d'autres craignent que trop de détails n'entraînent une perte de flexibilité. La transition entre les étapes (de la conception à la conception, puis à la mise en œuvre) nécessite une mise à jour opportune des exigences et l'implication de tous les participants.

Solution :

L'analyste système applique une approche itérative. Au début, seules les principales besoins commerciaux et les grands blocs (epic) sont fixés, puis les niveaux de détail augmentent au fur et à mesure qu'on progresse vers le développement :

À l'étape de prévente — Vision et exigences de haut niveau ;
Lors de la préparation du cahier des charges — décomposition en user stories ou spécifications de fonctionnalités ;
À l'étape de conception et de transfert au développement — élaboration des scénarios, des erreurs, des interactions et des maquettes jusqu'au niveau des critères d'acceptation.

Caractéristiques clés :

Le niveau de détail augmente à mesure que la solution est précisée (principe de l'élaboration progressive).
L'analyste utilise la synchronisation avec l'équipe pour ne pas entrer dans les détails trop tôt.
Le niveau de détail est en accord avec le cycle de vie du projet et les obligations contractuelles.

Questions pièges.

Qui doit déterminer le niveau de détail nécessaire — l'analyste, l'architecte ou le client ?

On pense souvent à tort que cela ne relève que de l'analyste ou que de l'architecte, alors que la réponse correcte est : le niveau de détail est de la responsabilité de l'ensemble du groupe de coordination (analyste, architecte, product owner, leaders techniques et client), en accord dans le cadre de la méthodologie du projet.

Les exigences de haut niveau sont-elles suffisantes pour démarrer le travail de l'équipe ?

Non, les exigences de haut niveau sont nécessaires pour former une vision globale. Pour passer au développement, des scénarios précisés (user stories, critères d'acceptation) sont obligatoires, sinon le risque de malentendu et d'erreurs lors de la mise en œuvre est élevé.

Tous les exigences doivent-elles être également détaillées pour la sortie ?

Non, souvent les exigences pour le MVP sont approfondies au maximum, tandis que des tâches moins prioritaires sont maintenues à un niveau de brouillon, afin de ne pas gaspiller les ressources prématurément.

Erreurs typiques et anti-patrons

Continuer à augmenter le niveau de détail sans tenir compte de la phase du projet.
Commencer à traiter les détails de toutes les exigences, même celles de moindre priorité, perdant ainsi en rapidité.
Négliger la communication avec l'équipe concernant la suffisance du niveau de détail — il manque des retours d'information.

Exemple de la vie

Cas négatif : Un projet CRM dans une startup. L'entreprise insistait sur une description détaillée de tous les modules à l'avance. L'analyste a créé des centaines de pages d'exigences pour toutes les futures fonctionnalités, bien que seules les ventes soient prioritaires.

Avantages :

Base détaillée d'exigences pour l'avenir.

Inconvénients :

Coûts en temps et en budget, retards dans le démarrage.
Les exigences étaient obsolètes au moment de l'élaboration des modules et nécessitaient des changements substantiels.

Cas positif : Dans un projet similaire, l'analyste a formé le noyau des exigences pour le MVP (gestion des leads et des transactions), les autres étaient formulées comme des épics avec une brève description. Le niveau de détail s'est développé au fur et à mesure de l'approche des sprints de réalisation.