« NFR (SAFe) » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (2 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 3 : | Ligne 3 : | ||
[[Category: SAFe]] | [[Category: SAFe]] | ||
Auteur : © 2010-2023 Scaled Agile, Inc.<br /> | Auteur : © 2010-2023 Scaled Agile, Inc.<br /> | ||
Source : [https://scaledagileframework.com/ | Source : [https://scaledagileframework.com/nonfunctional-requirements/ Nonfunctional Requirements]<br/> | ||
Date : 13/10/2023 (dernière mise à jour)<br /> | Date : 13/10/2023 (dernière mise à jour)<br /> | ||
---- | ---- | ||
Traducteur : Fabrice Aimetti<br /> | Traducteur : Fabrice Aimetti<br /> | ||
Date : | Date : 29/02/2024<br /> | ||
---- | ---- | ||
Traduction :<br /> | Traduction :<br /> | ||
| Ligne 75 : | Ligne 75 : | ||
<br/> | <br/> | ||
[[Fichier:Nonfunctional Requirements F04.jpg|border|500px|link=]]<br/> | [[Fichier:Nonfunctional Requirements F04.jpg|border|500px|link=]]<br/> | ||
<small>''Figure 4. Les NFR sont capturées dans l'intention de la solution.'' | <small>''Figure 4. Les NFR sont capturées dans l'intention de la solution.''</small><br/> | ||
<br/> | <br/> | ||
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.<br/> | 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.<br/> | ||
| Ligne 93 : | Ligne 93 : | ||
* '''Négociables''' - Le caractère négociable des NFR est un aspect crucial de la performance économique. | * '''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. | * '''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.<br/> | |||
<br/> | |||
Dans de nombreux cas, l'application d'une [https://scaledagileframework.com/set-based-design/ conception basée sur des variantes (''Set-Based Design'')] permet de [https://scaledagileframework.com/assume-variability-preserve-options/ 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é.<br/> | |||
<br/> | |||
Le [https://scaledagileframework.com/take-an-economic-view/#economicframework 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 [https://scaledagileframework.com/supplier/ fournisseurs], et leurs connaissances et intérêts doivent être pris en compte dans les spécifications des NFR et dans le cadre économique.<br/> | |||
<br/> | |||
[[Fichier:1-Take-an-economic-view F06.jpg|border|500px|link=]]<br/> | |||
<small>''Figure 6. Cinq variables guident les décisions de compromis économique pour les NFR.''</small><br/> | |||
<br/> | |||
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. | |||
<br/> | |||
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 [https://scaledagileframework.com/agile-testing 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.<br/> | |||
<br/> | |||
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é.<br/> | |||
<br/> | |||
[[Fichier:Nonfunctional Requirements F07-2.jpg|border|900px|link=]]<br/> | |||
<small>''Figure 7. Les NFR se trouvent dans le quadrant 4 de la matrice de test Agile.''</small><br/> | |||
<br/> | <br/> | ||
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 [https://scaledagileframework.com/system-team/ 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== | ==En savoir plus== | ||
