Les exigences non fonctionnelles expliquées : exemples, types, outils

1. Exigences de performance

Les exigences de performance portent principalement sur la rapidité et l'efficacité d'un système. Elles déterminent la vitesse à laquelle le système doit traiter les demandes des utilisateurs et y répondre. Les utilisateurs sont souvent frustrés lorsqu'ils utilisent 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 le champ de saisie, le temps de latence ne doit pas dépasser 500 ms.

2. Exigences en matière d'évolutivité

L'évolutivité désigne la capacité d'un système à s'adapter à une croissance tout en conservant ses performances. Lorsque le nombre d'utilisateurs ou les demandes de traitement de données augmentent, un système évolutif continue de fonctionner sans qu'il soit nécessaire de le reconstruire entièrement.

Les exigences en matière d'évolutivité sont essentielles pour les entreprises qui prévoient une croissance future ou des pics de trafic saisonniers. Si ces exigences ne sont pas prises en compte, le système risque de tomber en panne lorsqu'il ne sera plus en mesure de gérer la charge pendant les pics de trafic.

Exemples

• Le système de messagerie devrait continuer à fonctionner sans problème, même si le nombre d'utilisateurs actifs passe de 100 000 à 5 millions.
• Pendant la période de soldes, la boutique en ligne doit être capable de gérer un trafic dix fois plus important sans aucune baisse de performances.

3. Exigences en matière de disponibilité

Les exigences en matière de disponibilité définissent le temps pendant lequel le système doit rester accessible aux utilisateurs. La haute disponibilité du système réduit considérablement les risques d'indisponibilité et renforce la confiance des utilisateurs. Pour certains systèmes, même quelques minutes d'indisponibilité peuvent entraîner des pertes se chiffrant en millions de dollars, ainsi que la perte d'utilisateurs et d'une partie de la réputation.

Exemple

• Le système bancaire en ligne doit être disponible 99,95 % du temps. Pour les opérations de maintenance, le système peut connaître une interruption de service de 30 minutes entre 2 h et 4 h, heure locale.

4. Exigences en matière de portabilité

Les exigences de portabilité (NFR) portent sur la facilité avec laquelle le système peut s'adapter à différents environnements, notamment les systèmes d'exploitation, les fournisseurs de services cloud ou les appareils. Un système portable permet de gagner du temps et de réduire les efforts lors du passage de la phase de développement à la production ou lors de l'extension à de nouvelles plateformes.

Exemples (plateforme de réseaux sociaux)

• Une application doit fonctionner sur tous les appareils mobiles.
• Les utilisateurs d'Android et d'iOS devraient disposer des mêmes fonctionnalités principales.
• Le système doit être compatible avec les conteneurs (par exemple, Docker) afin de permettre un déploiement rapide sur différents environnements cloud tels qu'AWS, Azure ou GCP.

5. Exigences de compatibilité

Les exigences fonctionnelles non fonctionnelles (NFR) relatives à la compatibilité définissent le niveau d'interopérabilité du système avec d'autres systèmes, logiciels ou matériels. Cet aspect est crucial dans les environnements où le système doit se connecter à des API, des bases de données, des navigateurs ou des services tiers. Une compatibilité insuffisante peut entraîner des dysfonctionnements, des plaintes des utilisateurs et des problèmes d'intégration.

Exemples

• La fonctionnalité de partage d'écran d'une application de visioconférence devrait fonctionner aussi bien sur les navigateurs mobiles que sur ceux des ordinateurs de bureau.
• Un outil de gestion de projet doit s'intégrer de manière transparente à diverses plateformes telles que Google Agenda, Slack, etc., sans que les utilisateurs aient à le configurer manuellement.

6. Exigences en matière de fiabilité

Les exigences en matière de fiabilité permettent d'évaluer la fréquence à laquelle le système fonctionne sans défaillance, même en cas d'événements imprévus. Elles revêtent une importance particulière pour les applications telles que les logiciels bancaires, les systèmes de santé, etc., que les utilisateurs consultent quotidiennement.

Exemples (système de gestion des patients hospitaliers)

• Le système doit fonctionner sans défaillance pendant 99,95 % du temps sur une période de 30 jours.
• En cas d'échec de la connexion à la base de données, le système doit effectuer trois tentatives de reconnexion automatique.
• En cas de panne du système, celui-ci doit revenir à la dernière version déployée afin de permettre la reprise.

7. Exigences en matière de maintenabilité

Les exigences non fonctionnelles (NFR) relatives à la maintenabilité définissent la facilité et la rapidité avec lesquelles le système peut être mis à jour ou corrigé. Elles englobent le temps et les ressources nécessaires à la maintenance du système. La maintenabilité revêt toujours une importance particulière dans les projets de grande envergure ou pour les produits faisant l'objet d'améliorations constantes.

Exemples (système CRM pour les équipes commerciales)

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

8. Exigences en matière de sécurité

Les exigences fonctionnelles non fonctionnelles (NFR) en matière de sécurité définissent la manière dont le système doit protéger et préserver les données sensibles des utilisateurs contre les accès non autorisés, les failles de sécurité et les cyberattaques. Elles portent principalement sur la mise en œuvre de mécanismes d'authentification et de chiffrement destinés à protéger les données.

Exemples (application de trading boursier)

• Les données de l'utilisateur doivent être chiffrées lors de toute requête API entre le front-end et le back-end du système visant à mettre à jour ces données.
• Les utilisateurs doivent se connecter en utilisant l'authentification à deux facteurs (2FA) pour toutes les opérations financières.
• Le système doit bloquer un compte après cinq tentatives de connexion infructueuses et avertir l'utilisateur par e-mail.

9. Exigences en matière d'ergonomie

L'ergonomie porte sur la facilité avec laquelle les utilisateurs peuvent interagir avec le système. Un produit très ergonomique améliore l'expérience utilisateur et peut être adopté par de nouveaux utilisateurs avec un minimum de formation. Une ergonomie médiocre engendre de la frustration et augmente les coûts d'assistance.

Exemple

• Dans l'application de livraison de repas en ligne, toutes les actions principales (ajouter au panier, utiliser un bon de réduction, repasser une commande) doivent être accessibles en deux clics maximum sur mobile.

Pourquoi les exigences non fonctionnelles sont importantes : échecs concrets et enseignements tirés

Les équipes de développement de produits se concentrent principalement sur les exigences fonctionnelles, mais ne prêtent pas attention aux exigences non fonctionnelles. Elles estiment que si la fonctionnalité fonctionne, le travail est terminé. Elles ne tiennent toutefois pas compte des performances, de la fiabilité, de la sécurité et d'autres exigences non fonctionnelles.

Voici comment le fait de ne pas tenir compte des exigences non fonctionnelles a entraîné des défaillances majeures dans des systèmes réels.

Amazon : panne technique pendant le Prime Day (2018)

En 2018, Amazon a connu une panne majeure lors de l'événement Prime Day. Le nombre d'utilisateurs du site a augmenté de manière inattendue, et le système n'a pas pu faire face à l'afflux. En conséquence, le site web d'Amazon s'est bloqué et les acheteurs ont reçu des messages d'erreur. Amazon a perdu entre 90 et 100 millions de dollars au cours de cette panne d'une heure.

Cette panne est due à une mauvaise gestion de l'évolutivité. Le système doit donc être en mesure de s'adapter à toute situation et doit être disponible la plupart du temps.

Knight Capital : défaillance du système de négociation (2012)

En 2012, Knight Capital a lancé son logiciel de trading sans l'avoir soumis à des tests adéquats. Moins de 45 minutes après son lancement, le système a commencé à passer des ordres erronés qui ont entraîné une perte de 440 millions de dollars pour l'entreprise.

Cette défaillance du système s'est produite parce que la fiabilité du logiciel n'avait pas été testée correctement et qu'il n'existait aucun dispositif de sécurité permettant d'empêcher les actions défectueuses.

TSB Bank : catastrophe liée à la migration informatique (2018)

Au Royaume-Uni, la banque TSB a connu de graves difficultés en 2018 après avoir transféré les données de ses clients vers un nouveau système. La migration des données de l'ancienne plateforme vers la nouvelle s'est déroulée sans encombre. Cependant, par la suite, de nombreux clients n'ont pas pu se connecter, certains ont constaté des informations erronées dans leur profil et quelques utilisateurs ont pu consulter les données personnelles d'autres personnes. Au final, la banque a dû débourser environ 330 millions de livres sterling pour remédier à ces problèmes et a perdu la confiance de ses clients.

Cet échec s'explique par le manque de fiabilité du système et la faiblesse des mesures de sécurité.

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

Comme nous l'avons vu précédemment, les exigences non fonctionnelles sont essentielles à la réussite d'un projet. Cependant, il n'est pas facile de les formuler correctement. De nombreuses équipes commettent des erreurs courantes qui peuvent entraîner des retards ou un mauvais fonctionnement du système par la suite. Les équipes doivent suivre les bonnes pratiques ci-dessous pour éviter ces erreurs courantes et rédiger des spécifications logicielles de qualité.

1. Soyez précis et évitez les termes vagues : lorsque vous définissez les exigences non fonctionnelles, soyez clair et évitez toute ambiguïté. Par exemple, plutôt que de dire « Le système doit être rapide », précisez : « Le système doit charger le tableau de bord en moins de 2 secondes pour 90 % des utilisateurs. » Ainsi, chaque membre de l'équipe pourra comprendre clairement l'objectif des exigences non fonctionnelles.
2. Veillez à ce que toutes les exigences non fonctionnelles (NFR) soient mesurables et vérifiables : définissez toujours des indicateurs ou des fourchettes pour évaluer les critères de réussite. Par exemple, au lieu d'indiquer qu'une application doit présenter une « grande évolutivité », précisez plutôt : « L'application doit pouvoir prendre en charge 500 utilisateurs simultanés sans que ses performances en pâtissent. » Cela permet aux équipes de suivre les progrès réalisés et de s'assurer que l'application respecte bien les exigences non fonctionnelles.
3. Définir les exigences non fonctionnelles (NFR) pour les composants du système : au lieu de définir une exigence non fonctionnelle particulière pour l'ensemble du système, définissez-la pour le composant spécifique. Par exemple, lors du développement d'une boutique en ligne, il n'est pas nécessaire de définir des exigences en matière d'évolutivité pour le panneau d'administration si seul un nombre fixe d'administrateurs est amené à l'utiliser.
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, notamment les développeurs, les testeurs qualité, les équipes de sécurité, les architectes, les chefs de produit et même les utilisateurs finaux si nécessaire. Chacun apporte un éclairage différent qui peut contribuer à renforcer les exigences non fonctionnelles.
5. Reliez les exigences aux objectifs commerciaux : chaque exigence non fonctionnelle (NFR) doit répondre à un besoin concret. Si la disponibilité, la vitesse ou la sécurité aident votre entreprise à générer des revenus ou à fidéliser ses clients, cela doit clairement transparaître dans vos exigences. Préférez une formulation telle que « une disponibilité de 99,9 % pour respecter les engagements liés aux commandes en ligne » plutôt que de vous contenter de « haute disponibilité ». Cela permet de s'assurer que l'équipe comprend pourquoi cette exigence est importante.
6. Regroupez les NFR par catégories : plutôt que d'avoir une longue liste de NFR, regroupez-les en fonction de leur nature, par exemple les performances, la fiabilité, l'évolutivité, etc.
7. Utilisez une mise en forme et une terminologie cohérentes : veillez à respecter un format standard pour la rédaction des exigences. Vous pouvez définir un identifiant, une description, une priorité et des critères d'évaluation pour chaque exigence.
8. Utilisez les bons outils pour simplifier votre travail : utilisez les bons outils pour la gestion des exigences. Modern Requirements4DevOps, une solution de gestion des exigences intégrée nativement à Azure DevOps, offre des fonctionnalités telles que la traçabilité des exigences, la gestion des versions et des variantes, la gestion des documents, la gestion des révisions, etc.

Utiliser Modern Requirements4DevOps pour rédiger de meilleurs documents de spécifications non fonctionnelles

Il est important de documenter les exigences non fonctionnelles afin de garantir que chaque membre de l'équipe et chaque partie prenante ait une vision commune des objectifs du projet. Grâce à une documentation claire, les équipes peuvent réduire au minimum le risque de malentendus, qui peuvent entraîner des retouches coûteuses.

Nous avons présenté ici quelques fonctionnalités clés de Modern Requirements4DevOps qui permettent de simplifier le processus 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 de spécifications évolutifs directement dans Azure DevOps. Il offre une interface similaire à celle de Microsoft Word pour la rédaction et la modification de documents. De plus, il permet aux équipes de relier directement les spécifications issues des backlogs aux documents. Ainsi, toute modification apportée aux données de spécifications sera instantanément répercutée dans le document.