Réponse

Dans l'histoire de l'analyse systémique, l'une des tâches les plus difficiles est d'identifier et de formaliser des exigences non évidentes, floues ou cachées. Souvent, le commanditaire ne peut pas expliquer clairement ce qui est nécessaire ou utilise des termes sans révéler ses véritables attentes.

Caractéristiques clés :

• Les exigences implicites sont identifiées par l'analyse, l'écoute active, des questions de clarification, des entretiens et l'observation.
• La formalisation se fait dans un langage compréhensible à la fois par le commanditaire et par les développeurs (par exemple, en utilisant des récits utilisateurs, des scénarios BPMN).
• Il est essentiel de fixer et de valider les formulations clarifiées avec le commanditaire pour éviter toute ambiguïté.

Historique de la question

Le problème des exigences non formalisées est connu depuis les premiers projets de mise en œuvre. À l'origine, des entretiens simples étaient utilisés, mais on utilise maintenant également le user story mapping, le prototypage et la facilitation.

Problème

Les exigences implicites conduisent à une mauvaise formulation des tâches, à des efforts inutiles et à des conflits entre les parties.

Solution

Utiliser des techniques d'entrevue, de visualisation (cartes de processus, prototypes), la facilitation et une documentation claire des résultats. Vérifier les retours après chaque étape de la fixation des exigences.

Questions pièges.

Peut-on formaliser toutes les exigences à l'avance avant le début du projet ?

Non, beaucoup d'exigences sont clarifiées et découvertes au cours du travail lors du prototypage et de la clarification du projet.

Faut-il enregistrer uniquement les souhaits exprimés de manière explicite par le commanditaire ?

Non, l'analyste doit également travailler avec les attentes implicites, analyser les objectifs commerciaux et identifier les besoins cachés.

La tâche d'un analyste système consiste-t-elle seulement à traduire les exigences en cahier des charges ?

Non, l'analyste est également responsable de la formalisation, de la validation et de la clarification des exigences, ainsi que de l'identification des contradictions.

Erreurs courantes et anti-modèles

• Ne pas fixer les accords intermédiaires.
• Considérer que toutes les exigences sont également importantes.
• Documenter uniquement ce qui est explicitement dit sans analyser les processus réels.

Exemple de la vie

Cas négatif :
L'analyste a enregistré tout ce que le commanditaire a dit dans le projet sans clarifier les détails. Avantages : le développement a commencé rapidement, économie de temps sur l'analyse.
Inconvénients : de nombreuses retouches, conflits avec le commanditaire en raison de mauvaises attentes.

Cas positif :
L'analyste a créé des prototypes, a conduit des sessions de clarification, a fixé les exigences implicites avec le commanditaire.
Avantages : haute précision des exigences, commanditaire satisfait, moins de conflits.
Inconvénients : coûts de facilitation et de collecte de retours.