Réponse.

Les exigences fonctionnelles décrivent ce que le système doit faire : opérations commerciales, processus, scénarios utilisateur - c'est-à-dire fonctionnalité.

Les exigences non fonctionnelles définissent comment le système doit fonctionner : restrictions, paramètres de qualité, performance, sécurité, convivialité, etc. Ces exigences influencent souvent le choix des technologies, l'évolutivité et la résilience de la solution.

Pourquoi est-il important de faire la distinction :

• La séparation claire favorise une bonne formulation des tâches pour les développeurs et les testeurs.
• Elle permet d'éviter le passage sous silence de caractéristiques critiques (par exemple, la sécurité, l'évolutivité).
• Les exigences non fonctionnelles non prises en compte deviennent souvent une source d'échec du projet.

Caractéristiques clés :

• Les exigences fonctionnelles concernent le comportement du système.
• Les exigences non fonctionnelles concernent la qualité et les restrictions.
• Les deux types doivent être clairement documentés et approuvés.

Questions pièges.

L’« ergonomie de l'interface » entre-t-elle dans les exigences fonctionnelles ?

Non, c'est un paramètre non fonctionnel (usabilité). Une exigence fonctionnelle serait la présence, par exemple, d'un bouton « Enregistrer », une exigence non fonctionnelle serait la rapidité de sa réponse et sa simplicité d'utilisation.

Peut-on négliger les exigences non fonctionnelles si elles ne sont pas spécifiées par le client ?

Non. L'analyste doit discuter et formaliser même les exigences non fonctionnelles implicites, sinon le risque d'échec du lancement, de plaintes des utilisateurs et de coûts supplémentaires augmente.

« Le système doit être capable de traiter 1000 requêtes par minute ». Est-ce une exigence fonctionnelle ?

Non, c'est une exigence non fonctionnelle - une caractéristique de performance.

Erreurs typiques et anti-modèles

• Focalisation uniquement sur la fonctionnalité ("l'essentiel est que cela fonctionne, la vitesse vient après").
• Formulation implicite des exigences non fonctionnelles - "doit être rapide", "fiable", "sécurisé".
• Ignorer les tests de non-fonctionnalité.

Exemple de la vie

Cas négatif : Le système a entièrement réalisé la fonctionnalité commerciale déclarée, mais en cas de forte charge, il a commencé à "ralentir", car la performance n'a pas du tout été prise en compte. Avantages :

• Développement rapide, exécution précise des scénarios déclarés. Inconvénients :
• Le système n'est pas adapté à une exploitation en conditions de charge réelle, l'entreprise a dû maîtriser d'urgence l'architecture.

Cas positif : L'analyste, en collaboration avec l'architecte et le client, a documenté dans les exigences la charge maximale, les critères de réponse et a effectué des tests de charge. Avantages :

• Le produit fonctionnait de manière stable et supportait la croissance des utilisateurs.
• Les plans de développement prévoyaient l'évolutivité. Inconvénients :
• Au début de la conception, il a fallu consacrer plus de temps à la discussion et aux tests supplémentaires.