Chapitre 09 : Exigences et User Stories

Introduction

Le recueil et la formalisation des exigences constituent la première étape critique de tout projet SI. Une exigence mal formulée ou mal comprise peut entraîner des dérives coûteuses. Ce chapitre explore les différentes techniques de spécification des besoins : des User Stories agiles aux Use Cases structurés, en passant par la méthode Volere et le langage Gherkin.

---

9.1 Recueil des exigences

9.1.1 Définitions

Une exigence est une capacité dont un système a besoin ou une condition que le système doit satisfaire. On distingue trois grandes catégories :

9.1.2 Sources d'exigences

Les exigences proviennent de multiples sources :

Diagramme en cours de génération...

9.1.3 Techniques de recueil

9.1.4 Hiérarchisation MoSCoW

La technique MoSCoW permet de prioriser les exigences :

M — Must have (indispensable)
S — Should have (important mais pas critique)
C — Could have (bonus)
W — Won't have (hors périmètre)

---

9.2 User Stories

9.2.1 Définition

Une User Story est une description concise d'une fonctionnalité du point de vue de l'utilisateur. Elle suit le format standardisé :

En tant que [rôle utilisateur]
Je veux [action/fonctionnalité]
Afin de [bénéfice/valeur métier]

9.2.2 Les critères INVEST

Toute User Story doit respecter les critères INVEST :

1. I — Independent : La story peut être développée et livrée indépendamment des autres
2. N — Negotiable : La story est une discussion, pas un contrat figé
3. V — Valuable : La story apporte de la valeur métier
4. E — Estimable : On peut estimer l'effort de développement
5. S — Small : La story est suffisamment petite pour être réalisée en un sprint
6. T — Testable : On peut vérifier objectivement son implémentation

Diagramme en cours de génération...

9.2.3 Gherkin pour les critères d'acceptation

Les critères d'acceptation sont rédigés en Gherkin, un langage structuré Given/When/Then :

Fonctionnalité: <Titre de la fonctionnalité>
  Scénario: <Titre du scénario>
    Étant donné <contexte initial>
    Quand <action déclenchée>
    Alors <résultat attendu>

9.2.4 Exemple complet

Fonctionnalité: Connexion utilisateur
  En tant qu'utilisateur enregistré
  Je veux me connecter à mon compte
  Afin d'accéder aux fonctionnalités réservées

  Scénario: Connexion réussie
    Étant donné un utilisateur avec un email validé
    Quand je saisis mon email "user@example.com" et mon mot de passe valide
    Alors je suis connecté
    Et je suis redirigé vers mon tableau de bord

  Scénario: Mot de passe incorrect
    Étant donné un utilisateur enregistré
    Quand je saisis un mot de passe incorrect
    Alors un message "Email ou mot de passe incorrect" s'affiche
    Et je reste sur la page de connexion

  Scénario: Email non validé
    Étant donné un utilisateur avec un email non validé
    Quand je tente de me connecter avec des identifiants valides
    Alors un message "Veuillez valider votre email" s'affiche
    Et la connexion est refusée

9.2.5 Pièges à éviter dans les User Stories

9.2.6 Hiérarchie des artefacts agiles

Diagramme en cours de génération...

---

9.3 Use Cases

9.3.1 Définition

Un Use Case (cas d'utilisation) décrit de manière détaillée une séquence d'interactions entre un acteur et le système, aboutissant à un résultat observable.

9.3.2 Structure d'un Use Case

9.3.3 Exemple détaillé de Use Case

═══════════════════════════════════════════════════════
UC-01 : Passer une commande
═══════════════════════════════════════════════════════

Acteur principal : Client
Acteurs secondaires : Système de paiement, Service logistique
Préconditions :
  - Le client est authentifié
  - Le panier contient au moins un article
Postconditions :
  - La commande est créée (statut : confirmée)
  - Le stock est réservé
  - Un email de confirmation est envoyé

Scénario nominal :
  1. Le client consulte le résumé de son panier
  2. Le système affiche le récapitulatif (articles, prix)
  3. Le client saisit son adresse de livraison
  4. Le système valide l'adresse
  5. Le client sélectionne un mode de livraison
  6. Le système calcule les frais de port
  7. Le client sélectionne le mode de paiement
  8. Le client saisit les informations de paiement
  9. Le système transmet la demande à la banque
  10. La banque autorise le paiement
  11. Le système crée la commande (statut : confirmée)
  12. Le système envoie un email de confirmation
  13. Le système affiche la page de confirmation

Scénarios alternatifs :
  A1. Adresse invalide (étape 4)
    A1.1 Le système détecte une adresse incomplète
    A1.2 Le système demande les champs manquants
    A1.3 Retour à l'étape 3

  A2. Paiement refusé (étape 10)
    A2.1 La banque refuse le paiement
    A2.2 Le système affiche le motif du refus
    A2.3 Le système propose un autre moyen de paiement
    A2.4 Retour à l'étape 8

  A3. Stock insuffisant (étape 11)
    A3.1 Le stock d'un article est épuisé entre temps
    A3.2 La commande est créée avec un statut "en attente"
    A3.3 Un email informe le client du délai

Règles métier :
  - Une commande doit contenir au moins 1 article
  - Le montant minimum de commande est de 10€
  - La livraison est gratuite pour les commandes > 50€

9.3.4 Relations entre Use Cases

Diagramme en cours de génération...

9.3.5 Niveaux de granularité (Cockburn)

Alistair Cockburn définit 3 niveaux de Use Cases :

• Niveau Stratégique (Résumé) : Vue macro, cycle de vie complet
• Niveau Utilisateur (But) : Objectif concret d'un acteur
• Niveau Subfonction (Sous-but) : Sous-étapes techniques

---

9.4 Spécification fonctionnelle

9.4.1 Structure type

Un document de spécification fonctionnelle comprend généralement :

1. Page de garde : Titre, version, date, auteurs
2. Historique des versions
3. Table des matières
4. Introduction : Contexte, objectifs, périmètre
5. Glossaire : Définitions des termes métier
6. Description générale : Vue d'ensemble du système
7. Exigences fonctionnelles détaillées : Par module ou fonctionnalité
8. Règles de gestion : Logique métier
9. Exigences non-fonctionnelles : Performances, sécurité, etc.
10. Contraintes : Techniques, légales, organisationnelles
11. Annexes : Diagrammes, maquettes, références

9.4.2 Exemple de traçabilité

Diagramme en cours de génération...

---

9.5 Méthode Volere

9.5.1 Présentation

La méthode Volere (Robertson, 2006) est une approche complète de gestion des exigences. Elle fournit un template structuré avec 50 questions réparties en 4 sections :

Diagramme en cours de génération...

9.5.2 Les 4 sections du template Volere

Section 1 — Project Drivers

• But du projet
• Objectifs métier
• Bénéfices attendus

Section 2 — Project Constraints

• Contraintes techniques
• Contraintes temporelles
• Contraintes budgétaires
• Contraintes légales

Section 3 — Functional Requirements

• Fonctionnalités détaillées
• Interfaces utilisateur
• Interfaces systèmes
• Règles métier

Section 4 — Non-Functional Requirements

• Performance
• Sécurité
• Disponibilité
• Maintenabilité
• Portabilité
• Utilisabilité

9.5.3 Carte de spécification Volere

Chaque exigence Volere est décrite sur une carte avec :

┌────────────────────────────────────────────┐
│  Volere Requirement Card                   │
├────────────────────────────────────────────┤
│  ID: RQ-042                                │
│  Type: Fonctionnelle                       │
│  Description: Le système doit permettre    │
│  la recherche de produits par mots-clés    │
│  Source: Client (Marketing)                │
│  Priorité: Must Have                       │
│  Risque: Faible                            │
│  Validation: Test de recette               │
└────────────────────────────────────────────┘

---

9.6 Comparaison User Stories vs Use Cases

9.6.1 Tableau comparatif

9.6.2 Quand utiliser quoi ?

Diagramme en cours de génération...

9.6.3 Complémentarité

User Stories et Use Cases ne sont pas mutuellement exclusifs :

• User Stories pour la gestion de projet (backlog, priorisation, estimation)
• Use Cases pour la spécification détaillée (cas complexes, réglementaires)
• Gherkin pour les tests d'acceptation automatisés

---

9.7 Synthèse

Diagramme en cours de génération...

Points clés à retenir

---

Exercices de synthèse

1. QCM : Vérifiez vos connaissances avec le quiz du chapitre
2. Flashcards : Révisez les concepts clés
3. TP 1 : Rédigez 8 User Stories pour un système de bibliothèque
4. TP 2 : Produisez une spécification fonctionnelle complète

---

Pour aller plus loin

• Mike Cohn — User Stories Applied (2004)
• Alistair Cockburn — Writing Effective Use Cases (2000)
• Robertson — Mastering the Requirements Process (2012)
• Volere — Template gratuit sur volere.org
• Cucumber — Documentation Gherkin sur cucumber.io