Réponse.

Historiquement, dans les projets IT, l'attention principale a été accordée aux exigences fonctionnelles : ce que le système doit faire. Pendant ce temps, les questions de performance, de fiabilité, d'évolutivité, de disponibilité, de sécurité et de maintenabilité (ces caractéristiques étant regroupées sous le terme « exigences non fonctionnelles », ENF) sont longtemps restées secondaires et souvent non formalisées.

Problème

Ignorer ou décrire formellement les ENF entraîne des problèmes significatifs dans l'exploitation : le système ne s'avère pas prêt à supporter les charges attendues, ne résiste pas aux cyberattaques, est difficile à maintenir et à évoluer, ou est inaccessible pour le nombre d'utilisateurs requis.

Solution

Un analyste systémique moderne doit initier, formaliser, analyser et documenter les ENF. Cela inclut :

l'interaction avec les architectes, les équipes DevOps et les équipes d'exploitation pour déterminer les contraintes technologiques et d'infrastructure ;
la collecte des exigences de l'entreprise (par exemple, concernant les SLA) ;
la création d'une liste exhaustive des ENF avec des valeurs seuils spécifiques ;
la mise en place de mesures de contrôle lors de la mise en œuvre et du soutien ;
la documentation des exigences dans des sections distinctes de la spécification.

Caractéristiques clés :

Les ENF sont obligatoires pour tout projet de grande envergure.
Elles sont définies conjointement avec des parties prenantes techniques et commerciales.
Elles doivent être claires, testables et liées aux objectifs commerciaux.

Questions pièges.

Quelle est la différence entre "qualité du produit" et "exigences non fonctionnelles" ?

La qualité du produit est un concept plus large, incluant non seulement des paramètres formalisables, mais aussi des évaluations subjectives (par exemple, la convivialité UX/UI). Les ENF sont des caractéristiques mesurables de manière précise (performance, fiabilité, etc.), soumises à une validation automatique.

Un analyste peut-il confier la définition de toutes les exigences non fonctionnelles à l'architecte ?

Non, l'analyste doit conjointement avec l'architecte et l'entreprise identifier ces exigences durant la phase d'analyse, sinon les exigences seront incomplètes ou ne seront décrites que sur le plan technique, sans prendre en compte les besoins commerciaux.

Peut-on formuler des exigences non fonctionnelles uniquement sous forme de phrases générales ("le système doit être fiable") ?

Non, de telles formulations ne sont pas utilisables pour le contrôle et les tests. Une spécification est requise : par exemple, "le temps de récupération du service après une panne ne doit pas dépasser 10 minutes".

Erreurs typiques et anti-patrons

Formulation des exigences sans critères testables ("rapide", "cool", "fiable").
Oubli de classes entières d'ENF (par exemple, sécurité pour les systèmes internes).
Incohérence des exigences entre le client et le support.

Exemple de la vie réelle

Cas négatif : Le projet du portail national des services gouvernementaux n'a pas formalisé les exigences concernant les charges de pointe. Le système "plantait" lors du lancement de services populaires, des incidents de sécurité sont survenus.

Avantages :

MVP rapide

Inconvénients :

Coûts énormes pour les corrections
Perte de confiance des utilisateurs
Difficultés de maintenance

Cas positif : Dès le départ du projet d'usine d'automatisation industrielle, l'analyste a révélé avec l'exploitation que les temps d'arrêt du système étaient plus importants que de nouvelles fonctionnalités. Il a travaillé sur les SLA, les scénarios d'urgence et a spécifié des métriques concrètes.