L’essentiel à retenir
- Requirements Management est un processus central et continu, pas une phase séquentielle.
- Sa finalité : comprendre et gérer les exigences, avec une traçabilité de bout en bout.
- Les phases traitent et priorisent les exigences ; le processus les gère et les rend disponibles.
- Le Requirements Impact Assessment indique quelles phases revisiter après un changement.
- L’Architecture Requirements Repository conserve les exigences autorisées.
Finalité : comprendre et gérer les exigences
Le guide des praticiens résume la finalité de Requirements Management en deux verbes : comprendre et gérer les exigences. Le TOGAF le place au centre du développement de l’architecture, car toutes les phases produisent, consomment ou modifient des exigences.
Son efficacité dépend d’une traçabilité claire, depuis la vision, la mission, le business model et les stratégies de l’organisation jusqu’aux exigences les plus détaillées. Le processus est dynamique : les exigences changent en cours de route et doivent être réévaluées sans attendre la fin du cycle.
Point souvent mal compris : le processus ne traite pas et ne priorise pas lui-même les exigences. Ce travail se fait dans la phase concernée ; Requirements Management en assure l’identification, le stockage, le suivi et la diffusion.
Trois objectifs
Les objectifs du processus sont formulés du point de vue du service rendu aux phases de l’ADM.
- Faire fonctionner durablement la gestion des exigences pour toutes les phases concernées
- Gérer les exigences d’architecture identifiées lors de n’importe quelle exécution du cycle ou d’une phase
- Rendre les exigences pertinentes disponibles pour chaque phase au moment où elle s’exécute
Étapes : un dialogue entre le processus et les phases
APPROFONDISSEMENT · DÉTAILS D’APPLICATION
Les étapes alternent entre ce que fait Requirements Management et ce que fait la phase en cours. Les premières exigences de haut niveau apparaissent avec l’Architecture Vision en Phase A ; chaque phase en ajoute ou en modifie ensuite.
- La phase identifie et documente ses exigences ; le processus les établit en baseline (priorités confirmées, adhésion des parties prenantes, enregistrement)
- Le processus surveille la baseline et repère les exigences modifiées, ajoutées ou supprimées
- L’impact des changements sur la phase courante et les phases passées est évalué
- Les exigences issues de la Phase H sont prises en compte et le référentiel est mis à jour
- La phase applique le changement et révise, si besoin, la gap analysis des phases précédentes
Livrables et référentiel
Les exigences autorisées sont regroupées dans l’Architecture Requirements Repository, composant de l’Architecture Repository. Des techniques comme les Business Scenarios aident à les découvrir, mais le standard n’impose aucun outil particulier.
- Exigences modifiées
- Requirements Impact Assessment : phases à revisiter et, dans sa version finale, implications complètes (coûts, délais, indicateurs métier)
- Architecture Requirements Specification mise à jour, vue quantitative et mesurable de la solution
LES MOTS À CONNAÎTRE
Le vocabulaire, avec du sens.
- Architecture Requirements Repository
- Partie de l’Architecture Repository qui offre une vue de toutes les exigences d’architecture autorisées.
- Requirements Impact Assessment
- Évaluation de l’effet d’un changement d’exigence sur le cycle, qui désigne les phases à revisiter.
- Architecture Requirements Specification
- Ensemble des exigences mesurables que la mise en œuvre doit respecter ; complète la vue qualitative de l’Architecture Definition Document.
- Traçabilité
- Lien explicite entre la vision et les stratégies de l’organisation et chaque exigence détaillée.
- Baseline d’exigences
- Ensemble d’exigences priorisées, acceptées par les parties prenantes et enregistrées, qui sert de référence pour suivre les changements.