Exigences non fonctionnelles revisitées

Des exigences de localisation ou d'utilisabilité représentent des contraintes qui portent sur plusieurs user stories.

J'alimente le backlog de produit d'IceScrum pour la nouvelle release. J'y mets donc des features et des user stories, qui représentent l'aspect fonctionnel. Pour avoir un produit de qualité, je réfléchis aussi aux exigences non fonctionnelles. J'avais fait un billet "que faire avec les exigences non fonctionnelles ?" il y a quelque temps en disant qu'elles devaient aussi aller dans le backlog. Mais ça ne marche pas avec toutes.

IceScrum est un produit utilisé dans le monde entier, il offre 2 langues : en plus du français, l'anglais et l'espagnol. C'est une exigence de localisation. Est-ce qu'elle va dans le backlog de produit ? Non ! En tant qu'utilisateur espagnol, je veux un produit qui parle ma langue serait une story possible, mais elle ne pourrait être faite qu'à la fin quand tout le français serait fait. Or nous voulons que l'espagnol soit fait au fur et à mesure. Chaque fois qu'on ajoute du texte pour une nouvelle user story, il doit être accessible dans les 3 langues.

Chaque user story avec du texte est donc contrainte par cette exigence de localisation. L'exigence "texte en français, anglais et espagnol" doit être connue de tous les membres de l'équipe : développeurs et testeurs. Une façon de la rappeler à tous est de l'inclure dans la définition de fini.

D'autres exigences non fonctionnelles du même genre :

  • compatibilité avec Firefox 2 et 3, IE7 et Safari
  • aide en ligne disponible sous forme de tooltip
  • compatibilité Java6 et Java5

Ces exigences non fonctionnelles nécessitent des tests particuliers, avec éventuellement des environnements spécifiques. Cela peut représenter beaucoup de travail.

Porter à la connaissance de toute l'équipe les exigences non fonctionnelles permet d'éviter les surprises. Pour rester avec IceScrum, j'ai appris fortuitement, lors d'une installation chez un client, qu'il n'était pas compatible avec IE6. Si nous avions mis en évidence, soit dans la définition de fini, soit dans une liste spécifique ce genre de contraintes, il n'y aurait pas eu de surprise.

Et hop, ça fait des stories à ajouter dans mon backlog pour offrir ça dans IceScrum : définition de fini, collecte des exigences non fonctionnelles et des tests associés...