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.

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

La matérialisation des exigences

Elles doivent être adressées dès la conception et non 15 jours avant la mise en production… Nous les retrouvons dans les phases de maturation des sujets, de développement et mise en place de l’infrastructure et architecture et pour finir dans tout le 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.

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 s’assurent de la bonne prise en compte. Ci-dessous des exemples d’attentes pour un flux donné :

Etape “Description du besoins” : 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

Tracer et piloter

Pour nous assurer de la complétude, cette liste est suivie. Nous préconisons le classique fichier excel ou word afin 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.

Conclusion

La gestion de NFR 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 SM 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.