Module 3 : Rédaction des exigences

À la fin de ce module, vous devriez être en mesure de:

 Décrire les exigences dans en utilisant les 12 principes Agile.
 Créer un user story et reconnaître le format d’un user story.
 Évaluer ce qui rend un user story bon.
 Reconnaître quand un user story est trop grande (en d'autres termes, vous devriez être capable de
reconnaître une histoire d'utilisateur (user story) épique), et pourquoi cela est susceptible de se produire
dans la spécification du user story.
 Créer un test d'acceptation pour les user stories sur la base des critères d'acceptation.
 Expliquer ce qu'est un backlog de produit et comment il peut aider à prioriser les user stories.
 Décrire ce qu'est le backlog de produit et comment il fonctionne dans le cadre de Scrum.
 Créer une story map et identifier les avantages de l'utilisation d'une story map.
 Identifier les histoires d'utilisateurs manquantes ou incohérentes dans une story map.*

Comme nous venons de le voir au module 2, les exigences peuvent être exprimées par des techniques telles que
les cas d'utilisation, les wireframes et les storyboards, mais elles peuvent également être exprimées dans de
nombreux formats écrits.

Exigences agiles
Les besoins et les exigences du client peuvent être exprimés dans le cadre de la philosophie du développement
agile de logiciels. Le développement agile de logiciels repose sur 12 principes. Ces principes s'appuient sur la
croyance de la méthode Agile selon laquelle les logiciels sont dynamiques. En d'autres termes, dans la
méthode Agile, le logiciel est dynamique. En d'autres termes, dans la méthode Agile, le logiciel ne peut pas être
simplement défini une fois, puis créé à partir de cette définition singulière - il est en constante évolution.
Conformément à cette philosophie, les clients changent souvent d'avis sur les fonctionnalités du produit. Cela
peut se produire même au cours du développement. Dans le cadre d'un développement logiciel agile, cependant,
l'évolution des besoins doit être accueillie favorablement et attendue, les changements d'exigences doivent être
accueillis favorablement et attendus. La capacité à accueillir des exigences changeantes peut faire la différence
entre la réussite ou l'échec d'un projet. Les équipes de développement doivent comprendre que, bien que les
exigences soient créées avec la ferme intention de les respecter, elles changent inévitablement.

12 principes de la méthode Agile

Ces principes sont les suivants. Nous résumons la version anglaise dans à la figure 1 tirée du site
https://agilemanifesto.org/
1. Toujours satisfaire le client à travers des livraisons rapides et continues
2. Bien accueillir tous les changements même les tardifs
3. Livrer fréquemment un système fonctionnel
4. Les clients et les développeurs doivent collaborer
5. Conduire le projet autour d’équipes motivées
6. La meilleure méthode de faire circuler l’information c’est le contact direct entre collaborateurs
7. La première mesure d’avancement c’est un logiciel fonctionnel
8. Le développement doit être durable et à un rythme constant
9. La bonne conception et l’excellence technique augmentent l’agilité
10. Simplifier au maximum
11. Les meilleurs architectures, besoins et conceptions proviennent d’équipes qui s’organisent d’elles mêmes
12. L’équipe s’améliore d’une manière autonome et régulière

Page 1 sur 11
IUT de Ngaoundéré-Ndam Njoya Arouna- 2021
 Figure 1 : 12 Principes agile
Selon la méthode Agile, les interactions en face à face avec les clients sont essentielles pour s'assurer que les
exigences sont correctes, même si elles changent. Les exigences doivent être formulées dans un cadre ouvert et
collaboratif, comme l'explique la section Élire les exigences. Bien que la vision du produit vient du client, les
gestionnaires de produits logiciels aident souvent à préciser cette vision et à définir les exigences qui entrent
dans le cadre du projet. Ces réunions sont également l'occasion de discuter des changements inévitables dans
les exigences. Cette méthode est fréquemment utilisée par la méthode Scrum.
Les exigences font partie intégrante de la méthode Agile. Si l'on suit la méthode agile pour créer les exigences, la
qualité s'en trouve améliorée.

Page 2 sur 11
IUT de Ngaoundéré-Ndam Njoya Arouna- 2021
User Stories
Les User stories sont une technique majeure utilisée pour exprimer les exigences, comme les cas d'utilisation,
les wireframes et les storyboards. Les User stories sont spéciales parce qu'elles utilisent un format cohérent
pour exprimer les exigences qui est facile à écrire, à lire et à évaluer.
Le format des User stories est le suivant:

En tant que "qui", je veux pouvoir "quoi", afin que je puisse "pourquoi".
Le "qui" de l'exigence est le rôle de la partie prenante pour laquelle l'exigence est formulée. L'exigence doit être
rédigée comme si elle était du point de vue de cette personne.
Le "quoi" de l'exigence est la tâche spécifique ou la fonctionnalité que la partie prenante veut réaliser en utilisant
le produit.
Le "pourquoi" de l'exigence met en évidence les objectifs ou les visions du produit et donne un aperçu de la
valeur ou du bénéfice du produit.
Un exemple de récit d'utilisateur basé sur l'exemple du restaurant utilisé précédemment dans ce cours pourrait
être : "En tant que client, je veux pouvoir identifier les restrictions alimentaires, afin de savoir si
je peux manger les plats que je commande."
Les user stories sont utiles, car elles fournissent un moyen clair et structuré d'exprimer une exigence
qui n'utilise pas trop de détails techniques. Contrairement aux exigences formulées librement, les
histoires d'utilisateurs garantissent que le "qui", le "quoi" et le "pourquoi" d'une exigence sont
toujours pris en compte. Les histoires d'utilisateurs sont également utiles parce qu'elles sont courtes et
peuvent être facilement écrites sur des cartes d'index ou des notes autocollantes.

Cartes d'index

Classiquement, les histoires d'utilisateurs étaient écrites sur des cartes d'index. Le recto de la carte
contenait l'histoire de l'utilisateur et le verso les critères d'acceptation, que nous aborderons plus tard.

Si vous avez des doutes sur la taille d’un user story, essayez de l'écrire sur une carte d'index dans le
format de la figue 2. Si vous avez du mal à faire tenir vos idées, essayez de les reformuler pour
qu'elles soient plus claires et plus concises.

Figure 2: Format d’index user story

Page 3 sur 11
IUT de Ngaoundéré-Ndam Njoya Arouna- 2021
Méthode INVEST

Les User stories peuvent être évaluées à l'aide de la méthode INVEST. Un user story d'utilisateur
décrit une exigence logicielle spécifique du produit

Tableau 1: La technique INVEST

I Indépendant
Cela signifie que l'exigence peut exister en dehors d'autres user stories et rester
significative. Autrement dit, lorsque le client peut en toute liberté décider de l’ordre dans
lequel les scénarios sont implémentés, sans qu’interviennent des contraintes techniques,
il est plus facile de réorganiser les exigences si nécessaire.
Bons exemples : « Je peux consulter la liste des factures émises » ;« Je peux trier les
factures par date » ; « Je peux consulter la liste des clients ».
Mauvais exemples : « Créer un contrôle permettant d’afficher des listes avec tri sur une
colonne quelconque » ; « Créer la liste des factures » ; « Créer la liste des clients ».
N Négociable
Les user stories doivent également être suffisamment générales pour que l'équipe de
développement et le client puissent travailler autour de leur mise en œuvre. Elles ne
doivent pas se concentrer sur des détails techniques spécifiques. Ils doivent plutôt se
concentrer sur les aspects les plus importants des exigences, tout en gardant à l'esprit
qu'ils peuvent changer. Un bon scénario fait état d’un objectif à atteindre, les détails
d’implémentation pouvant être négociés en cours de route entre clients et développeurs.
Bon exemple : « Je peux connaître le montant total des factures impayées ».
Mauvais exemple : « Lorsque je clique sur le bouton "Total", une ligne est rajoutée à la
liste des factures avec le montant total des impayés ».
V Vertical
Les user stories doivent apporter de la valeur au client. Un bon scénario décrit une
fonctionnalité complète de l’application, dont le client peut en soi apprécier l’intérêt.
Lorsqu’il concerne une seule « couche » de l’application, on parle de scénario horizontal,
il faut alors chercher un meilleur découpage.
Bon exemple : un découpage qui fait apparaître comme scénarios distincts les différents
services rendus par le module de facturation.
Mauvais exemples : « Créer le modèle d’objets métier correspondant à la facturation » ;
« Créer l’interface graphique pour les fonctions de facturation » ; « Créer le schéma de
base de données pour la facturation ».
E Estimé
Il doit être possible d'estimer le temps nécessaire à la conception et à la mise en œuvre
de l'exigence contenue dans le récit de l'utilisateur. Pour que les scénarios client puissent
servir de base à la planification, on doit connaître leurs coûts d’implémentation, ou au
moins une estimation. S’il est difficile de donner une estimation, c’est que le scénario est
trop vague.
Bon exemple : « Implémenter les règles métier R1, R2 et R3 ».
Mauvais exemple : « Garantir le respect des règles de gestion selon la législation en
vigueur. »
S Suffisamment petit
Toujours pour faciliter la planification, un user story doit être petite parce qu'elle est
destinée à être développée dans un court laps de temps. Si le temps nécessaire à la
conception et à la mise en œuvre d'une exigence est incertain, le user story est
probablement trop volumineuse. Il doit donc être décomposée
Mauvais exemple : « Réaliser le module de facturation ».
T Testable
Les user stories doivent être vérifiables par rapport à un ensemble de critères afin de
déterminer si elles sont "faites", ce qui signifie que le user story a accompli ce qu'elle

Page 4 sur 11
IUT de Ngaoundéré-Ndam Njoya Arouna- 2021
 avait prévu de faire et qu'elle ne nécessite pas de travail supplémentaire. Le Teste est un
excellent moyen pour s’assurer que tout le monde, client et développeurs, comprend
ce que recouvre un scénario consiste à se demander comment on va le tester. Une
question qu’il est utile de poser : « Le développeur nous dit qu’il vient de réaliser le
scénario en moins de cinq minutes ; on pense qu’il se fiche de nous. Comment le prendre
en défaut ? »

User stories épiques

Si un user story contient des descriptions trop vagues ou trop larges, et s'il est difficile d'estimer
combien de temps cela prendra ou comment cela peut être fait, il s'agit probablement d'une histoire
d'utilisateur épique. Les histoires d'utilisateurs épiques se produisent généralement au début d'un
projet, lorsque le produit est encore en cours de développement et qu'il n'a pas encore de forme
définie. Cela est dû au modèle connu sous le nom de "cône d'incertitude" qui suggère que les
estimations de temps pour développer une histoire d'utilisateur deviennent de moins en moins
précises au fur et à mesure que l'on s'éloigne dans le temps de la fonctionnalité prévue pour être
développée.

Exemple d'un user story épique :

« En tant que client, je veux payer ma facture pour pouvoir régler rapidement ce que je dois. »

Ce user story pourrait être décomposée en plus petites, comme par exemple :

 "En tant que client, je veux pouvoir voir une facture, avec tous les articles de la commande,
afin de savoir combien ma commande va coûter.
 "En tant que client, je veux pouvoir sélectionner l'option "payer maintenant" lorsque je
consulte ma facture, afin de pouvoir la payer immédiatement.
 "En tant que client, je veux pouvoir entrer mes coordonnées de paiement pour les cartes de
crédit VISA et MasterCard, afin de pouvoir payer par un moyen pratique.

Tests d'acceptation
Un test d'acceptation est utilisé pour vérifier si les exigences d’un user story ont été remplies. Les
tests d'acceptation sont souvent utilisés dans la partie testable de la technique INVEST. Une histoire
d'utilisateur est considérée comme satisfaite si le test est réussi.
Les tests de performance sont évalués sur la base d'un ensemble de critères d'acceptation. Les
critères d'acceptation sont des conditions simples et spécifiques utilisées pour vérifier si une histoire
d'utilisateur a été mise en œuvre correctement.
Les critères d'acceptation sont généralement déterminés par les besoins spécifiques du client. Afin de
transformer les critères d'acceptation en un test d'acceptation, il est utile de passer en revue les
étapes des critères.
Chaque test doit évaluer une condition vérifiable qui constitue une petite partie d’un user story. Si
tous les tests sont réussis, le critère d'acceptation l'est également, alors la user story est considérée
comme étant tester avec succès.
Exemple du Restaurant
En se basant sur l'exemple du restaurant utilisé tout au long de ce cours, des exemples de critères
d'acceptation pour le user story "En tant que client, je veux pouvoir entrer mes coordonnées de
paiement pour les cartes de crédit VISA et MasterCard, afin de pouvoir payer par un moyen
pratique" incluent :
 Le paiement peut être effectué avec une carte de crédit VISA.
Page 5 sur 11
IUT de Ngaoundéré-Ndam Njoya Arouna- 2021
  Le paiement peut être effectué à l'aide d'une carte de crédit MasterCard.
 Le paiement peut être effectué à l'aide d'un service financier en ligne.
 Lors d'un paiement par carte de crédit, le fait de remplir le champ "numéro de carte" permet
de détecter automatiquement le type de carte.
 Le client ne voit que les champs de saisie pertinents, en fonction de la méthode de paiement
sélectionnée.
Pour transformer un critère en test d'acceptation, il est utile de créer quelques étapes. Par exemple,
pour "Le paiement peut être effectué au moyen d'une carte de crédit VISA" les tests pourraient
être les suivants :
 Insérer une carte VISA dans un lecteur de puce.
 Saisir le code PIN de la carte VISA.
 Confirmer que le paiement a été accepté.
Ces étapes permettent de vérifier le critère d'acceptation
Les tests d'acceptation présentent de nombreux autres avantages. Ils permettent à l'équipe de
développement de voir les exigences du point de vue de l'utilisateur. Ils aident également à
déterminer la fonctionnalité du produit, car ils fournissent des détails qui ne figurent pas dans le récit
de l'utilisateur. Ces détails peuvent aider à définir les tâches du développeur et la manière dont elles
peuvent être achevées. Les tests d'acceptation permettent également d'éviter les user stories épiques.
Un nombre excessif de critères d'acceptation suggère qu'un user story devrait être divisé en plusieurs
parties.
Comme les user stories, les tests d'acceptation doivent être développés par le client avec l'aide du
chef de produit et de l'équipe de développement.

Backlog du Produit
Un product Backlog est un ensemble ou une liste de fonctionnalités logicielles que le responsable du
produit logiciel et l'équipe de développement prévoient de développer pour un produit au cours d'un
projet. Il s'agit d'un moyen d'organiser le travail, de hiérarchiser les tâches au sein du projet et de
planifier ces priorités. Les product Baclogs sont une technique populaire car ils offrent une grande
flexibilité aux clients et aux équipes de développement. Ils proviennent de Scrum et donc de la
philosophie Agile.
Les caractéristiques des product Baclogs comprennent les tâches de travail (travaux physiques qui
doivent être effectués dans le cadre du projet mais qui ne sont pas nécessairement liés au
développement des caractéristiques du produit), les tâches de connaissance (travail sur des parties
du projet qui doivent être apprises), les bugs (erreurs dans le code du produit) et, le plus souvent, les
user stories. Toutes les tâches des product Baclogs tendent à s'affiner au fil du temps.
Pour créer un product Baclog, les user stories doivent être placées dans une liste. Chaque user story
doit également se voir attribuer un identifiant unique. Les identifiants peuvent être de simples
numéros séquentiels.
L'étape suivante de la création d'un product backlog consiste à classer les user stories et les
caractéristiques par ordre de priorité. Le processus de hiérarchisation aide les clients à identifier leurs
besoins et leurs souhaits. Il donne également aux développeurs une perspective et une orientation en
mettant en évidence ce qui est le plus important dans un projet. L'établissement de priorités permet
également de déterminer quelles fonctionnalités peuvent être réalisées dans le cadre d'un projet,
compte tenu de la technologie et des ressources disponibles.
La hiérarchisation étant importante pour l'ensemble de l'équipe, il est préférable que les clients, le
responsable du produit logiciel et l'équipe de développement discutent de la hiérarchisation des user
stories dans le product backlog. La raison pour laquelle un user story est important sera plus clair

Page 6 sur 11
IUT de Ngaoundéré-Ndam Njoya Arouna- 2021
 pour tout le monde grâce à ces discussions, de même que la raison pour laquelle une estimation de
l'effort a de la valeur.
À l'aide du product backlog, l'équipe de développement peut commencer à planifier le projet en
utilisant les priorités comme points de référence. Les user stories du backlog de produit sont
regroupées en unités de travail à effectuer à certains intervalles de temps. Dans Scrum, ces
intervalles sont appelés sprints. Les fonctionnalités les plus importantes des backlogs de produits
doivent être terminées plus tôt, tandis que les moins importantes peuvent être terminées plus tard.
Les backlogs de produits sont très flexibles au regard de ce type de développement. Scrum se
concentre sur le développement d'un sprint à la fois. Bien que le sprint en cours de développement ne
doit pas changer, les sprints au-delà de celui sur lequel on travaille peuvent changer. À la fin d'un
sprint, les clients peuvent évaluer le travail effectué et ajouter de nouvelles user stories ou exigences
pour le produit, ou modifier la priorité des user stories ou exigences existantes. Le sprint suivant peut
être ajusté en conséquence.
Les product backlogs évoluent donc au fil du temps et peuvent devenir plus petits, plus grands ou
changer d'ordre. Cette adaptabilité et cette polyvalence sont encouragées par les méthodes agiles.
Le tableau 2 montre un exemple basique du product backlog.
Tableau 2: Product backlog basic

Item Description Priority Notes

As a user, I want to be able to create This feature will allow users to save their settings and
PBI-001 an account High preferences.
As a user, I want to be able to search
PBI-002 for products High This feature will allow users to find what they're looking for quickly.
As a user, I want to be able to add
PBI-003 items to my cart High This feature will allow users to purchase items later.
As a user, I want to be able to view This feature will allow users to see what items they have selected
PBI-004 my cart High for purchase.
As a user, I want to be able to
PBI-005 checkout High This feature will allow users to complete their purchase.
As a user, I want to be able to receive
email notifications about my order
PBI-006 status Medium This feature will allow users to track their package.
As a user, I want to be able to leave
PBI-007 product reviews Medium This feature will allow users to share their experience with others.
As an admin, I want to be able to
PBI-008 manage user accounts High This feature will ensure security and privacy.
As an admin, I want to be able to
PBI-009 manage product listings High This feature will keep the catalog up-to-date.
As an admin, I want to be able to
PBI-010 generate sales reports Low This feature will track the performance of the business.

Page 7 sur 11
IUT de Ngaoundéré-Ndam Njoya Arouna- 2021
 Figure 3 : Product backlog avec user stories Uniquement plus enrichi
Sur la figure 3 :
 Estimation (taille) : Quelle que soit la méthode utilisée pour l'estimation. Il peut s'agir de
points d'histoire, de l'échelle de Fibonacci ou de la taille des t-shirts - petit, moyen, grand.
 Estimation de l'effort : Champ facultatif pour l'estimation de l'effort en heures ou en jours.

La figure 4 montre un exemple d’organisation du product baclog avec les cas d’utilisation. Cet
exemple d’organisation est donné à la figure 5.
Sur la figure 5 :
 Epic ou story épique : story dont l’équipe considère qu’elle est trop grosse pour rentrerdans
un sprint en l’état. Elle ne peut pas passer au statut « prête ».
 Le bac à sable est en quelque sorte l’antichambre du backlog. C’est la boîte d’entrée
danslaquelle tout le monde, y compris les développeurs et les parties prenantes, propose des
stories. Plus exactement, on met dans le bac à sable une idée d’un « truc » à ajouter au
produit, qui pourra éventuellement devenir une story

Figure 4 : Product backlog user stories autour des cas d’utilisation

Page 8 sur 11
IUT de Ngaoundéré-Ndam Njoya Arouna- 2021
 Figure 5 : Product backlog un exemple d’organisation

Story Maps ou Cartes Narratives

Les story maps sont utilisées pour organiser les exigences et aider à structurer un projet. Les story
maps soutiennent le changement à un niveau plus élevé que les backlogs de produits. Elles
présentent les backlogs de produits de manière visuelle, avec des histoires d'utilisateurs regroupées
dans des catégories fonctionnelles spécifiques. En couvrant et en hiérarchisant les histoires
d'utilisateurs dans plusieurs catégories, les story maps fournissent des vues holistiques du produit en
cours de développement.

Page 9 sur 11
IUT de Ngaoundéré-Ndam Njoya Arouna- 2021
Les story maps ont une structure spécifique. Elles sont créées sous forme d'ensembles de colonnes.
Chaque colonne représente une catégorie permettant de regrouper les histoires d'utilisateurs. Dans
chaque colonne, les histoires d'utilisateurs sont classées par ordre de priorité, de la plus importante à
la moins importante. Cette structure permet au client, au responsable du produit logiciel et à l'équipe
de développement de voir les histoires d'utilisateurs les plus prioritaires pour l'ensemble d'un projet.
Alors qu'une liste d'exigences ayant la structure d'un carnet de commandes peut sembler écrasante,
les story maps transforment ces listes en ensembles gérables et organisés de fonctionnalités à mettre
en œuvre au cours d'un projet.
Les figure 6 et 7 sont des exemples de ce à quoi pourrait ressembler la structure d'une story map. La
première étape du story mapping consiste à créer la colonne vertébrale de l’application sur la
première ligne. Les features sont organisées de façon chronologique, en vue de définir un
enchaînement (une chaîne de valeur) logique selon l’usage du produit par ses acteurs. C’est l’axe de
la séquence, qui rappellera les use cases à certains. Ensuite, on part de la feature la plus prioritaire
pour la décomposer en stories dont chacune est enregistrée sur un Post-it. Pour une feature, il peut y
avoir plusieurs stories, jusqu’à une dizaine.

Figure 6: Format d’un story maps

Page 10 sur 11
IUT de Ngaoundéré-Ndam Njoya Arouna- 2021
 Figure 6: Vue partielle d’une story map

Les story maps présentent de nombreux avantages, notamment

 Simplifier la hiérarchisation des histoires d'utilisateurs
 Donner aux backlogs de produits un aspect visuel qui permet d'en suivre l'évolution
 Donner une perspective sur la façon dont les histoires d'utilisateurs peuvent être liées les
unes aux autres
 Aider à identifier ce qui pourrait manquer dans chaque catégorie
 Fournir un contexte aux développeurs en montrant qu'il est préférable de mettre en œuvre
d'autres fonctionnalités simples avant un travail plus complexe
 Fournir une vision holistique du produit en ne permettant pas de se concentrer sur une seule
catégorie, mais en mettant l'accent sur les multiples fonctionnalités (ou catégories) de la
plupart des produits.
 Mieux comprendre comment le produit se développera et s'intégrera au fil des étapes - il est
possible de voir comment un produit évoluera ligne par ligne, ce qui peut faire gagner du
temps au cours du projet.
Les story maps sont un bon exemple du principe Agile de construction d'un logiciel fonctionnel, car
elles mettent l'accent sur des fonctionnalités multiples.
Il est important de rappeler qu'une story map n'est pas un tableau Kanban. Un tableau Kanban,
comme indiqué dans Processus logiciel et pratiques agiles, est un outil visuel utilisé pour afficher l'état
actuel du projet et pour suivre l'avancement des tâches du projet. En revanche, une story map est
utilisée uniquement comme outil de planification et d'organisation des histoires d'utilisateurs.
Cependant, les story maps ne sont pas non plus des plans de développement à part entière.

Page 11 sur 11
IUT de Ngaoundéré-Ndam Njoya Arouna- 2021