Recueil des exigences¶

Distinguer ce que le système fait de comment il le fait — et rendre chaque exigence mesurable.

Exigences fonctionnelles et non-fonctionnelles¶

Distinguer ce que le système fait de comment il le fait est le premier travail de cadrage. Les exigences fonctionnelles décrivent les comportements observables par l'utilisateur. Les exigences non-fonctionnelles (NFR) décrivent les qualites du système — performance, disponibilité, scalabilité, sécurité.

Catégories de NFR et leur impact architectural¶

Les NFR se regroupent en catégories qui correspondent directement a des choix d'architecture :

Performance et latence¶

• Latence p99 < 200ms → exclut les architectures avec de nombreux sauts synchrones
• Throughput > 10 000 req/s → impose un load balancer et une conception stateless des services
• Temps de génération de rapport < 5s → impose du pre-calcul ou du caching agressif

Disponibilité et résilience¶

• 99.9% (8h/an) → déploiement sans interruption, health checks, restart automatique
• 99.95% (4h/an) → multi-zone, circuit breakers, graceful dégradation
• 99.99% (52min/an) → multi-region, réplication synchrone, runbooks testés

Reprise sur incident¶

• RPO (Recovery Point Objective) : combien de données peut-on perdre en cas de panne ?
• RTO (Recovery Time Objective) : combien de temps peut-on rester indisponible ?
• RPO < 1h impose des backups fréquents ou une réplication synchrone
• RTO < 15min impose une bascule automatique, pas manuelle

Sécurité et conformité¶

• RGPD : localisation des données, droit à l'effacement, audit log
• PCI-DSS : isolation des composants manipulant des données de carte, chiffrement at-rest
• SOC 2 : traçabilité de tous les accès aux données sensibles

Identifier les NFR tôt evite de découvrir en phase de tests que l'architecture choisie ne peut pas les satisfaire. Un système conçu sans SLA de disponibilité sera probablement déployé avec un seul point de défaillance.

Documents formels de cadrage¶

Le cadrage des exigences s'appuie sur des documents formalisés dont la structure varie selon le contexte — projet interne, appel d'offres, prestation externe. Trois documents principaux couvrent le spectre du besoin à la solution.

Cahier des charges (CDC)¶

Le cahier des charges exprime le besoin du commanditaire. Il décrit quoi sans prescrire comment. Sa structure type :

Spécification fonctionnelle détaillée (SFD)¶

La SFD traduit le CDC en comportements précis du système. Elle décrit les règles métier, les parcours utilisateur, les cas d'erreur, les interfaces. C'est le document de référence pour les développeurs et les testeurs.

Contenu typique :

• Diagrammes de cas d'utilisation ou user story maps
• Règles de gestion détaillées
• Maquettes ou wireframes
• Matrice des droits et rôles
• Scenarios nominaux et alternatifs pour chaque fonctionnalité

Spécification technique détaillée (STD)¶

La STD décrit comment le système sera construit. Elle traduit les exigences fonctionnelles et non-fonctionnelles en choix techniques concrets :

• Architecture retenue (avec référence aux ADR)
• Schémas de données
• Contrats d'API
• Infrastructure cible
• Plan de déploiement
• Stratégie de tests

La STD est le pont entre le cadrage et la construction. Elle est validee par le comite d'architecture avant le début du développement.

Articulation entre les documents¶

graph LR
    CDC[Cahier des charges] --"traduit en"--> SFD[Specification fonctionnelle]
    CDC --"contraint"--> STD[Specification technique]
    SFD --"alimente"--> STD
    STD --"reference"--> ADR[ADR]
    SFD --"valide par"--> TEST[Plan de tests]
    STD --"valide par"--> TEST

Dans un contexte agile, ces documents ne sont pas produits en sequence monolithique. Le CDC existe souvent sous forme de product vision et de backlog priorise. La SFD se materialise dans les user stories et les critères d'acceptance. La STD vit dans les ADR et le wiki technique. La forme change, pas le besoin.

Techniques de recueil des exigences¶

Les exigences ne tombent pas du ciel. Elles s'extraient par des techniques adaptées au contexte et aux interlocuteurs.

Interviews individuelles¶

L'interview est la technique la plus directe. On rencontre chaque partie prenante pour comprendre ses attentes, ses craintes et ses priorités.

Bonnes pratiques :

• Préparer les questions à l'avance — questions ouvertes, pas des validations
• Interviewer les parties prenantes séparément pour éviter l'influence du groupe
• Distinguer les besoins réels des solutions déjà imaginees ("j'ai besoin d'un export Excel" cache souvent "j'ai besoin de suivre mes commandes")
• Prendre des notes structurées et les faire valider par l'interviewe

Ateliers collaboratifs¶

Les ateliers reunissent plusieurs parties prenantes pour co-construire les exigences. Ils sont utiles pour révéler les conflits et les zones d'ombre.

Prototypage exploratoire¶

Quand les parties prenantes ne savent pas ce qu'elles veulent (situation plus courante qu'on ne le croit), un prototype exploratoire révélé les exigences par l'usage.

Le prototype n'est pas un MVP. C'est un outil jetable dont la seule valeur est le feedback qu'il généré. Il doit être suffisamment realiste pour provoquer des réactions utiles, mais suffisamment léger pour être modifie en heures, pas en semaines.

Analyse de l'existant¶

Pour un système qui remplacé ou évolue un système existant, l'analyse de l'existant est incontournable. On y decouvre les exigences implicites — celles que personne ne mentionne parce qu'elles sont évidentes pour les utilisateurs actuels.

Techniques : observation directe, analyse des logs, interviews des utilisateurs, étude des tickets de support. Les bugs recurrents révèlent souvent des exigences non-fonctionnelles non documentees.

Choisir la technique selon le contexte¶

Priorisation MoSCoW¶

Toutes les exigences ne se valent pas. La méthode MoSCoW classe chaque exigence en quatre catégories qui structurent les arbitrages :

Exemple de priorisation¶

Règles de répartition¶

Une répartition saine suit approximativement cette distribution :

• Must : 30-40% des exigences. Si tout est M, rien n'est priorise.
• Should : 20-30%. Ce sont les fonctionnalités qui font la différence.
• Could : 15-25%. Le confort, pas la nécessité.
• Won't : 10-20%. La discipline du périmètre.

Si plus de 50% des exigences sont classees M, le travail de priorisation n'a pas été fait. Retourner en atelier avec les parties prenantes pour forcer les arbitrages.

Matrice de traçabilité¶

La matrice de traçabilité lie chaque exigence aux composants qui l'implementent, aux tests qui la valident et aux décisions qui l'impactent. Elle répond à la question : "si cette exigence change, qu'est-ce qui est impacte ?"

graph LR
    EX[Exigence] --"implemente par"--> COMP[Composant]
    EX --"validee par"--> TEST[Test]
    EX --"decidee dans"--> ADR[Decision ADR]
    COMP --"materialise dans"--> CODE[Code source]
    TEST --"execute par"--> CI[Pipeline CI]

La traçabilité n'est pas un exercice bureaucratique. Elle est utile dans trois situations concrètes :

1. Impact analysis : quand une exigence change, on identifié immédiatement les composants et tests impactes.
2. Couverture : on détecté les exigences sans test et les composants sans exigence associee.
3. Audit : on démontré que chaque exigence reglementaire est implémentée et testée.

Outillage de la traçabilité¶

La matrice peut vivre dans un tableur pour les petits projets, mais les projets plus importants beneficient d'outils dédiés :

• Jira + liens : lier les epics (exigences) aux stories (composants) et aux test plans
• Azure DevOps : traçabilité native entre requirements, work items et test cases
• Notion / Confluence : bases de données relationnelles entre exigences et composants
• Code : tags dans les tests (@requirement("ENF-001")) pour la traçabilité automatique

L'outil importe moins que la discipline. Une matrice non maintenue est pire que pas de matrice — elle donne une fausse impression de contrôle.

Anti-patterns du recueil d'exigences¶

Chapitre suivant : Contraintes et contexte — les faits qui eliminent des options avant même d'ouvrir un outil de modélisation.