Analyse et documentation des exigences

Définition

L'analyse des exigences est le processus de structuration, validation et documentation des exigences recueillies lors de l'élicitation. Elle transforme des besoins bruts en exigences exploitables — claires, complètes, cohérentes et traçables — que l'équipe projet peut implémenter.

Activité	Objectif
Modélisation	Représenter les exigences visuellement (diagrammes, flux)
Spécification	Rédiger les exigences de façon précise et non ambiguë
Validation	Vérifier que les exigences reflètent les vrais besoins
Vérification	Vérifier que les exigences sont correctement documentées
Priorisation	Ordonner les exigences par importance et urgence
Approbation	Obtenir l'accord formel des parties prenantes

Contexte

Le CAPM distingue l'élicitation (recueil) de l'analyse (traitement). L'analyse est souvent sous-estimée : des exigences mal analysées sont la cause n°1 d'échec des projets selon le PMI. La documentation sert de contrat entre les parties prenantes et l'équipe de réalisation.

Détails techniques

Types d'exigences à documenter

Type	Description	Exemple
Fonctionnelle	Ce que le système doit faire	Le système envoie un email de confirmation après commande
Non-fonctionnelle	Comment le système doit se comporter	Temps de réponse < 2 secondes sous 1 000 utilisateurs
Métier	Objectif stratégique	Augmenter le taux de conversion de 15%
Transition	Passage ancien → nouveau	Migration des 50 000 comptes utilisateurs existants
Contrainte	Limitation imposée	Budget max 200K €, compatible IE11, RGPD

Techniques de modélisation des exigences

Technique	Représentation	Usage
Diagramme de flux (BPMN)	Processus métier étape par étape	Workflows, processus d'approbation
Cas d'utilisation (Use Case)	Acteur → Système → Réponse	Interactions utilisateur-système
User Story + Critères	En tant que... je veux... afin de...	Projets agile
Maquette / Wireframe	Interface visuelle	Exigences UI/UX
Diagramme d'état	Transitions entre états	Cycle de vie d'un objet (commande, ticket)
Matrice de règles métier	Conditions → Actions	Logique décisionnelle complexe
Modèle de données	Entités et relations	Architecture de données

Critères de qualité d'une exigence (SMART + INVEST)

Critère	Vérification	Mauvais exemple	Bon exemple
Claire	Pas d'ambiguïté	Le système doit être rapide	Temps de réponse < 200 ms au P95
Complète	Tous les cas couverts	L'utilisateur peut se connecter	L'utilisateur se connecte par email/MDP, Google, ou SSO
Cohérente	Pas de contradiction	Exigence A dit X, exigence B dit non-X	Vérification croisée OK
Testable	Critère de validation objectif	Le système doit être convivial	Score SUS > 80 après test utilisateur
Traçable	Liée à un besoin métier	Fonctionnalité isolée	Req-045 → Besoin B-012 → Objectif stratégique
Priorisée	Importance relative connue	Tout est « haute priorité »	MoSCoW : Must / Should / Could / Won't

Techniques de priorisation

Technique	Description	Résultat
MoSCoW	Must / Should / Could / Won't	Catégorisation en 4 niveaux
100-Dollar Method	Chaque PP distribue 100 $ fictifs	Priorisation pondérée par l'investissement
Kano	Basique / Performance / Attractif	Classification par satisfaction utilisateur
WSJF	Weighted Shortest Job First	Priorité = Coût du retard / Taille (agile à l'échelle)
Valeur métier / Effort	Matrice 2×2	Quick wins identifiés

Structure d'un document d'exigences (SRS)

1. Introduction
   ├── Objectif du document
   ├── Portée du système
   └── Références
2. Description générale
   ├── Contexte et contraintes
   └── Hypothèses et dépendances
3. Exigences fonctionnelles
   ├── EF-001 : [Description, priorité, critères d'acceptation]
   ├── EF-002 : ...
   └── ...
4. Exigences non-fonctionnelles
   ├── Performance, sécurité, disponibilité
   └── Contraintes techniques
5. Modèles et diagrammes
6. Matrice de traçabilité
7. Approbations

Exemple concret

Analyse des exigences pour un module de facturation :

ID	Exigence	Type	Priorité	Source	Validation
EF-01	Le système génère une facture PDF à chaque commande validée	Fonctionnelle	Must	Comptabilité	Facture PDF générée en < 5s
EF-02	L'utilisateur peut télécharger ses factures des 24 derniers mois	Fonctionnelle	Must	Client	Historique accessible, PDF valide
ENF-01	Le système supporte 500 factures simultanées	Non-fonctionnelle	Should	IT	Test de charge OK
ENF-02	Conformité TVA pour 5 pays UE	Contrainte	Must	Juridique	Audit comptable validé
ET-01	Reprise des 120 000 factures de l'ancien système	Transition	Must	Comptabilité	100% des factures migrées et vérifiables

Priorisation MoSCoW : 12 Must (MVP), 8 Should (V1.1), 5 Could (V2), 3 Won't (hors périmètre).