Réponse.

Historiquement, les approches de collecte des exigences étaient considérées comme linéaires : l'analyste interrogeait différents parties prenantes, constituait des listes de souhaits et les formulait dans une spécification. En réalité, plus le projet est large, plus il devient difficile d'identifier et de suivre les chevauchements, les duplications et les tâches diamétralement opposées entre les exigences de différents groupes d'intérêt.

Problème

Dans les systèmes à grande échelle, il se produit souvent :

des contradictions entre les exigences de différents départements (par exemple, sécurité vs confort) ;
des chevauchements et des duplications (différentes équipes veulent la même chose sous un angle différent) ;
des dépendances cachées (un changement entraîne d'autres).

Une erreur au stade de l'analyse peut entraîner des conflits lors de la mise en œuvre, un allongement des délais, des mécanismes non fonctionnels ou une impossibilité d'intégration des modules.

Solution

Un analyste système professionnel est contraint d'utiliser des techniques :

création de matrices de dépendance (par exemple, ".requirement-traceability-matrix") et de modèles (diagrammes UML, diagrammes ER) ;
organisation de réunions de travail et de revues entre des groupes de parties prenantes opposés ;
utilisation de la technique de "résolution des conflits d'exigences" (par exemple, des sessions de facilitation) ;
mise en place d'outils de traçabilité (traceability) qui permettent de voir, à chaque étape, les relations entre les exigences (par exemple, les exigences API et les exigences de sécurité pour ces mêmes opérations) ;
mise à jour régulière et priorisation des exigences.

Caractéristiques clés :

Les matrices et les diagrammes sont indispensables pour des projets complexes.
La résolution des conflits est de la responsabilité de l'analyste.
Les dépendances cachées se révèlent par le modélisation et les communications.

Questions pièges.

La priorisation des exigences est-elle un moyen de résoudre les contradictions ?

Non, la priorisation est un ordre de mise en œuvre. Les contradictions doivent être résolues avant leur intégration dans le backlog, par consensus, compromis ou révision des exigences.

Peut-on identifier toutes les relations uniquement par des outils automatiques ?

Non, l'automatisation (par exemple, des outils de traçabilité) aide, mais les sens commerciaux enfouis, les subtilités des processus et les conflits cachés ne sont enregistrés que par des discussions avec de réels parties prenantes.

Le fait que les exigences se chevauchent signifie-t-il qu'une d'elles est forcément de trop ?

Non, les exigences peuvent se chevaucher en termes de formulations, mais avoir des objectifs finaux différents. Il est nécessaire de vérifier le sens et de rechercher des opportunités pour leur agrégation ou leur révélation.

Erreurs courantes et anti-modèles.

Fusion hâtive des exigences contradictoires (en supprimant une, les scénarios commerciaux se brisent).
Non-fixation des liens - lors des modifications, les anciennes exigences se "perdent" et sont violées.
S'appuyer uniquement sur la documentation sans communications en direct.

Exemple de la vie réelle

Cas négatif : Dans un CRM bancaire, deux départements ont indépendamment demandé à mettre en place "une recherche rapide de clients". Les exigences ont été mises en œuvre séparément, sans identifier de duplications - ce qui a conduit à l'émergence de deux recherches différentes, avec des scénarios confus.

Avantages :

Satisfaction de chaque département séparément

Inconvénients :

Incohérence de l'interface
Augmentation du support
Coût du projet accru

Cas positif : L'analyste a organisé des ateliers avec des fragments clés des exigences, une matrice de dépendance, a itérativement validé les scénarios avec les clients et les exécutants.