Exigences non fonctionnelles expliquées : exemples, types, outils

1. Exigences de performance

Les exigences de performance se concentrent sur la rapidité et l’efficacité de tout système. Il définit la rapidité avec laquelle le système doit traiter les demandes de l’utilisateur et y répondre. Les utilisateurs se frustrent souvent en utilisant des systèmes peu performants, ce qui entraîne des taux de rebond élevés.

Exemples (système d’IA générative)

• Le système doit répondre aux requêtes de l’utilisateur dans un délai de 1,2 seconde.
• Lors de la saisie de la requête dans la boîte d’entrée, la latence ne doit pas dépasser 500 ms.

2. Exigences de scalabilité

La scalabilité concerne la capacité du système à croître tout en restant performant. Lorsque les utilisateurs du système ou les demandes de traitement de données augmentent, un système évolutif fonctionne sans avoir besoin d’une reconstruction complète du système.

Les exigences de scalabilité sont importantes pour les entreprises qui acceptent la croissance future ou les pics saisonniers de trafic. Si les exigences de scalabilité sont ignorées, le système peut planter s’il ne peut pas gérer la charge pendant les heures de pointe.

Exemples

• Le système de messagerie devrait continuer à fonctionner de façon fluide même si la base d’utilisateurs passe de 100 000 à 5 millions d’utilisateurs actifs.
• Pendant la vente, la boutique en ligne devrait pouvoir gérer 10 fois le trafic sans aucune dégradation de performance.

3. Exigences de disponibilité

Les exigences de disponibilité décrivent combien de temps le système doit être accessible aux utilisateurs. La grande disponibilité du système réduit considérablement les risques d’arrêt et améliore la confiance de l’utilisateur. Pour certains systèmes, même quelques minutes d’arrêt peuvent entraîner la perte de millions de dollars, d’utilisateurs et de réputation.

Exemple

• Le système bancaire en ligne devrait être disponible 99,95% du temps. Pour les activités de maintenance, le système peut avoir un temps d’arrêt de 30 minutes entre 2 h et 4 h du matin, heure locale.

4. Exigences de portabilité

Les NFR de portabilité concernent la facilité avec laquelle le système peut fonctionner avec différents environnements, y compris les systèmes d’exploitation, les fournisseurs cloud ou les appareils. Un système portable permet d’économiser du temps et des efforts lors du passage du développement à la production ou lors de l’expansion vers de nouvelles plateformes.

Exemples (plateforme de médias sociaux)

• Une application devrait fonctionner sur tous les appareils mobiles.
• Les utilisateurs Android et iOS devraient bénéficier des mêmes fonctionnalités de base.
• Le système devrait être prêt pour conteneurs (par exemple, Docker) afin de supporter un déploiement rapide sur différents environnements cloud comme AWS, Azure ou GCP.

5. Exigences de compatibilité

Les NFR de compatibilité définissent à quel point le système fonctionne avec d’autres systèmes, logiciels ou matériels. Cela est important dans les environnements où le système doit se connecter à des API, des bases de données, des navigateurs ou des services tiers. Une mauvaise compatibilité peut entraîner des fonctionnalités défaillantes, des plaintes des utilisateurs et des problèmes d’intégration.

Exemples

• L’option de partage d’écran dans une application de visioconférence devrait fonctionner sur les navigateurs mobiles et de bureau.
• Un outil de gestion de projet devrait s’intégrer parfaitement à diverses plateformes comme Google Agendas, Slack, etc., sans que les utilisateurs aient à le configurer manuellement.

6. Exigences de fiabilité

Les exigences de fiabilité évaluent à quelle fréquence le système fonctionne sans défaillance, même lors d’événements inattendus. C’est important pour des applications comme les logiciels bancaires, les systèmes de santé, etc., que les gens utilisent quotidiennement.

Exemples (système de gestion des patients hospitaliers)

• Le système devrait fonctionner sans panne pendant 99,95% du temps sur une période de 30 jours.
• Lorsque la connexion à la base de données échoue, le système doit réessayer trois fois pour récupérer automatiquement.
• Lorsque le système plante, il devrait annuler le dernier déploiement pour la récupération.

7. Exigences de maintenabilité

Les NFR de maintenabilité définissent la facilité et la rapidité avec lesquelles le système peut être mis à jour ou corrigé. Il couvre le temps et les ressources nécessaires à la maintenance du système. La maintenabilité est toujours importante dans les projets ou produits à grande échelle en constante amélioration.

Exemples (système CRM pour équipes de vente)

• Tout bug devrait être corrigé dans les 30 minutes.
• Les développeurs doivent pouvoir déployer la nouvelle version ou les mises à jour sans affecter les sessions utilisateur actives.

8. Exigences de sécurité

Les NFR de sécurité définissent comment le système doit protéger et sauvegarder les données sensibles des utilisateurs contre les accès non autorisés, les violations de sécurité et les cyberattaques. Cela inclut principalement la mise en place de mécanismes d’authentification et de chiffrement pour protéger les données.

Exemples (Application de négociation boursière)

• Les données de l’utilisateur doivent être chiffrées lors d’une requête API entre le frontend et le backend du système pour mettre à jour les données.
• Les utilisateurs doivent se connecter en utilisant l’authentification à deux facteurs (2FA) pour toutes les actions financières.
• Le système devrait verrouiller un compte après cinq tentatives de connexion ratées et alerter l’utilisateur par courriel.

9. Exigences d’ergonomie

L’ergonomie met l’accent sur la facilité avec laquelle les utilisateurs interagissent avec le système. Un produit à grande utilisabilité améliore l’expérience utilisateur et peut être adopté par de nouveaux utilisateurs avec une formation minimale. Une mauvaise utilisabilité entraîne de la frustration et augmente les coûts de soutien.

Exemple

• Dans l’application de livraison de nourriture en ligne, toutes les actions majeures (ajouter au panier, appliquer un coupon, recommander) devraient être accessibles en 2 tapotements ou moins sur mobile.

Pourquoi les exigences non fonctionnelles sont importantes : défaillances et leçons réelles

Les équipes de développement produit se concentrent principalement sur les exigences fonctionnelles, mais ne prêtent pas attention aux exigences non fonctionnelles. Les équipes pensent que si la fonctionnalité fonctionne, c’est fini. Cependant, ils ne tiennent pas compte de la performance, de la fiabilité, de la sécurité et d’autres NFR.

Voici comment le fait de sauter des exigences non fonctionnelles a mené à de graves défaillances dans les systèmes réels.

Amazon : Panne pendant le Prime Day (2018)

En 2018, Amazon a subi une panne majeure lors de l’événement Prime Day. Le nombre d’utilisateurs du site a augmenté de façon inattendue, et le système n’a pas pu les gérer. À cause de cela, le site Amazon a planté, et les acheteurs recevaient des messages d’erreur. Amazon a perdu près de 90 à 100 millions de dollars lors de cette panne d’une heure.

Cette panne est survenue à cause d’une mauvaise gestion de la scalabilité. Donc, le système doit toujours être prêt à évoluer dans toutes les situations et doit être disponible la plupart du temps.

Knight Capital : Défaillance du système de trading (2012)

En 2012, Knight Capital a lancé le logiciel de trading sans tests appropriés. Moins de 45 minutes après le lancement, le système a commencé à effectuer de mauvaises transactions qui ont causé à l’entreprise une perte de 440 millions de dollars.

Cette défaillance du système s’est produite parce que la fiabilité logicielle n’a pas été testée correctement, et qu’il n’y avait aucun contrôle de sécurité pour arrêter les actions défectueuses.

TSB Bank : Catastrophe de migration informatique (2018)

TSB Bank au Royaume-Uni a rencontré de sérieux problèmes en 2018 après avoir transféré les données clients vers un nouveau système. La migration des données de l’ancienne plateforme vers la nouvelle plateforme a été un succès. Mais après cela, beaucoup de clients n’ont pas pu se connecter, certains ont vu des informations incorrectes sur leur profil, et quelques utilisateurs ont pu voir les données privées d’autres personnes. Au final, la banque a payé environ 330 millions de livres sterling pour tout réparer et a perdu la confiance des clients.

Les raisons de cette défaillance étaient une faible fiabilité du système et des mesures de sécurité faibles.

Conseils et meilleures pratiques pour rédiger des exigences claires non fonctionnelles

Comme discuté précédemment, les exigences non fonctionnelles sont cruciales pour le succès d’un projet. Cependant, les écrire correctement est un défi. Beaucoup d’équipes rencontrent des erreurs courantes qui peuvent entraîner des retards ou un mauvais comportement du système par la suite. Les équipes devraient suivre les meilleures pratiques ci-dessous pour éviter les erreurs courantes et rédiger de bonnes exigences logicielles.

1. Soyez précis et évitez les termes vagues : Lors de la définition des exigences non fonctionnelles, soyez clair et évitez toute ambiguïté. Par exemple, au lieu de dire « Le système devrait être rapide », dites des choses comme « Le système devrait charger le tableau de bord en moins de 2 secondes pour 90% des utilisateurs. » De cette façon, chaque membre de l’équipe peut comprendre l’objectif clair du NFR.
2. Rendez tous les NFR mesurables et testables : Fixez toujours des métriques ou des fourchettes pour mesurer les critères de réussite. Par exemple, au lieu d’indiquer qu’une application doit avoir une « Haute Scalabilité », disons : « L’application devrait supporter 500 utilisateurs simultanés sans affecter la performance. » Cela aide les équipes à suivre les progrès et à s’assurer que l’application respecte correctement le NFR.
3. Définir les NFR pour les composants du système : Au lieu de définir un NFR particulier pour l’ensemble du système, définissez-le pour le composant spécifique. Par exemple, lors du développement d’une boutique en ligne, vous n’avez pas besoin de définir des exigences de scalabilité pour le panneau d’administration si seulement un nombre fixe d’administrateurs va interagir avec.
4. Collaborez avec toutes les parties prenantes clés : Lors de la définition des exigences non fonctionnelles, impliquez toutes les parties prenantes clés, y compris les développeurs, les testeurs QA, les équipes de sécurité, les architectes, les propriétaires de produits et même les utilisateurs finaux lorsque nécessaire. Chacun a des aspects différents qui peuvent aider à renforcer les NFR.
5. Relier les exigences aux objectifs d’affaires : Chaque NFR devrait avoir un vrai but. Si la disponibilité, la rapidité ou la sécurité aident votre entreprise à gagner de l’argent ou à garder des clients, cela doit être clairement reflété dans vos exigences. Dites « 99,9% de disponibilité pour respecter les engagements de commande en ligne » au lieu de simplement « haute disponibilité ». Cela permet à l’équipe de comprendre pourquoi l’exigence est importante.
6. Regroupez les NFR en catégories : Plutôt que d’avoir une longue liste de NFR, regroupez-les selon les types, comme la performance, la fiabilité, l’évolutivité, etc.
7. Utilisez une mise en page et une terminologie cohérentes : Assurez-vous d’utiliser un format standard pour rédiger les exigences. Vous pouvez définir l’ID des exigences, la description, la priorité et les critères de mesure pour chaque exigence.
8. Utilisez les bons outils pour simplifier le travail : Utilisez les bons outils pour la gestion des exigences. Modern Requirements4DevOps, une solution de gestion des exigences intégrée nativement dans Azure DevOps, offre des fonctionnalités telles que la traçabilité des exigences, la gestion des versions et variantes, la gestion des documents, la gestion des révisions, etc.

Utiliser Modern Requirements4DevOps pour rédiger de meilleurs documents d’exigences non fonctionnels

Documenter les exigences non fonctionnelles est important pour s’assurer que chaque membre de l’équipe et chaque partie prenante ait une compréhension commune des objectifs du projet. Avec une documentation claire, les équipes peuvent minimiser le risque de malentendus, ce qui peut entraîner des remaniements coûteux.

Ici, nous avons introduit quelques fonctionnalités clés de Modern Requirements4DevOps qui peuvent simplifier le flux de travail de création de la documentation des exigences.

1. Smart Docs : Ce module permet aux équipes de créer et de gérer des documents d’exigences vivantes directement dans Azure DevOps. Il offre une interface similaire à Microsoft Word pour rédiger et éditer des documents. De plus, cela permet aux équipes de lier directement les exigences des arriérés aux documents. Ainsi, chaque fois que des données d’exigence sont modifiées, elles seront instantanément reflétées dans le document.