Voici le second article issu de la série d’entretiens que j’ai eu avec plusieurs experts agiles dans l’objectif de divulguer les différences entre les user stories et les spécifications des exigences ainsi que leurs applications dans les systèmes d’informations soumis à la réglementation (par exemple dans le domaine médical). Vous pouvez lire le précédent article de cette série ici

Je discute aujourd’hui avec Johanna Rothman, surnommée la “manager pragmatique”. Johanna réponds et donne des conseils en toute franchise sur les problèmes que vous lui soumettez. Elle aide les responsables à voir les problèmes, à saisir les opportunités, et à supprimer les obstacles. Johanna travaille actuellement à un livre sur le management agile des systèmes d’informations. Elle écrit également des articles dans StickyMinds et dans ProjectManagement.com ainsi que sur ses deux blogs jrothman.com et createadaptablelife.com.

Pensez-vous que “user story” soit juste un terme fantaisiste pour la spécification des exigences ?

Non. Les user stories sont souvent très différentes des spécifications des exigences.

Une user story est un simple scénario. Une spécification des exigences est souvent un recueil d’exigences. Vous pourriez avoir des user stories dans une spécification des exigences, mais pourquoi donc ? Vous ordonnez chaque story dans un backlog, et au fur et à mesure que vous avancez, vous obtenez des retours d’informations sur la story que vous réalisez.

Dans une spécification des exigences, vous tentez de créez toutes les exigences, souvent sous la forme d’exigences fonctionnelles ou non fonctionnelles.

Le problème est que les clients veulent des fonctionnalités, une histoire 1. Ils ne veulent pas des exigences fonctionnelles ou non fonctionnelles. Vous devez expliquer ces exigences sous la forme de métaphores 1.

Comment comparez-vous une user story avec une spécification des exigences ?

Une spécification des exigences est écrite souvent à la forme passive (tout comme je viens juste de le faire). C’est souvent très long. Il est souvent difficile d’en voir la valeur, ou la priorité des exigences à l’intérieur. Si les personnes ordonnent leurs exigences, ils utilisent souvent des termes fourre-tout, comme “doit”, “pourrait”, “serait”, ou d’autres termes dans le même genre. Lorsque nous écrivons des user stories, nous parlons d’un utilisateur spécifique, donc nous écrivons la story sous une forme active. Nous en voyons la valeur. Nous pouvons comparer la valeur d’une story par rapport à une autre.

Pensez-vous que les user stories remplacent les spécifications des exigences ?

Pour moi, elles le font. Pourquoi ne le feraient-elles pas ?

Lorsque vous terminez une story, vous obtenez du retour d’informations. Avec ce retour d’informations, vous pouvez décidez quel sera la story suivante à faire ou vous pouvez en changer.

Ce que je vois le plus souvent c’est que les responsables de produits / les product owners ne demandent pas tout ce à quoi ils pensent comme ils le font dans une spécification des exigences lorsqu’ils utilisent et ordonnent les user stories.

Avec laquelle des deux, préférez-vous travailler avec ?

Je préfère les user stories même lorsque je ne fais pas de l’agile. De cette manière, je vois toujours la valeur et les acteurs dans les exigences et je peux facilement ordonner les exigences.

Laquelle des deux méthodes recommandez-vous dans le cadre de systèmes soumis à la réglementation (c’est-à-dire les systèmes d’informations dans le domaine de la santé, dans les logiciels embarqués d’appareils médicaux) ?

Les user stories. Elles expliquent pour qui sont les exigences, et l’histoire autour de chaque exigence, en plus des critères d’acceptances.

Êtes-vous d’accord avec Johanna ? Tout commentaire et point de vue sont les bienvenus. 2

Le prochain article de cette série sera l’entretien que j’ai eu avec Christiaan Verwijs que vous pouvez retrouver ici. 3


Auteur : Abder-Rahman Ali
Source : The Differences between User Stories and Software Requirements Specification (SRS) – Interview with Johanna Rothman
Date de parution originale : 23 Juillet 2015


Traducteur : Nicolas Mereaux
Date de traduction : 10/02/2016


Licence Creative Commons
Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.


  1. métaphore et histoire - story donc - NdT  2

  2. ou dans votre réseau social préféré, notre site étant dépourvu de commentaires - NdT 

  3. traduit très prochainement - NdT