Introduction : Les user stories, ce qu’elles sont et ce qu’elles ne sont pas

Stoppez-moi si vous avez déjà entendu ça : “Les user stories remplacent les requirements traditionnels.” Ou encore : “On n’a pas besoin de spécifications détaillées en Agile, les user stories suffisent !”

Si ces affirmations vous semblent familières, vous n’êtes pas seul. Beaucoup confondent user stories et requirements, pensant que l’un peut se substituer à l’autre. Pourtant, cette confusion peut mener à des erreurs coûteuses : pertes de vision, produits mal alignés sur les besoins réels, ou même échec du projet.

En tant que coach en software craftsmanship, j’ai souvent vu ces malentendus semer la pagaille dans les équipes. Dans cet article, je vais clarifier pourquoi les user stories ne sont pas des requirements, comment différencier les deux, et surtout, pourquoi il est essentiel de partir des requirements pour écrire vos user stories – et non l’inverse.

Voici ce que vous allez apprendre :

1. Les distinctions fondamentales entre user stories et requirements.
2. Pourquoi les requirements sont la fondation essentielle de tout projet.
3. Comment structurer vos user stories à partir de requirements pour garantir un backlog robuste et évolutif.

Vous découvrirez aussi des exemples pratiques en Gherkin, des erreurs courantes à éviter, et des conseils pour articuler vos besoins de manière claire et efficace.

Prêt à structurer votre projet Agile avec méthode ? Allons-y !

Les différences fondamentales entre user stories et requirements

Lorsque l’on parle de user stories et de requirements, on évoque deux artefacts très différents mais complémentaires dans la gestion de projet. La confusion entre ces deux concepts est fréquente, mais elle peut entraîner des erreurs stratégiques importantes. Pour éviter cela, examinons leurs différences principales.

1. User stories : Des artefacts centrés sur l’utilisateur

Les user stories sont des outils agiles, conçus pour capturer les besoins du point de vue de l’utilisateur final. Elles répondent au "quoi" et au "pourquoi" d’une fonctionnalité, en laissant de côté les détails techniques.

Une user story est généralement écrite sous le format classique :

En tant que [type d'utilisateur],  
Je veux [action ou fonctionnalité],  
Afin de [objectif ou bénéfice].

Exemple :

En tant qu’utilisateur inscrit,  
Je veux pouvoir réinitialiser mon mot de passe,  
Afin de retrouver l’accès à mon compte sans assistance.

Caractéristiques clés :

• Simple et compréhensible : Facile à saisir pour toutes les parties prenantes.
• Évolutive : Les détails peuvent être raffinés au fil des sprints.
• Jetable : Une fois implémentées, les user stories sont souvent remplacées par d’autres besoins.

2. Requirements : Une documentation durable et détaillée

Les requirements, ou exigences, représentent une description complète des besoins métier, techniques et organisationnels. Contrairement aux user stories, ils ne se limitent pas au point de vue utilisateur. Ils capturent également des contraintes essentielles, comme la sécurité, la performance, ou la conformité légale.

Un requirement peut se décliner en plusieurs types :

• Fonctionnels : Ce que le système doit faire.
• Non fonctionnels (NFR) : Performance, sécurité, scalabilité, accessibilité, etc.
• Contraintes techniques : Technologies imposées, intégrations tierces.
• Règlementaires : Conformité avec des normes ou lois spécifiques.

Exemple (NFR) :

Le système doit être capable de gérer 10 000 connexions simultanées avec un temps de réponse inférieur à 3 secondes.

Caractéristiques clés :

• Précis et complet : Ils forment une base stable pour la conception et le développement.
• Durable : Contrairement aux user stories, les requirements restent valables même après la livraison.
• Traçable : Ils servent de référence dans tout le cycle de vie du produit.

3. Résumé des différences

4. Pourquoi la distinction est importante

• Les user stories sont des artefacts temporaires conçus pour s'adapter rapidement. Elles permettent une collaboration active pendant un sprint.
• Les requirements sont une documentation pérenne. Ils assurent une vision claire et une traçabilité des besoins sur le long terme.

Piège courant : Partir uniquement des user stories pour définir vos besoins. Cela limite votre vision à court terme et vous expose à des oublis critiques (performance, sécurité, etc.).

Les types de requirements à connaître

Pour construire un produit ou un système solide, il est essentiel de comprendre que tous les besoins ne se valent pas. Ils doivent être regroupés en catégories qui couvrent à la fois les aspects fonctionnels et non fonctionnels. Chaque type de requirement joue un rôle spécifique et garantit que votre produit répond aux attentes des utilisateurs et des parties prenantes.

1. Les requirements fonctionnels

Les requirements fonctionnels décrivent ce que le système doit faire pour répondre aux besoins métiers ou utilisateurs. Ils définissent les fonctionnalités et les comportements attendus d’une application.

Exemple :

Le système doit permettre aux utilisateurs inscrits de télécharger une facture mensuelle au format PDF.

Caractéristiques :

• Centrés sur les fonctionnalités spécifiques.
• Répondent au "quoi" sans nécessairement définir le "comment".

2. Les requirements non fonctionnels (NFR)

Les NFR (Non-Functional Requirements) définissent les qualités et performances attendues du système. Ce sont des contraintes transversales qui affectent tous les aspects du produit.

Types de NFR :

• Performance : Temps de réponse, volume de données supporté.
• Sécurité : Confidentialité, contrôle d’accès, protection contre les attaques.
• Scalabilité : Capacité à supporter une montée en charge.
• Accessibilité : Conformité aux standards d’accessibilité (WCAG, par exemple).
• Maintenabilité : Facilité de correction et d'évolution du code.

Exemple :

Le système doit pouvoir gérer 5000 requêtes par seconde avec un temps de réponse inférieur à 200 ms.

3. Les contraintes techniques

Ces requirements imposent des choix technologiques ou des intégrations nécessaires. Ils définissent des limites sur la manière dont le produit doit être développé ou implémenté.

Exemple :

Le système doit s'intégrer avec le service d'authentification OAuth 2.0 pour la gestion des connexions utilisateurs.

4. Les exigences règlementaires

Ces requirements concernent la conformité à des lois, normes ou régulations spécifiques (ex. RGPD, PCI-DSS).

Exemple :

Toutes les données utilisateur doivent être anonymisées avant d’être stockées pour des analyses statistiques.

5. Les critères d’acceptation : Un pont entre requirements et user stories

Les critères d’acceptation définissent les conditions de succès qui permettent de valider qu’une user story ou un requirement est satisfait. Ils traduisent un besoin en actions mesurables.

Exemple pour une user story :

Scénario : Réinitialisation du mot de passe  
Étant donné un utilisateur inscrit,  
Lorsqu'il demande à réinitialiser son mot de passe,  
Alors il doit recevoir un email contenant un lien valable 24 heures.

Les critères d’acceptation garantissent que les exigences fonctionnelles et non fonctionnelles sont respectées au moment du développement.

6. Pourquoi bien distinguer ces types est essentiel

• Couverture complète : En regroupant vos besoins par catégorie, vous évitez d’oublier des aspects critiques comme la performance ou la conformité.
• Priorisation efficace : Vous pouvez attribuer des priorités claires à chaque catégorie en fonction des besoins métiers.
• Traçabilité : Les NFR et autres contraintes restent valables même si les user stories évoluent ou sont supprimées.

Pourquoi partir des requirements pour écrire des user stories ?

Commencer par les requirements avant de créer des user stories peut sembler contre-intuitif dans un contexte Agile, où l’on valorise la simplicité et l’itération. Pourtant, cette approche est cruciale pour garantir la pérennité, la cohérence et l’efficacité de votre backlog.

1. Les requirements : Une base solide pour tout projet

Les requirements capturent la vision globale du produit. Ils vous permettent de comprendre les besoins des parties prenantes, les contraintes techniques, et les objectifs à long terme.

Pourquoi est-ce important ?

• Vision claire : Les requirements définissent les objectifs du produit et les résultats attendus.
• Réduction des oublis : En documentant les exigences, vous couvrez les besoins critiques qui pourraient être négligés avec une approche uniquement centrée sur les user stories.
• Traçabilité : Vous savez exactement pourquoi chaque fonctionnalité existe et comment elle contribue à vos objectifs.

2. Les user stories : Une traduction actionnable des requirements

Les user stories sont un outil de communication pour les équipes de développement. Elles découlent des requirements et les traduisent en fonctionnalités actionnables et centrées sur l’utilisateur.

Avantages de cette approche :

• Alignement parfait : Les user stories reflètent directement les besoins identifiés dans les requirements.
• Contexte riche : Les équipes de développement comprennent non seulement quoi faire, mais aussi pourquoi cela est important.
• Backlog évolutif : Lorsque les requirements évoluent, les user stories peuvent être mises à jour, ajoutées ou supprimées sans perte de cohérence.

3. Exemple concret : Du requirement à la user story

Requirement :

Le système doit permettre aux utilisateurs de visualiser en temps réel l’état de leur commande (préparation, expédition, livraison).

User Story dérivée :

En tant que client,  
Je veux voir l’état actuel de ma commande,  
Afin de savoir quand la recevoir.

Critères d’acceptation associés :

Scénario : Visualisation de l’état de commande  
Étant donné un client ayant passé une commande,  
Lorsqu’il se connecte à son compte,  
Alors il doit voir un tableau de suivi avec les étapes actuelles de la commande.

4. Les risques d’une approche inversée (user stories avant requirements)

Lorsque vous partez des user stories, vous risquez de créer un backlog :

• Fragmenté : Les user stories manquent de contexte global, ce qui peut entraîner des incohérences.
• Incomplet : Des besoins critiques comme la sécurité ou la performance peuvent être oubliés.
• Rigide : Lorsque les besoins évoluent, il est difficile de mettre à jour les user stories sans perturber l’ensemble.

5. Synthèse : Requirements d’abord pour un backlog robuste

Requirements = Vision globale
Ils garantissent que toutes les parties prenantes sont alignées et que les besoins métier sont bien compris.

User Stories = Action détaillée
Elles traduisent ces besoins en tâches spécifiques à réaliser, prêtes à être planifiées et priorisées.

Pourquoi partir des user stories pour écrire les requirements n’est pas une bonne pratique

Dans de nombreuses équipes Agile, il est tentant de créer des user stories en premier, puis de tenter d'en extraire des requirements pour structurer les besoins. Bien que cela puisse sembler pragmatique à court terme, cette approche mène souvent à des erreurs structurelles qui nuisent à la qualité du produit et à la gestion du projet.

1. Une vision limitée au "comment" au lieu du "pourquoi"

Les user stories sont par nature centrées sur des actions spécifiques d’un utilisateur. Si vous partez des user stories pour définir vos requirements, vous risquez de perdre la vision globale du produit.

Ce qui arrive :

• Les user stories se concentrent sur des solutions immédiates (le comment) au lieu de définir les objectifs métier ou techniques (le pourquoi).
• Les besoins plus larges comme la sécurité, la performance ou la conformité sont souvent oubliés ou sous-estimés.

Exemple :

• User Story mal utilisée comme requirement :

En tant que client,  
Je veux recevoir un email de confirmation après avoir passé commande.

• Ce qui manque :
  • Comment garantir que cet email ne sera pas bloqué par les filtres anti-spam ?
  • Que se passe-t-il si l’envoi échoue ?
  • Est-ce que cet email doit respecter une charte RGPD ?

2. Une perte de visibilité à long terme

Les user stories sont conçues pour être jetables et remplaçables une fois implémentées. Les requirements, eux, doivent persister tout au long de la vie du produit pour garantir une traçabilité et une adaptation continue.

Problème : En partant des user stories, vous créez des artefacts à courte durée de vie, qui ne capturent pas les besoins métiers ou techniques durables. Cela entraîne :

• Des lacunes dans la documentation.
• Une incapacité à justifier certaines décisions après coup.
• Une dette organisationnelle qui se traduit par des efforts supplémentaires pour rattraper ces manques.

3. Une obsolescence rapide des user stories

Les user stories sont souvent impactées par les retours utilisateurs ou les changements d’orientation du projet. Si vos requirements dépendent d’elles, vos besoins documentés deviennent rapidement faux ou incohérents.

Exemple concret :

1. Sprint 1 : Une user story initiale est créée :

   En tant que client,  
   Je veux voir mes commandes passées,  
   Afin de suivre mes dépenses.
   

2. Sprint 3 : Après des retours, cette user story est supprimée ou modifiée. Si vos requirements s’appuient dessus, vous perdez la traçabilité du besoin initial.

4. Un backlog fragmenté et rigide

En partant des user stories pour créer les requirements, vous risquez de structurer votre backlog de manière trop rigide. Chaque story devient un bloc isolé, difficile à modifier ou à adapter lorsque le projet évolue.

Impact :

• Les dépendances entre stories ne sont pas clairement définies.
• Les changements ou ajouts nécessitent une réécriture massive des artefacts existants.
• Vous perdez en agilité, paradoxalement, dans un cadre censé la favoriser.

5. Synthèse : Les erreurs d’une approche "user stories d’abord"

Leçon : Les user stories doivent servir la réalisation des requirements, et non l’inverse.

Conséquences d’une approche "user stories d’abord" avec des exemples détaillés

Lorsqu’on commence par des user stories sans établir de requirements solides au préalable, les problèmes apparaissent rapidement. Cette méthode entraîne des lacunes, une perte de vision, et un backlog de plus en plus difficile à gérer. Voici une illustration des impacts sur 6 sprints, avec des exemples concrets.

1. Sprint 1 : Départ fragmenté

Contexte : Les user stories sont créées directement, sans requirement initial pour définir les objectifs métier ou techniques.

Exemples de user stories créées sans vision globale : 1.

En tant qu’utilisateur,  
Je veux pouvoir m’inscrire avec mon email,  
Afin de créer un compte.

En tant qu’utilisateur,  
Je veux voir mes commandes passées,  
Afin de suivre mes achats.

Ce qui manque :

• Aucun lien explicite entre ces stories.
• Pas de consideration des besoins techniques ou de sécurité (ex : validation de l’email, stockage sécurisé des informations).

Impacts immédiats :

• Fragmentation : Les user stories sont isolées et manquent de contexte.
• Vision limitée : Les développeurs se concentrent sur des tâches spécifiques sans comprendre l’objectif global.

2. Sprint 2 : Premiers ajustements massifs

Contexte : Pendant la livraison, les parties prenantes identifient des lacunes critiques (ex : sécurisation des comptes).

Nouvelles user stories ajoutées pour combler les lacunes : 1.

En tant qu’utilisateur,  
Je veux que mon mot de passe soit crypté,  
Afin de garantir la sécurité de mon compte.

En tant qu’administrateur,  
Je veux que seuls les emails vérifiés puissent accéder au système,  
Afin de prévenir les abus.

Impacts :

• Ajout de nouvelles stories en urgence : Cela perturbe le sprint et surcharge les équipes.
• Développement désorganisé : Les corrections sont ajoutées de manière ad hoc, augmentant la complexité du code.

3. Sprint 3 : Explosion du backlog

Contexte : Les besoins évoluent, et de nouvelles fonctionnalités sont demandées, sans structure pour prioriser ou rationaliser le backlog.

Exemple de backlog désorganisé :

• Stories initiales non modifiées :

En tant qu’utilisateur,  
Je veux voir mes commandes passées,  
Afin de suivre mes achats.

• Nouvelles stories ajoutées pour répondre aux retours utilisateurs :

En tant qu’utilisateur,  
Je veux filtrer mes commandes par date,  
Afin de retrouver une commande spécifique.

En tant qu’utilisateur,  
Je veux recevoir un email lorsque ma commande est expédiée,  
Afin de rester informé.

Impacts :

• Redondances et contradictions : Les nouvelles stories s’empilent sans liens clairs avec les anciennes.
• Complexité croissante : Le backlog devient difficile à naviguer et à prioriser.

4. Sprint 4 : Dépendances invisibles

Contexte : Les développeurs découvrent tardivement des dépendances non identifiées, entraînant des retards.

Exemple de dépendance manquée :

• Une user story implique une fonctionnalité de notification qui dépend d’un système de mise à jour de statut non planifié.

En tant qu’utilisateur,  
Je veux recevoir une notification lorsque ma commande est livrée,  
Afin de savoir qu’elle est arrivée.

Problème : Le système de mise à jour de statut n’a pas été développé au sprint 2, bloquant cette story.

Impacts :

• Délais imprévus : Le sprint doit être réorganisé pour traiter les dépendances.
• Stress sur l’équipe : Les développeurs jonglent entre correctifs et nouvelles stories.

5. Sprint 5 : Obsolescence des stories initiales

Contexte : Les stories créées au sprint 1 deviennent obsolètes ou inutiles en raison des ajustements constants.

Exemple :
La story initiale sur l’inscription devient obsolète car un besoin de connexion via OAuth est introduit :

En tant qu’utilisateur,  
Je veux m’inscrire via mon compte Google,  
Afin de faciliter l’accès au service.

Ce qui arrive :

• Les anciennes stories restent dans le backlog sans être archivées ou mises à jour.
• Le backlog devient confus, avec des artefacts inutiles mélangés aux tâches actives.

Impacts :

• Perte de temps : Les équipes passent du temps à trier et clarifier les artefacts.
• Risque accru d’erreurs : Les développeurs travaillent parfois sur des stories obsolètes.

6. Sprint 6 : Produit incohérent et backlog chaotique

Contexte : Le produit final ne correspond pas aux attentes initiales, et des lacunes subsistent dans des aspects clés comme la sécurité ou la performance.

Exemple d’oubli critique :
Aucun requirement n’a été établi pour gérer des pics de trafic, entraînant des ralentissements majeurs lors de la mise en production.

Impacts :

• Insatisfaction des utilisateurs : Le produit ne répond pas à leurs attentes fondamentales.
• Maintenance complexe : Les équipes doivent corriger des problèmes structurels après la livraison, augmentant les coûts.

Synthèse des problèmes sur 6 sprints

Leçon à retenir : Établir des requirements avant les user stories

• Requirements = Vision globale : Ils garantissent une structure solide, adaptable, et cohérente.
• User stories dérivées : Elles traduisent ces besoins en actions concrètes pour chaque sprint.

Les bénéfices d’une approche "requirements d’abord" avec des exemples détaillés

Pour illustrer concrètement comment une approche "requirements d’abord" peut transformer la gestion de votre projet, nous allons suivre l’évolution d’un backlog structuré sur 6 sprints avec des exemples clairs de requirements, user stories et leurs impacts.

1. Sprint 1 : Des bases solides avec les requirements

Requirement :

Le système doit permettre aux clients de suivre leurs commandes, avec un statut détaillé pour chaque étape : "Préparation", "Expédition", "Livraison".

User stories dérivées :

En tant que client,  
Je veux voir le statut de ma commande dans mon compte,  
Afin de savoir quand elle sera livrée.

En tant qu’administrateur,  
Je veux pouvoir mettre à jour le statut d’une commande,  
Afin que les clients voient l’état correct en temps réel.

Impacts positifs :

• Les dépendances sont identifiées : l'interface client dépend de l’API qui met à jour les statuts.
• Une vision claire permet aux équipes de concevoir une architecture modulaire.

Conséquence : Les équipes entament le sprint avec des objectifs clairs et livrent une première version fonctionnelle de l’interface utilisateur et de l’API.

2. Sprint 2 : Alignement et livraisons cohérentes

Évolution du requirement :

Ajout d’une contrainte non fonctionnelle :

Le système doit mettre à jour le statut des commandes en moins de 5 secondes après l’action de l’administrateur.

Nouvelles user stories dérivées :

En tant que client,  
Je veux voir l’état de ma commande mis à jour immédiatement,  
Afin de suivre son avancement en temps réel.

En tant que développeur,  
Je veux que l’API retourne les mises à jour de statut en moins de 5 secondes,  
Afin de répondre aux attentes de rapidité des utilisateurs.

Impacts positifs :

• L’ajout de ce NFR influence les choix techniques pour optimiser l’API (mise en cache, optimisation des requêtes).
• Les équipes peuvent adapter les user stories tout en respectant le cadre défini par le requirement.

Conséquence : Le sprint livre une API optimisée et une mise à jour rapide des statuts dans l’interface.

3. Sprint 3 : Adaptation fluide aux évolutions

Changement du requirement :

Un besoin métier évolue : permettre aux clients de recevoir des notifications par email lorsque le statut change.

Le système doit envoyer une notification par email au client pour chaque changement de statut.

Nouvelles user stories dérivées :

En tant que client,  
Je veux recevoir un email lorsque ma commande passe en expédition,  
Afin d’être informé sans me connecter au site.

En tant qu’administrateur,  
Je veux que les statuts déclenchent des notifications automatiquement,  
Afin de réduire le temps passé à contacter les clients.

Impacts positifs :

• Le changement dans le requirement est reflété directement dans de nouvelles user stories.
• Les équipes ajoutent un service d’envoi d’emails sans affecter les fonctionnalités existantes.

Conséquence : Les notifications fonctionnent sans impact négatif sur les performances.

4. Sprint 4 : Traçabilité et priorisation simplifiées

Nouvelles priorités sur les requirements :

Les retours des parties prenantes indiquent que la performance globale est critique pour la satisfaction client.

Le système doit être capable de traiter 10 000 commandes simultanées avec un temps de réponse inférieur à 3 secondes.

Nouvelles user stories dérivées :

En tant que client,  
Je veux que l’interface affiche ma commande rapidement,  
Afin de ne pas perdre de temps à attendre.

En tant que développeur,  
Je veux optimiser la base de données pour supporter 10 000 commandes simultanées,  
Afin que le système reste performant sous forte charge.

Impacts positifs :

• Les équipes priorisent les optimisations techniques pour répondre à cet objectif.
• Les tests de charge sont introduits pour valider les performances en production.

Conséquence : Une traçabilité claire garantit que l’objectif métier de performance est respecté.

5. Sprint 5 : Focus sur la qualité

Requirement :

Les critères d’acceptation initiaux sont revus pour inclure des exigences sur la sécurité des notifications par email.

Les notifications par email doivent être envoyées uniquement aux utilisateurs authentifiés, avec un lien unique valable 24 heures.

Nouvelles user stories dérivées :

En tant que client,  
Je veux que les liens dans les emails expirent après 24 heures,  
Afin de garantir la sécurité de mes informations.

En tant que développeur,  
Je veux implémenter des tokens uniques dans les liens d’email,  
Afin de prévenir tout accès non autorisé.

Impacts positifs :

• Des tests automatisés validant les critères de sécurité sont ajoutés au pipeline CI/CD.
• Les équipes s’assurent que la conformité RGPD est respectée.

Conséquence : Le produit gagne en robustesse et en crédibilité auprès des clients.

6. Sprint 6 : Produit pérenne et backlog propre

Requirement :

Les évolutions futures du produit nécessitent de rendre les notifications paramétrables.

Le système doit permettre aux clients de choisir les notifications qu’ils souhaitent recevoir.

User stories dérivées :

En tant que client,  
Je veux pouvoir désactiver les notifications pour certains statuts,  
Afin de limiter les emails reçus.

En tant qu’administrateur,  
Je veux pouvoir activer ou désactiver les notifications par défaut,  
Afin de simplifier la configuration initiale.

Impacts positifs :

• Les user stories obsolètes sont archivées et remplacées par de nouvelles stories alignées sur les objectifs à venir.
• Le backlog reste clair, sans redondances ni contradictions.

Conséquence : Le produit évolue facilement tout en maintenant la traçabilité des décisions initiales.

Synthèse : Pourquoi cette approche garantit le succès

Les critères d’acceptation, leur rôle et leur importance

Les critères d’acceptation sont des éléments essentiels pour garantir la qualité et la validation de vos user stories et requirements. Ils définissent des conditions spécifiques qui doivent être respectées pour qu’une fonctionnalité soit considérée comme terminée et conforme aux attentes. Sans critères d’acceptation clairs, le risque de malentendus et de livraisons incomplètes augmente considérablement.

1. Qu’est-ce qu’un critère d’acceptation ?

Un critère d’acceptation est une règle ou une condition testable, qui décrit comment une fonctionnalité doit se comporter pour être acceptée par les parties prenantes.

Exemple basique (lié à une user story) :
User Story :

En tant que client,  
Je veux recevoir un email de confirmation après avoir passé une commande,  
Afin de m’assurer que ma commande a bien été prise en compte.

Critères d’acceptation :

Scénario : Confirmation de commande  
Étant donné un client ayant passé une commande,  
Lorsqu’il termine le processus de paiement,  
Alors il reçoit un email contenant les détails de sa commande.  

Scénario : Absence d’email pour une commande non validée  
Étant donné un client ayant ajouté des articles à son panier,  
Lorsqu’il abandonne son paiement,  
Alors aucun email de confirmation n’est envoyé.

2. Pourquoi sont-ils importants ?

a) Clarifier les attentes

Les critères d’acceptation traduisent une idée générale en conditions précises. Ils permettent de réduire les malentendus entre les parties prenantes (Product Owners, développeurs, testeurs, etc.).

b) Guider les tests

Les équipes de QA et les testeurs automatisés utilisent les critères d’acceptation comme base pour écrire des tests.

Exemple :
Un test automatisé peut valider qu’un email est bien envoyé ou qu’il contient les informations correctes, comme défini dans le scénario.

c) Servir de définition du "Done"

Ils définissent clairement ce qu’il faut livrer pour que la tâche soit considérée comme terminée.

Astuce : Si vous entendez "mais ce n’était pas prévu comme ça" après une livraison, il est probable que vos critères d’acceptation n’étaient pas assez clairs.

3. Critères d’acceptation pour les requirements

Les critères d’acceptation ne se limitent pas aux user stories. Ils jouent un rôle clé pour valider les requirements, en particulier les besoins non fonctionnels.

Exemple : Critères pour un NFR

Requirement (NFR) :

Le système doit traiter 10 000 requêtes simultanées avec un temps de réponse inférieur à 3 secondes.

Critères d’acceptation associés :

Scénario : Charge normale  
Étant donné 1 000 utilisateurs connectés,  
Lorsqu’ils effectuent des requêtes en parallèle,  
Alors le temps de réponse moyen doit être inférieur à 3 secondes.  

Scénario : Charge maximale  
Étant donné 10 000 utilisateurs connectés simultanément,  
Lorsqu’ils effectuent des requêtes en parallèle,  
Alors le système doit maintenir un temps de réponse inférieur à 3 secondes.  

Scénario : Gestion des pics de charge  
Étant donné un pic soudain à 15 000 utilisateurs connectés,  
Lorsqu’ils effectuent des requêtes,  
Alors le système doit répartir la charge et garantir la continuité de service.

4. Conseils pour écrire de bons critères d’acceptation

a) Soyez précis et testable

Un bon critère d’acceptation doit toujours être mesurable et vérifiable.

• Exemple imprécis : "L’interface doit être conviviale."
• Exemple précis : "L’interface doit charger en moins de 2 secondes sur un réseau 4G."

b) Rédigez-les en langage naturel ou Gherkin

Utilisez un format accessible à tous, comme les scénarios Given/When/Then.

c) Limitez-les à des cas spécifiques

Chaque critère doit couvrir un seul cas ou une seule condition pour éviter toute ambiguïté.

d) Impliquez les parties prenantes

Les Product Owners, développeurs et testeurs doivent collaborer pour s’assurer que les critères reflètent bien les attentes.

5. Impact des critères d’acceptation sur les projets

Exemple complet : Requirement, User Story, et Critères

Requirement :

Le système doit permettre aux utilisateurs de télécharger leurs factures sous forme de PDF.

User Story dérivée :

En tant qu’utilisateur,  
Je veux pouvoir télécharger ma facture mensuelle en PDF,  
Afin de conserver une trace de mes paiements.

Critères d’acceptation associés :

Scénario : Facture disponible  
Étant donné un utilisateur connecté,  
Lorsqu’il accède à sa section "Factures",  
Alors il voit un bouton pour télécharger sa facture du mois en PDF.  

Scénario : Facture absente  
Étant donné un utilisateur sans facture pour le mois en cours,  
Lorsqu’il accède à sa section "Factures",  
Alors un message indique qu’aucune facture n’est disponible.

6. Les pièges à éviter

• Critères vagues : Evitez les phrases comme "doit fonctionner correctement". Soyez précis.
• Trop nombreux ou trop complexes : Limitez le nombre de critères par story pour éviter de surcharger les équipes.
• Manque de collaboration : Écrivez les critères avec les parties prenantes pour capturer toutes les attentes.

Stratégies pour écrire et référencer efficacement requirements et user stories

Un projet réussi repose sur une documentation claire et bien organisée. Une fois vos requirements et user stories définis, l’enjeu est de les structurer et de les référencer de manière efficace pour éviter les doublons, clarifier les dépendances, et faciliter les évolutions futures. Dans ce chapitre, je partage des stratégies éprouvées pour y parvenir.

1. Structurer les requirements et user stories

a) Organisez les requirements par catégories

Séparez vos requirements en grandes catégories dès le début du projet :

• Fonctionnels : Ce que le système doit faire.
• Non fonctionnels (NFR) : Performance, sécurité, accessibilité, etc.
• Techniques : Contraintes d’intégration, choix technologiques.
• Règlementaires : Conformité légale et normes.

Exemple d’organisation :

b) Liens hiérarchiques entre requirements et user stories

Chaque requirement doit avoir des user stories associées pour le traduire en actions concrètes.

Exemple :
Requirement :

RQ-F-001 : Le système doit permettre aux clients de suivre leurs commandes.

User Stories associées : 1.

US-001 : En tant que client,  
Je veux voir un récapitulatif des commandes passées,  
Afin de suivre mes achats.

US-002 : En tant que client,  
Je veux voir l’état actuel d’une commande,  
Afin de savoir si elle est en cours de livraison.

2. Référencement clair avec des identifiants uniques

Pourquoi utiliser des identifiants ?

• Traçabilité : Vous pouvez suivre chaque user story jusqu’à son requirement d’origine.
• Priorisation : Les identifiants aident à regrouper les tâches liées à un même besoin.
• Collaboration : Ils facilitent la communication entre équipes (développement, QA, business).

Format recommandé pour les identifiants :

• Requirement : RQ-Type-Numéro (ex : RQ-F-001 pour un requirement fonctionnel).
• User Story : US-Numéro lié au requirement-Sous-numéro (ex : US-001-1 pour une user story issue de RQ-F-001).

Exemple complet :

3. Outils pour gérer requirements et user stories

a) Utilisez un backlog numérique

Les outils numériques sont essentiels pour gérer efficacement les requirements et les user stories. Ils offrent des fonctionnalités de traçabilité, de collaboration, et de priorisation. Voici quelques options populaires :

1. Jira :
   • Idéal pour gérer des backlogs Agile.
   • Permet de structurer les épics (requirements) et de lier les user stories associées.
   • Fonctionnalités avancées comme les tableaux Scrum et Kanban.
2. Azure DevOps :
   • Intégration directe avec le développement et les pipelines CI/CD.
   • Bon pour des projets techniques avec un suivi précis des tâches.
3. ALM Octane :
   • Spécifiquement conçu pour les environnements complexes.
   • Permet de gérer les requirements, les user stories et les tests dans un seul espace.
   • Très adapté aux équipes travaillant avec des méthodologies hybrides (Agile/Waterfall).
4. Quality Center (Micro Focus) :
   • Outil robuste pour la gestion des tests, mais il excelle aussi dans la gestion des requirements.
   • Idéal pour garantir que chaque requirement est lié à des cas de test validés.
   • Fonctionnalités de traçabilité détaillées pour les projets exigeants (ex. : industrie ou réglementaire).

Astuce : Si votre équipe travaille avec des tests exigeants (ex : tests de conformité ou de sécurité), ALM Octane et Quality Center offrent des intégrations étroites avec les outils de test et garantissent un alignement parfait entre vos artefacts.

b) Intégrez un outil de traçabilité des tests

Pour valider que les critères d’acceptation sont respectés, des outils dédiés à la gestion des tests sont essentiels :

• TestRail : Idéal pour structurer les cas de test et assurer leur alignement avec les user stories.
• Zephyr (intégré à Jira) : Permet de gérer les tests directement dans le backlog, offrant une traçabilité complète entre les stories, les tests, et les résultats.

Astuce : Combinez un outil de gestion des requirements (ex. : ALM Octane) avec un outil de tests (ex. : TestRail) pour garantir une couverture complète des besoins.

c) Centralisez la documentation

Une documentation claire améliore la collaboration entre les équipes. Voici quelques outils pour maintenir une trace des requirements et des user stories :

• Confluence : Utilisé pour documenter les épics et leurs dépendances, avec des tableaux croisés pour référencer les user stories.
• Notion : Outil flexible pour organiser et partager vos requirements avec les parties prenantes.

Astuce : Assurez-vous que votre documentation est accessible à toutes les équipes (développement, QA, produit) pour éviter les silos d’information.

d) Avantages des outils avancés (ALM Octane et Quality Center)

Les outils comme ALM Octane et Quality Center sont particulièrement utiles pour des projets critiques :

• Traçabilité complète : Suivez un requirement depuis sa définition jusqu’à sa validation finale (tests inclus).
• Multi-équipe : Gèrent des besoins dans des organisations complexes où plusieurs équipes doivent collaborer sur des artefacts partagés.
• Rapports avancés : Fournissent des métriques sur la couverture des tests, les défauts et les livraisons.
• Conformité : Adaptés aux secteurs hautement réglementés (ex. : santé, finance, défense).

Exemple pratique :
Dans ALM Octane, vous pouvez créer un requirement "Suivi des commandes", y associer des user stories comme "Voir le statut d’une commande", et lier ces stories à des cas de tests automatisés pour valider la mise à jour en temps réel du statut.

4. Pratiques avancées pour gérer les dépendances

a) Identifiez les dépendances en amont

• Analysez les stories pour repérer les fonctionnalités qui en bloquent d’autres.
• Exemple : Une user story "Voir le statut de ma commande" dépend d’une autre story "Permettre à l’administrateur de mettre à jour le statut".

b) Priorisez les dépendances critiques

Attribuez une priorité élevée aux stories bloquantes, et assurez-vous qu’elles soient livrées en premier.

c) Visualisez les dépendances

Utilisez un diagramme de dépendances pour éviter les blocages dans vos sprints.

Exemple de diagramme simple :

• RQ-F-001 (Suivi des commandes)
  • US-001-1 (Récapitulatif des commandes)
  • US-001-2 (Statut d’une commande)
    • Bloquée par : US-001-3 (Mise à jour du statut par l’administrateur).

5. Tips et bonnes pratiques

a) Revoyez les requirements régulièrement

Les requirements évoluent avec le projet. Planifiez des revues régulières pour les ajuster et en dériver de nouvelles user stories.

b) Limitez la granularité excessive

Ne divisez pas trop vos requirements. Regroupez les besoins similaires pour éviter un backlog trop fragmenté.

c) Conservez un backlog propre

Archivez les user stories obsolètes et maintenez une trace des versions précédentes pour la traçabilité.

6. Exemple complet : Requirement, User Stories, Critères, et Tests

Requirement :

RQ-F-001 : Le système doit permettre aux clients de suivre leurs commandes.

User Stories associées :

US-001-1 : En tant que client,  
Je veux voir un tableau récapitulatif de mes commandes,  
Afin de savoir ce que j’ai acheté.

US-001-2 : En tant que client,  
Je veux voir le statut actuel de ma commande,  
Afin de savoir si elle est en cours de livraison.

Critères d’acceptation (pour US-001-2) :

Scénario : Visualisation du statut  
Étant donné un client connecté,  
Lorsqu’il sélectionne une commande,  
Alors il voit son statut actuel ("Préparation", "Expédition", "Livraison").  

Scénario : Mise à jour en temps réel  
Étant donné une commande en cours,  
Lorsqu’un administrateur modifie son statut,  
Alors le client voit immédiatement cette modification.

Test associé :

• Test automatisé : Valider que les mises à jour de statut se reflètent dans l’interface utilisateur en moins de 2 secondes après modification.

Les erreurs courantes et comment les éviter

Même avec une structure bien pensée et des outils performants, des erreurs peuvent se glisser dans la gestion des requirements et des user stories. Ces erreurs peuvent compromettre la qualité, la collaboration, et la livraison du projet. Dans ce chapitre, je vais détailler les pièges les plus fréquents et comment les éviter.

1. Ne pas définir les requirements avant de commencer les user stories

Erreur : Se lancer directement dans la création de user stories sans établir de requirements solides au préalable.

Conséquences :

• Backlog désorganisé et incohérent.
• Lacunes dans les besoins critiques comme la performance ou la sécurité.
• Difficulté à prioriser les tâches et à aligner les équipes.

Comment éviter cette erreur :

• Identifiez et documentez clairement les requirements fonctionnels et non fonctionnels dès le début.
• Créez un lien explicite entre chaque requirement et ses user stories associées.

2. Écrire des user stories trop vagues ou trop détaillées

Erreur :

• Trop vague : "En tant qu’utilisateur, je veux une interface conviviale."
• Trop détaillé : "En tant qu’utilisateur, je veux un bouton vert avec une bordure de 2px."

Conséquences :

• Une user story vague crée des malentendus entre les développeurs et les parties prenantes.
• Une user story trop détaillée peut limiter la créativité et l’efficacité des développeurs.

Comment éviter cette erreur :

• Utilisez le format standardisé : "En tant que type d'utilisateur, je veux action/objectif, afin de bénéfice."
• Assurez-vous que les critères d’acceptation clarifient les attentes tout en laissant une marge pour les décisions techniques.

3. Oublier les requirements non fonctionnels (NFR)

Erreur : Se concentrer uniquement sur les fonctionnalités visibles au détriment des contraintes non fonctionnelles.

Exemple d’oubli : Ne pas définir de temps de réponse maximal pour une API ou d’exigences de sécurité pour les données utilisateur.

Conséquences :

• Performances médiocres sous forte charge.
• Failles de sécurité qui peuvent compromettre la confiance des utilisateurs.

Comment éviter cette erreur :

• Ajoutez une section dédiée aux NFR dans votre documentation des requirements.
• Rédigez des critères d’acceptation pour les NFR.
  Exemple :

Le système doit répondre à 90% des requêtes API en moins de 1 seconde sous une charge normale.

4. Négliger la collaboration interdisciplinaire

Erreur : Les user stories et requirements sont créés sans impliquer toutes les parties prenantes (Product Owner, QA, développeurs, utilisateurs finaux).

Conséquences :

• Les critères d’acceptation ne reflètent pas toujours les attentes réelles.
• Des besoins techniques ou métiers peuvent être oubliés.

Comment éviter cette erreur :

• Organisez des ateliers collaboratifs pour rédiger les requirements et user stories.
• Validez les critères d’acceptation avec toutes les parties prenantes avant de les finaliser.

5. Créer des artefacts redondants ou contradictoires

Erreur : Ajouter plusieurs user stories pour répondre au même besoin, ou créer des stories qui se contredisent.

Exemple :

• US-001 : "En tant qu’utilisateur, je veux m’inscrire avec mon email."
• US-002 : "En tant qu’utilisateur, je veux m’inscrire uniquement avec mon compte Google."

Conséquences :

• Confusion pour les développeurs.
• Double effort inutile ou livraisons incohérentes.

Comment éviter cette erreur :

• Maintenez un backlog centralisé et revoyez-le régulièrement.
• Utilisez des outils comme Jira, ALM Octane, ou Quality Center pour suivre les dépendances et éviter les duplications.

6. Mal gérer l’évolution des requirements

Erreur : Ne pas mettre à jour les requirements lorsqu’un besoin métier évolue, entraînant des user stories obsolètes.

Exemple :
Un requirement initial demande un envoi d’email pour chaque commande, mais un nouveau besoin impose des notifications push. Si le requirement n’est pas mis à jour, les user stories basées sur l’email deviennent incorrectes.

Conséquences :

• Travail gaspillé sur des fonctionnalités inutiles.
• Perte de confiance des parties prenantes dans le processus.

Comment éviter cette erreur :

• Utilisez un processus clair pour gérer les changements de requirements (par exemple, une revue hebdomadaire).
• Reliez vos user stories aux requirements pour identifier rapidement celles à mettre à jour.

7. Ignorer les retours des utilisateurs

Erreur : Ne pas inclure les retours utilisateurs dans l’évolution des user stories et requirements.

Conséquences :

• Un produit final qui ne répond pas aux attentes des utilisateurs finaux.
• Une perte de temps et de ressources à corriger le tir après la livraison.

Comment éviter cette erreur :

• Planifiez des démonstrations régulières avec les utilisateurs finaux pour valider les livraisons.
• Intégrez leurs retours directement dans l’évolution des requirements et des user stories.

8. Outils mal utilisés ou sous-exploités

Erreur : Ne pas tirer parti des fonctionnalités avancées des outils comme ALM Octane, Jira, ou Quality Center.

Conséquences :

• Traçabilité faible entre requirements, user stories, et tests.
• Efforts manuels inutiles pour gérer les dépendances et les priorités.

Comment éviter cette erreur :

• Formez votre équipe sur l’outil choisi.
• Configurez des liens automatisés entre les requirements, stories et tests pour maximiser la traçabilité.

Synthèse : Erreurs et solutions

Conclusion

Dans cet article, vous avez découvert pourquoi les user stories ne peuvent pas remplacer les requirements, et comment structurer vos projets pour garantir un backlog clair, évolutif et aligné sur les objectifs métier. Vous avez également vu comment des outils et des pratiques bien choisis peuvent transformer la gestion des artefacts dans vos équipes Agile.

Mais structurer vos requirements et user stories n’est qu’une partie de l’équation. Pour aller plus loin, il est essentiel d’adopter une démarche qui place la collaboration et la validation continue au cœur du développement. C’est ici que le Behaviour-Driven Development (BDD) entre en jeu.

Le BDD vous permettra de connecter encore plus efficacement les besoins métiers aux livrables techniques, en utilisant des scénarios compréhensibles par tous pour guider le développement et les tests automatisés.

👉 Je vous invite à lire notre prochain article : "Adopter le Behaviour-Driven Development (BDD) : Guide complet pour des équipes agiles". Vous y découvrirez les principes du BDD, comment rédiger des scénarios en Gherkin, et les outils pour intégrer cette méthode dans vos projets.

Vous voulez des équipes encore plus alignées et productives ? Le BDD pourrait être la clé. À très vite dans le prochain article !

FAQ – Vos questions, mes réponses

Pour conclure cet article, voici une FAQ répondant aux questions les plus fréquentes sur la gestion des requirements et des user stories. Cette section vous aidera à clarifier les concepts abordés et à appliquer les bonnes pratiques dans vos projets.

1. Les user stories peuvent-elles remplacer les requirements ?

Non.
Les user stories sont des artefacts temporaires, conçus pour guider l’équipe dans des cycles de développement courts. Elles traduisent un besoin spécifique d’un utilisateur, mais elles ne capturent pas la vision globale ou les contraintes durables d’un projet.
Les requirements, eux, sont des artefacts pérennes qui décrivent en détail les besoins métiers, techniques, et non fonctionnels.

2. Est-il obligatoire d’avoir des critères d’acceptation pour chaque user story ?

Oui.
Les critères d’acceptation sont essentiels pour clarifier les attentes et valider que la story est "Done". Ils servent également de base pour les tests, évitant ainsi des malentendus ou des fonctionnalités incomplètes.

3. Quelle est la différence entre un epic et un requirement ?

• Un epic est un regroupement de user stories autour d’un objectif fonctionnel commun. Il est souvent utilisé comme un conteneur pour organiser des stories liées dans le backlog.
• Un requirement est un document ou un artefact qui décrit un besoin spécifique (fonctionnel, non fonctionnel, technique, ou règlementaire). Il est plus durable et détaillé que les epics.

4. Peut-on adapter les user stories au fil des sprints ?

Oui.
Les user stories sont conçues pour être flexibles. Si un requirement évolue, les stories associées peuvent être mises à jour, archivées ou remplacées. Assurez-vous toutefois que le backlog reste clair et cohérent.

5. Comment gérer les requirements non fonctionnels (NFR) dans un projet Agile ?

• Intégrez-les dans vos critères d’acceptation.
• Planifiez des stories spécifiques pour les NFR critiques (ex. : tests de performance, configuration de sécurité).
• Assurez-vous qu’ils sont testés à chaque sprint pour éviter les régressions.

6. Quels outils recommandez-vous pour gérer les requirements et user stories ?

• Jira : Excellent pour les équipes Agile avec des fonctionnalités de gestion de backlog.
• ALM Octane : Idéal pour des projets complexes nécessitant une traçabilité étroite entre requirements, user stories, et tests.
• Quality Center : Parfait pour les environnements très réglementés où les exigences et tests doivent être alignés.

7. Est-il possible de travailler sans requirements dans un petit projet ?

Cela peut fonctionner sur des projets très simples, mais c’est risqué. Même dans un petit projet, des requirements bien définis garantissent une meilleure structure et une vision claire des besoins.

8. Comment éviter un backlog surchargé ?

• Archivez régulièrement les stories obsolètes ou inutilisées.
• Priorisez les stories selon la valeur métier et les objectifs globaux.
• Revoyez le backlog lors des rétrospectives pour identifier les éléments superflus.

9. Quelle est la meilleure façon de gérer les dépendances entre stories ?

• Identifiez-les dès le début grâce à des workshops collaboratifs.
• Utilisez des outils comme Jira ou ALM Octane pour visualiser et gérer les dépendances.
• Priorisez les stories bloquantes pour éviter les retards.

10. Est-ce qu’un requirement peut évoluer après le démarrage du projet ?

Oui.
Les requirements peuvent évoluer pour s’adapter aux nouveaux besoins métiers ou techniques. Cependant, il est important de :

• Mettre à jour les user stories et tests associés.
• Communiquer clairement ces changements à toutes les parties prenantes.

Conclusion de la FAQ

La gestion des requirements et des user stories est un processus dynamique qui nécessite collaboration, outils adaptés, et bonnes pratiques. En suivant ces conseils, vous pourrez structurer vos projets avec clarté et efficacité, tout en restant agile face aux évolutions.