Réponse.

Historique de la question :

Au départ, dans les projets informatiques, les analystes systèmes se concentraient principalement sur les exigences métier, tandis que les contraintes techniques étaient négligées ou ignorées, ce qui entraînait des solutions non fonctionnelles ou excessivement coûteuses.

Problème :

Les contraintes techniques ne sont pas toujours déclarées - le client peut ne pas en être conscient, le développement peut les omettre, et le résultat peut alors contredire les capacités de l'infrastructure ou des systèmes d'intégration.

Solution :

L'analyste système interroge activement les architectes, DevOps, QA, intégrateurs :

• Il définit les technologies, les dépendances métier et infrastructurelles.
• Il aligne les exigences sur les principes architecturaux : SLA, tolérance aux pannes, évolutivité, limitations de licences ou de sécurité.
• Il fixe et valide les compromis entre les capacités et les désirs du métier.
• Il applique des approches d'analyse basée sur des scénarios et des exigences non fonctionnelles.

Caractéristiques clés :

• Identification précoce des contraintes et des dépendances avec toutes les parties prenantes.
• Documentation des compromis et des contraintes implicites.
• Vérification constante des solutions de projet avec l'architecture de l'entreprise.

Questions pièges.

Peut-on ignorer les contraintes techniques implicites si elles ne sont pas explicitement mentionnées ?

Correct : Non. Les contraintes techniques implicites (par exemple, les délais d'intégration, la limite de taille des messages) nécessitent toujours d'être travaillées et documentées, même si elles ne sont pas exprimées clairement.

L'analyste doit-il participer aux appels/ateliers architecturaux ?

Correct : Oui, l'analyste système est le lien entre le métier et les architectes, il transmet les exigences aux deux parties et documente les décisions.

Suffit-il de collecter uniquement les exigences métier sans analyser les contraintes héritées ?

Correct : Ce n'est pas suffisant. Le code hérité, les licences, les intégrations (legacy) dictent parfois un plus grand nombre de contraintes que les exigences explicitement données.

Erreurs courantes et anti-modèles

• Sous-estimation des contraintes cachées et des dépendances des anciens systèmes.
• Ignorer les règles « non écrites » de l'architecture.
• Documenter uniquement la partie métier sans tenir compte de la faisabilité technique.

Exemple concret

Cas négatif : L'analyste a documenté une intégration basée sur un processus métier, mais n'a pas identifié les limitations de la vitesse de transmission des données dans l'interface.

Avantages : Mise en œuvre rapide des spécifications. Inconvénients : Le système n'a pas supporté la charge, l'entreprise a perdu de l'argent et du temps.

Cas positif : L'analyste a participé à des sessions architecturales, a identifié les limites (maximum de flux = 100, intégration une fois toutes les 10 secondes), et a aligné les limites critiques avec le métier.

Avantages : Solution fonctionnelle, intégration stable. Inconvénients : Il a fallu réduire la fonctionnalité de manière à établir un compromis et justifier cela auprès du client.