NFR (SAFe)

Auteur : © 2010-2023 Scaled Agile, Inc.
Source : Nonfunctional Requirements
Date : 13/10/2023 (dernière mise à jour)

---

Traducteur : Fabrice Aimetti
Date : 29/02/2024

---

Traduction :

Le diable est dans les détails.

- Proverbe populaire.

NFR (Exigences non fonctionnelles - Nonfunctional Requirements)

Les exigences non fonctionnelles (NFR) sont des qualités du système qui guident la conception de la solution et servent souvent de contraintes dans les carnets de commandes concernés.

Contrairement aux exigences fonctionnelles, qui spécifient la manière dont un système répond à des exigences spécifiques, les exigences non fonctionnelles sont utilisées pour spécifier diverses qualités et attributs du système, tels que :

• Performance : la rapidité avec laquelle un système doit répondre aux demandes
• Scalabilité : la capacité d'un système à gérer une augmentation du nombre d'utilisateurs ou de la charge de travail.
• Sécurité : dans quelle mesure un système protège-t-il contre les accès non autorisés et les violations de données ?
• Utilisabilité : facilité d'utilisation d'un système
• Maintenabilité : facilité de mise à jour et de modification du système.

Les NFR sont des qualités et des contraintes persistantes qui sont généralement réexaminées dans le cadre de la définition du fini (DoD) à chaque itération, PI ou version. Les NFR influencent les backlogs des équipes, de l'ART, du Solution Train et du Portefeuille.

Description détaillée

Les exigences non fonctionnelles (NFR) sont destinées à spécifier les "qualités du système", divers attributs du système qui ne sont pas directement liés à ses fonctionnalités. Ces attributs ne disent pas ce que le système fait, mais comment il le fait. En revanche, les exigences fonctionnelles sont exprimées sous la forme de Capabilities, de Features et de Stories, qui définissent ce que le système fait en réponse à diverses entrées. Bien qu'elles puissent sembler subtiles, les NFR sont tout aussi vitales pour garantir la réussite du système. Le non-respect des NFR peut se traduire par des systèmes qui ne répondent pas aux besoins de l'entreprise, des clients, du marché ou des réglementations ou normes applicables. Dans certains cas, la non-conformité peut entraîner des problèmes importants, tels que des coûts, des mesures de rappel, la protection de la vie privée, la sécurité, des risques pour la santé, des risques juridiques et bien d'autres encore.

L'identification et la mise en œuvre correctes des NFR sont essentielles. La solution peut être trop coûteuse ou non viable si elles sont sur-spécifiées. En cas de sous-spécification, le système risque d'être inadapté à l'usage auquel il est destiné. Quelle que soit la portée du système, une approche adaptative et incrémentale de l'exploration, de la définition et de la mise en œuvre des NFR est une compétence vitale pour les équipes Agile.

Les NFR contraignent les Backlogs

Les NFR sont associées aux backlogs dans l'ensemble de SAFe, comme l'illustre la figure 1. Cependant, elles ne sont pas des éléments d'un backlog. Les éléments d'un backlog vont et viennent au fur et à mesure de leur mise en œuvre. Les NFR sont des contraintes persistantes sur la conception et le développement du système. Par exemple, considérons une exigence telle que "tous les produits de la suite requièrent une authentification unique basée sur SAML". Alors que l'authentification unique est une exigence fonctionnelle, la sélection de SAML (Security Assertion Markup Language) est une contrainte. Tout nouvel élément du backlog nécessitant une fonctionnalité d'authentification doit inclure SAML dans ses critères d'acceptation.


Figure 1. Les NFR concernent tous les backlogs dans SAFe.

Comme les NFR sont des attributs importants de la solution créée par l'Agile Release Train (ART) et les Value Streams, elles influencent les backlogs des Teams, des ART et des Solution Trains. Le backlog du portefeuille peut également nécessiter des NFR, généralement pour des qualités intersolutions (comme les normes réglementaires). Les équipes agiles utilisent des pratiques de qualité intrinsèque pour accélérer les tests NFR et les rendre continus. Les équipes incluent les NFR pertinentes dans leur DoD, les utilisent comme contraintes pour les décisions locales de conception et de mise en œuvre, et assument la responsabilité des tests NFR.

Comme l'illustre la figure 2, les NFR sont modélisées comme des contraintes du carnet de commandes.


Figure 2. Les NFR sont associées aux backlogs et contraignent la conception du système.

Les NFRs peuvent contraindre n'importe quel élément du backlog tel que décrit dans le modèle d'exigences SAFe. La plupart des NFR nécessitent un ou plusieurs tests de qualité du système (idéalement automatisés) pour savoir si le système est conforme à la contrainte.

Types de NFR

D'une manière générale, il existe deux types de NFR : Les qualités des systèmes et les contraintes de conception. Chacun est décrit dans les paragraphes suivants.

Qualités du système

Les NFR sont souvent des exigences architecturales significatives qui décrivent les différents attributs de qualité du système ("-ilités"). Elles sont aussi critiques, voire plus critiques, que les exigences fonctionnelles qui passent par le backlog. En collaboration avec le Product Management et le Solution Management et les équipes, les architectes système et architectes solution sont souvent responsables de l'identification et de la définition des NFR. La figure 3 présente une liste relativement complète des sources de NFR à prendre en compte pendant le développement.


Figure 3. Exemples d'attributs du système pouvant faire l'objet d'une NFR [1].

Contraintes de conception

Outre les -ilités de ces systèmes, un autre type de NFR peut avoir un impact considérable sur la conception du système. Il s'agit des "contraintes de conception", qui limitent la liberté de choix pour certaines options de conception. Voici quelques exemples de contraintes de conception

• La conception du système doit utiliser uniquement des composants matériels provenant de fournisseurs agréés (système cyberphysique).
• L'authentification unique doit utiliser le protocole SAML.
• Les composants open-source doivent être approuvés à l'avance par le service juridique.
• Toutes les données des utilisateurs doivent être cryptées et stockées dans la base de données de l'entreprise.
• Les langages de programmation Java, Python et Javascript sont approuvés pour un usage général. Tout autre langage de développement doit être approuvé au préalable.

Bien entendu, pour favoriser l'innovation, ces langages doivent être aussi peu nombreux que possible et refléter les décisions centralisées qui permettent de réaliser des économies d'échelle, d'assurer la sécurité ou de prendre en compte d'autres aspects essentiels de l'ensemble des solutions.

Les exigences fonctionnelles (NFR) et les contraintes de conception définissent la portée et la qualité du système. En comprenant à la fois les NFR et les contraintes de conception, les équipes peuvent prendre des décisions plus éclairées sur la conception du système, en s'assurant qu'il répond aux besoins des parties prenantes tout en respectant les limitations.

Spécification des NFR

L'intention de la solution comprend les NFR et les exigences fonctionnelles et joue un rôle crucial dans la compréhension de l'économie faite par l'intention de la solution fixe par rapport à l'intention de la solution variable.

L'intention de la solution peut également fournir des liens de traçabilité entre les NFR, les autres éléments de travail sur lesquels elles ont un impact et les tests permettant de les vérifier. Les NFR jouent un rôle crucial dans la compréhension de l'économie de l'intention de solution fixe par rapport à l'intention de solution variable (Figure 4).


Figure 4. Les NFR sont capturées dans l'intention de la solution.

Comme pour les autres exigences, certaines NFR sont fixes et connues à l'avance (ex : le parcours d'aventure peut accueillir douze personnes) ; d'autres sont variables (l'accélération à la charge maximale du véhicule ne doit pas être inférieure à x Gs) et seront affinées au fil du temps.

Comme toutes les autres exigences, les NFR doivent être quantifiées par souci de clarté afin de s'assurer que tout le monde comprend bien l'objectif. La figure 5 donne un exemple de définition d'une NFR à l'aide de certaines des propriétés présentées dans la figure 3 :

• L'étape 1 définit la qualité de la NFR, y compris son nom, son échelle et sa méthode de mesure.
• L'étape 2 quantifie les valeurs mesurables de la NFR, y compris la valeur mesurée actuelle (ligne de base), la valeur à atteindre (cible) et la valeur qui devient inacceptable (contrainte).
  

La figure 5 présente un exemple de spécification d'une NFR pour l'efficacité de la détection de la limite de vitesse d'un véhicule autonome. En moyenne, les utilisateurs règlent actuellement la vitesse manuellement 0,1 fois par kilomètre, ce qui annule la solution automatisée. La nouvelle fonctionnalité du système devrait permettre d'améliorer cette vitesse 0,01 fois par kilomètre, mais ne devrait jamais descendre en dessous de 0,15 fois par kilomètre au cours de la mise en œuvre.


Figure 5. Étapes et exemple de spécification des NFR.

Les critères suivants permettent de définir les NFR :

• Limitées - Les NFR doivent s'inscrire dans un contexte limité spécifique. Par exemple, la fiabilité des commandes de vol d'un avion devrait être beaucoup plus élevée que celle du système d'infodivertissement.
• Indépendantes - Les NFR doivent être indépendantes les unes des autres afin de pouvoir être évaluées et testées sans tenir compte des autres qualités du système.
• Négociables - Le caractère négociable des NFR est un aspect crucial de la performance économique.
• Testables - Les NFR doivent pouvoir être testées à l'aide de mesures objectives.

Les NFR ont un impact sur le développement de solutions

Les exigences non fonctionnelles peuvent avoir un impact considérable sur le développement et le test des solutions. Les architectes et les développeurs doivent donc faire preuve de prudence lorsqu'ils les spécifient. Par exemple, une exigence telle que "99,999 % de disponibilité" peut sembler excellente, mais elle multiplie par 10 les efforts de développement par rapport à une exigence de "99,98 % de disponibilité". L'impact de la NFR doit être bien compris par ceux qui définissent les exigences.

Dans de nombreux cas, l'application d'une conception basée sur des variantes (Set-Based Design) permet de garder les options ouvertes en spécifiant les NFR sous la forme d'une fourchette (par exemple, 99,98 ... 99,999). Les équipes explorent l'espace des solutions et acquièrent des connaissances supplémentaires qui conduisent à de meilleures décisions économiques. Il se peut en effet qu'une fiabilité de 99,999 soit intéressante. Il se peut aussi qu'une fiabilité moindre soit plus rentable si l'on procède à des ajustements ailleurs dans l'environnement opérationnel du système. Les contraintes physiques, telles que le poids, le volume ou la tension, ont un impact similaire sur le développement de solutions. Différer les décisions pour mieux comprendre les coûts et la valeur permet souvent d'améliorer la rentabilité.

Le cadre économique de la solution (figure 6) permet de fournir des critères d'évaluation des NFR. Les NFR doivent prendre en compte les compromis avec les coûts et d'autres considérations. Les NFR affectent également les fournisseurs, et leurs connaissances et intérêts doivent être pris en compte dans les spécifications des NFR et dans le cadre économique.


Figure 6. Cinq variables guident les décisions de compromis économique pour les NFR.

Les NFR peuvent nécessiter des travaux supplémentaires, aujourd'hui ou à l'avenir. Parfois, elles doivent être mises en œuvre en une seule fois. Dans d'autres cas, les équipes peuvent adopter une approche incrémentale :

• En une seule fois - Certaines NFR apparaissent comme de nouvelles contraintes et nécessitent une mise en œuvre immédiate. Par exemple, des changements réglementaires peuvent obliger l'organisation à réagir dans les délais impartis, sous peine d'être en infraction.
• Chemin incrémental, story par story - À d'autres moments, les équipes disposent d'options. Par exemple, les équipes agiles peuvent améliorer les performances de manière incrémentale, une story à la fois.

La mise en œuvre doit se faire de manière à permettre plusieurs cycles d'apprentissage afin de déterminer le bon niveau de NFR. La structure d'un ART peut également avoir un impact sur la mise en œuvre des NFR. Par exemple, les ART organisées autour de couches architecturales auront du mal à mettre en œuvre et à tester les NFR. Les trains dont les équipes sont principalement alignées sur les flux de valeur auront plus de facilité à mettre en œuvre, à tester et à maintenir les NFR. L'application des pratiques de l'architecture agile soutient le développement des NFR et aide à maintenir la flexibilité au fur et à mesure que les exigences évoluent.

Test des exigences non fonctionnelles

Brian Marick, défenseur de XP et co-auteur du Manifeste Agile [3], a été l'un des pionniers des Tests Agiles et de la matrice de test, qui fournit une taxonomie pour l'organisation des tests. Cette approche a été développée dans Agile Testing [4] et mise à l'échelle dans Agile Software Requirements [4, 5]. La figure 7 décrit la dernière matrice [6] avec des conseils sur ce qu'il faut tester et quand.

Le quadrant 4 de la matrice de test agile de la figure 7 décrit les tests de qualité du système pour vérifier qu'il répond aux NFR. Les NFR nécessitent souvent une suite d'outils de test automatisés spécialisés (par exemple, des outils de test de charge et de performance) ou une télémétrie interne de la solution pour valider la conformité.


Figure 7. Les NFR se trouvent dans le quadrant 4 de la matrice de test Agile.

En raison de leur portée considérable et des exigences en matière d'outillage, les tests des NFR peuvent nécessiter l'aide de l'équipe système. Étant donné que toute modification du système peut compromettre la conformité avec les NFR, ces tests doivent être exécutés en continu, ou du moins chaque fois que cela est possible. Pour soutenir cette qualité intrinsèque, les équipes devraient automatiser les tests des NFR afin qu'ils soient exécutés en continu avec d'autres tests ou à la demande lorsque cela est nécessaire.

En savoir plus

[1] Non-functional requirement. Wikipedia. Retrieved October 13, 2023, from https://en.wikipedia.org/wiki/Non-functional_requirement
[2] Gilb, Tom. Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Butterworth-Heinemann, 2005.
[3] Manifesto for Agile Software Development. http://AgileManifesto.org/
[4] Crispin, Lisa, and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley Professional, 2009.
[5] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional, 2010.
[6] Gregory, Janet, and Lisa Crispin. More Agile Testing: Learning Journeys for the Whole Team. Addison-Wesley Professional, 2014.
[7] Leffingwell, Dean, and Ryan Shriver. Nonfunctional Requirements (System Qualities) Agile Style. Agile 2010.