Exigences non fonctionnelles sous forme de User Stories
Le Product Backlog contient les exigences d'un produit. Pour les formuler du point de vue de l'utilisateur, on utilise souvent le format de la User Story. Les exigences fonctionnelles du produit y sont décrites de manière claire et spécifique. Mais qu'en est-il des exigences non fonctionnelles ? Celles-ci devraient également être intégrées dans le Product Backlog. Tu découvriras ici pourquoi les exigences non fonctionnelles sont importantes et comment les intégrer au mieux dans le Product Backlog, par exemple à l'aide du template User Story.
Les différences entre les exigences fonctionnelles et non fonctionnelles
Depuis longtemps, on distingue dans la gestion de produit les exigences fonctionnelles des exigences non fonctionnelles. Cette distinction est également faite dans la gestion agile des exigences. Nous présentons ici brièvement les différences entre les deux.
Exigences fonctionnelles
Ces exigences décrivent des fonctions et spécifications concrètes du produit. Sous forme de User Story, les exigences importantes pour l'utilisateur sont listées de manière aussi précise et complète que possible. Il s'agit d'exigences spécifiques au produit qui, en règle générale, ne peuvent pas être transférées à n'importe quel autre produit. Voici des exemples typiques d'exigences fonctionnelles :
En tant qu'utilisateur d'un logiciel de traitement de texte, je souhaite pouvoir insérer un tableau.
Le programme doit pouvoir calculer la teneur en calories du menu sur la base d'une formule.
Exigences non fonctionnelles
Les exigences non fonctionnelles sont moins spécifiques. Elles décrivent par exemple une qualité, une condition ou une caractéristique du produit. Ces exigences ne sont pas nécessairement spécifiques au produit. Elles peuvent s'appliquer de manière générale à plusieurs produits ou même à l'ensemble du design ou de l'architecture d'un logiciel :
Interface conviviale
Temps de réponse rapides
En raison de leur caractère non spécifique, ces exigences risquent d'être négligées lors de la création du Product Backlog. Pourtant, elles devraient y figurer car elles présentent un grand intérêt pour l'utilisateur. Si la qualité, la fiabilité ou la rapidité ne sont pas adaptées aux besoins des clients, le produit ne sera très probablement pas utilisé, car la fonctionnalité seule ne suffit pas à satisfaire les utilisateurs. C'est pourquoi se pose la question de savoir comment intégrer les exigences non fonctionnelles dans le développement produit. Les formuler sous forme de User Story est utile pour prioriser ce type d'exigences.
Voici comment décrire les exigences non fonctionnelles en Scrum sous forme de User Stories
- Les exigences non fonctionnelles doivent être décrites de manière mesurable
- Considérer les exigences non fonctionnelles du point de vue du client
- L'exigence non fonctionnelle serait-elle peut-être mieux placée dans la « Definition of Done » ?
Les exigences non fonctionnelles doivent être décrites de manière mesurable
Dire que ton site doit avoir un temps de réponse le plus rapide possible est trop vague pour l'équipe de développement. Aucune exigence mesurable n'est décrite ici. « Rapide » est dans ce cas une formulation imprécise que chaque développeur définit différemment.
Dans cet exemple, il est utile pour l'équipe de recevoir des indications précises. Celles-ci peuvent être élaborées ensemble. Un moyen peut être de définir une contrainte concernant l'exigence. Cela rend les caractéristiques plus concrètes et permet de les implémenter sans problème. L'exigence peut par exemple être formulée ainsi :
La page devrait se charger en moins de x secondes.
La dépense calorique doit s'afficher en moins de 8 secondes après le clic.
Considérer les exigences non fonctionnelles du point de vue du client
Lors de la création des User Stories, les participants doivent se mettre à la place du client. Pour rédiger la User Story, il peut être utile de se représenter concrètement le produit à l'aide d'un format :
« En tant que <utilisateur>, je souhaite <objectif>, afin de <raison> »
Ce format simple peut t'aider, toi et ton équipe, à questionner la raison derrière l'exigence. Pourquoi peut-il être important pour un utilisateur que la consommation calorique du menu s'affiche en moins de 8 secondes ? Parce que l'utilisateur dispose ainsi rapidement d'une valeur de référence avec laquelle il peut lui-même planifier la préparation du menu selon son propre emploi du temps.Cependant, tu devrais remettre en question le résultat et considérer la formule uniquement comme un « outil de réflexion ». Si la réponse au « Pourquoi ? » s'avère trop compliquée ou confuse, alors tu devrais chercher le dialogue direct avec le client ou l'utilisateur. Demande aux personnes pourquoi cette caractéristique est personnellement importante pour elles. Parfois, il s'avère qu'une exigence non fonctionnelle n'est pas si peu spécifique que ça, mais simplement formulée de manière imprécise.
L'exigence non fonctionnelle serait-elle mieux placée dans la « Definition of Done » ?
S'agit-il de points transversaux comme par exemple les temps de réponse d'un programme ? Dans ce cas, il peut être judicieux de les intégrer dans la « Definition of Done ». Avec ton équipe et éventuellement les parties prenantes, vous pouvez réfléchir à si un temps de réponse rapide ne devrait pas être un critère fondamental pour l'ensemble du système.
L'intégration d'une exigence non fonctionnelle dans la Definition of Done implique que chaque item doit la respecter. C'est avantageux lorsqu'il s'agit par exemple d'un design et de sa conformité avec l'identité visuelle de l'entreprise ou similaire.
Convertir les exigences non fonctionnelles en exigences fonctionnelles
Les exigences non fonctionnelles peuvent être formulées comme des User Stories, tout comme les exigences fonctionnelles. Et c'est d'ailleurs ce qu'il faut faire pour éviter qu'elles ne soient oubliées ou négligées. L'important est qu'elles soient formulées de manière mesurable et délimitées d'une façon ou d'une autre. Si tu n'arrives pas à définir toi-même ces limites, la formule présentée plus haut peut t'aider. Elle pose la question du « Pourquoi ? » et peut ainsi te servir de guide de réflexion. Sinon, l'échange direct avec ton équipe, les utilisateurs ou les parties prenantes sera toujours utile.
Tu trouveras des premières informations sur Scrum et les User Stories sur notre site web. Tu souhaites acquérir des connaissances approfondies sur Scrum ? Alors inscris-toi à une formation Scrum et apprends les bases du travail agile !
