Kōkan

Tour d’horizon des non-functional requirements

De quoi s’agit il ?

Les NFR (Non functional requirements) sont une liste d’exigences qui font partie intégrante du produit. Elles contraignent la création pour être conforme aux besoins du marché, de l’entreprise, de la réglementation ou encore de l’exploitabilité. Traiter ce sujet au plus tôt est la garantie d’avoir un produit fiable, durable et performant.

Ces exigences font partie du cycle de vie du produit, elles sont sous la responsabilité du Product Owner ou Product Manager. Cependant, comme son nom l’indique ce n’est pas fonctionnel. Souvent, ces individus n’ont pas la compétence au début du produit.

Le Scrum Master étant responsable des processus d’ingénierie et de ceux de la société, tel un garde fou, il veille à ce que ces NFR soient prises en compte dès la conception. Pour cela, il utilise différentes postures : Coach, Formateur ou tout simplement il montre l’exemple en faisant. A certains moments, il peut être utile d’imposer pour le bien de l’efficacité du delivery sur le long terme.

Postures du leader
Les postures selon Scrum.org

Dans la majorité des produits nous trouvons ces catégories : Sécurité, Observabilité, Exploitabilité, Maintenabilité, Documentation. La liste de NFR est très longue. Toutes ne seront pas utile pour votre produit mais vous devez le vérifier en interne et par exemple avec les département Sécurité et Production de l’entreprise

Top 10 des Non functional requirements NFR
(Image par Love Sharma)

La matérialisation des exigences

Elles doivent être adressées dès la conception et tout au long de la vie du produit. Les traiter 15 jours avant la mise en production est définitivement à proscrire… Nous les retrouvons tout au long de la chaine de delivery : Durant la maturation des sujets et la définition de l’architecture, pendant le développement et la mise en place de l’infrastructure et, pour finir tout au long du release management.

Ces exigences vont influencer notre produit et donc notre architecture. Un produit attendu sur la performance ou la scalabilité est réfléchi en conséquence. C’est pourquoi les architectes sont présents au plus tôt dans les réflexions.

Elles sont mises en place par l’équipe, que ce soit des sujets d’infrastructure, de applicatif ou de test. En naissent des Enablers qui se retrouvent à tous les étages du backlog : Technical stories, Feature enablers et Epic enablers.

Ces NFR vont contraindre notre delivery, elles intégrent nos processus de réalisation telles des étapes de qualité. Le suivi du respect des exigences non fonctionnelles se retrouve dans les DOD.

Enfin, tous ces éléments sont vérifiés dans l’étape de la conformité du produit. Cette étape est faite sur des environnements de recette ou préproduction. Nous les retrouvons dans la stratégie de test.

A noter, chaque NFR apparaît généralement dans plusieurs domaines mais pas obligatoirement dans chaque.

Tout au long du flux de travail

Le meilleur moyen de traiter ce sujet est de l’intégrer dans notre processus de delivery en sur-couche des exigences habituelles. Les critères de passage de notre système Kanban nous assurent de la bonne prise en compte. Ci-dessous des exemples d’attentes pour un flux donné :

  • Etape “Description du besoin” : initier le document de suivi et indiquer les exigences issues des processus métier
  • Etape “Etude fonctionnelle et technique” : Lister toutes les exigences du Système d’information et donner les premières lignes directrices permettant des les atteindre
  • Etape “Conception équipe & backlog” : Affiner les solutions avec les architectes applicatifs ou équipiers, les intégrer aux travaux dans les backlog et mettre à jour la stratégie de test
  • Etape “Réalisation” : Pas besoin d’un dessin…
  • Etape “Validation” : Vérifier le bon respect des exigences par de l’outillage, de l’audit, des règles
  • Etape “Exploitation” : Utiliser les moyens mis à disposition
Exemple de flux de développement

Tracer et piloter les Non Functional Requirements

Pour nous assurer de la complétude, cette liste de Non functional requirements doit être suivie. Nous préconisons d’utiliser le classique fichier Excel ou Word. Ce choix permet de laisser dans le backlog les travaux à faire et dans le test manager, les scénarios de validation découlant de la stratégie de test.

IdentifiantCatégorieDescriptionFréquence de vérificationMoyens pour vérifierResponsable de la vérificationMode opératoire pour tester
NFR-Securite-001SécuritéRespecter les pratiques OWASP de l’entrepriseChaque déploiementIntégré dans les tests cucumbersQANA : Automatique
NFR-Securite-002SécuritéRestreindre en accès IP les interfaces d’administration 1. …
2. …
3. …
NFR-CA-001Accès aux systèmesSeul l’accès authentifié aux API est autorisé
NFR-Donnees-001Exposition des donnéesSeule l’environnement de production dédient des données sensibles
Créer des jeux de données anonymisés pour chaque environnement hors production

Conclusion

La gestion de Non functional requirements n’est en soit pas quelque chose de compliquée mais il faut s’y atteler.

Seul, le Scrum master ne pourra pas complétement faire ce travail. Nous dépassons le rôle de Scrum Master selon Scrum.org mais nous sommes convaincus qu’il en est de sa responsabilité.

Ce sujet est primordiale dans un produit informatique, il demande de la rigueur et de la communication pour connecter tous les acteurs : Architectes, RSSI, Product manager, Product Owner, le juridique, l’équipe d’exploitation, l’équipe d’infrastructure, l’équipe de réalisation, etc.

Nelson Release train engineer KoKan

Nelson

Nelson commence sa carrière en tant que développeur puis rejoint Xebia en 2016 pour réaliser des produits data et digitaux. 

Durant sa carrière, Nelson intervient dans des entreprises telles que BNP, Galeries lafayette, Société Générale, Orange jusqu’à assumer la direction de l’ingénierie d’une partie du PMU. 

Ses 10 ans d’expérience et son rôle de Release Train Engineer de 14 équipes,  lui ont confirmé l’importance de garder au coeur des préoccupations et à tout niveau de l’entreprise : la qualité logicielle, la mesure (Efficience, Qualité, Produit et Compétence) et le release management.

C’est ainsi qu’il décide de rejoindre le collectif KōKan pour créer le pure player en delivery management regroupant des consultants experts (coach, scrum master et RTE) sur Paris et Rennes.

Publié le 25 avril 2024

Partager :