Que faire avec les exigences non fonctionnelles ?

Les mettre dans le backlog, comme tout le monde !

Dans le backlog de produit, on met des user stories. La technique des user stories permet d'identifier les exigences fonctionnelles. Mais il y a d'autres exigences[1], qualifiées de non fonctionnelles, parfois d'exigences techniques. Dans OpenUp c'est le terme Supporting Requirements qui est utilisé et c'est mieux que le Supplementary Requirements du RUP.

Cela concerne :

  • les qualités d'exécution comme l'usabilité, la fiabilité, la performance.
  • les qualités de développement comme la maintenabilité, la portabilité...
  • les contraintes de conception, de déploiement, de conformité à des standards...

Le backlog de produit a vocation à contenir tout ce qui apporte de la valeur, le fonctionnel, comme ce qui est non fonctionnel. L'avantage de tout mettre dans le backlog permet d'avoir une source unique, avec des priorités, pour tout ce qu'il y a à faire. C'est maintenant largement reconnu. La difficulté, pour une exigence non fonctionnelle, est de faire en sorte qu'elle soit :

  • faisable en une itération
  • testable

Cela demande souvent à découper une exigence générale en petits morceaux. Ce n'est pas toujours facile mais on y arrive. La technique consiste à se préoccuper des actions possibles pour la vérifier plus que de sa description.

Par exemple :

Plutôt que de dire le logiciel doit être ergonomique (ce qu'on trouve dans des cahiers des charges), on dira, par exemple : en tant que membre de l'équipe, j'accède à mes tâches en 2 clics maximum. Pour une exigence générale comme l'ergonomie, il y aura souvent plusieurs stories non fonctionnelles.
Pour mentionner les exigences de performance on s'efforcera d'exprimer ce qui est vérifiable, comme : en tant qu'utilisateur lorsque je me connecte, j'ai un temps de réponse inférieur à 2 secondes dans 99 % des cas, même s'il y a déjà 50 utilisateurs connectés, en précisant la configuration du serveur sur lequel faire les tests.

Même s'il est réticent, le product owner doit être impliqué dans l'identification de ces stories non fonctionnelles : c'est lui le responsable de ce qu'il y a dans le backlog et il aura à définir les priorités de ces éléments par rapport aux autres.

Notes

[1] le terme exigence, déjà discutable pour évoquer des user stories, l'est encore plus pour du non fonctionnel, car il est bien rare qu'un client ait vraiment des exigences pour des aspects auxquels il ne pense généralement pas du tout

Commentaires

1. Le mardi 29 janvier 2008, 22:25 par jml

Il y a certes les exigences de type fonctionnelle et non-fonctionnelle. Devrait, à mon sens, aussi figurer dans le "product backlog" les elements découverts lors des rétrospectives liés par ex au "Process Improvment".
Ex: le build continu devrait prendre en compte les tests d'integrations

2. Le dimanche 03 février 2008, 19:30 par claude aubry

Ca se discute. J'en ai fait un nouveau billet : le backlog de produit n'est pas une todo liste.