Réponse.

Historique de la question :

Au départ, l'accent lors de la formalisation des exigences était mis sur les fonctionnalités, mais au fil du temps, il est devenu clair que les critères « invisibles » à première vue (performances, sécurité, tolérance aux pannes, etc.) sont essentiels à la réussite de l'implémentation et à la viabilité des produits. Leur ignorance conduisait à des pannes et à des comportements imprévisibles du logiciel après le lancement.

Problème :

Les exigences non fonctionnelles sont souvent documentées de manière standard, sans étude du contexte. Elles sont mentionnées pour faire « bonne mesure » ou sont formulées de manière trop abstraite, par exemple : « Le système doit être convivial » ou « Le système doit être rapide ». Cela ne donne pas aux développeurs, architectes et testeurs de KPI clairs.

Solution :

L'analyste système organise des sessions avec les affaires, l'IT et les spécialistes de l'exploitation pour identifier les restrictions réelles, enregistre des métriques quantitatives (par exemple, SLA, TPS, indicateurs de latence), décrit les exigences non fonctionnelles de manière explicite dans les spécifications et ensuite garantit leur testabilité en les liant aux cas de test et aux artefacts architecturaux du projet.

Caractéristiques clés :

Utilisation de caractéristiques quantitatives (mesurables !).
Inclusion d'une étape de formalisation et de justification par l'accord avec des experts IT clés.
Liaison des exigences avec les méthodes de test.

Questions pièges.

Peut-on laisser des groupes d'exigences simplement comme « Le système doit être disponible 24/7 » sans détailler ?

Non, il est essentiel de préciser les paramètres de disponibilité (par exemple, 99,95 %) et les conditions de rétablissement.

Est-il suffisant d'indiquer « le temps de réponse doit être rapide » ?

Non, de telles formulations ne fonctionnent pas. Il faut indiquer, par exemple : Temps de réponse < 3 secondes pour 95 % des requêtes avec une charge X.

Les exigences non fonctionnelles sont-elles formalisées si elles ne sont écrites que dans un cahier des charges général sans détail supplémentaire ?

Non, elles doivent être décomposées et liées aux solutions architecturales et aux plans de test, sinon elles resteront irréalisables ou non validables.

Erreurs typiques et anti-patterns

Laisser des formulations floues, empêchant les tests.
Copier les indicateurs requis d'autres projets sans analyser la spécificité.
Ignorer les consultations avec l'IT/SRE et l'exploitation.

Exemple de la vie

Cas négatif : Le projet de e-banking a été lancé avec l'exigence "disponibilité 24/7, fonctionnement rapide", sans préciser le SLA.

Avantages :

Préparation rapide des exigences

Inconvénients :

Pannes fréquentes, disputes irrésolues avec l'outsourcer
Réclamations des clients

Cas positif : L'analyste a travaillé avec le département d'exploitation, a enregistré un uptime de 99,9 %, un temps de réponse max de 2 secondes, a décrit des scénarios de dégradation.