La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
Avec TOGAF, les exigences peuvent changer tout au long des phases ADM.
Un nombre important de facteurs externes ou internes peuvent impacter les exigences durant le projet : les lois changent, la concurrence est de plus en plus agressive, les utilisateurs ne savent pas ce qu’ils veulent, des nouvelles technologies apparaissent à des fréquences de plus en plus réduites …
La solution est d’itérer le processus et d’intégrer à chaque nouvelle itération, la gestion des exigences et étudier s’il y des changements.
Pour en savoir plus sur système itératif ADM de TOGAF :
et l’article sur la phase H concernant la gestion des changements dans TOGAF
TOGAF avec la méthode ADM reprend toutes les bonnes pratiques bien connues.
Une exigence peut spécifier une fonction qu'un système doit exécuter ou des critères de performance à atteindre.
On pourra ainsi réutiliser des exigences dans d'autres produits ou projets.
Les scénarios typiques sont des exigences réglementaires, statutaires, ou contractuelles applicables à des produits et à des projets.
On doit pouvoir faire référence à une exigence qui peut donc se trouver dans des contextes multiples ou bien mettre à jour l'exigence d'origine et propager les modifications aux exigence réutilisées.
Si TOGAF n’impose aucune technique ni méthode de gestion d’exigences, il est fortement recommandé d’en prendre et de les adapter.
Vous trouverez dans la suite, des articles, qui vous aideront dans vos choix, sachant qu’ils sont le fruit de mes retours d’expérience.
Comment identifier les besoins ?
Expression des besoins : Techniques pour recueillir les besoins
Expression des besoins : Posez des questions efficacement
Expression des besoins : Soyez efficient dans l'organisation de vos groupes de travail !
Apprendre à modéliser les exigences avec SysML
SysML : le diagramme d'exigence (requirement diagram)
SysML : exemples de diagramme d'exigence tout droit sortie de la norme de l'OMG
SysML : le diagramme de cas d'utilisation (use case diagram)
SysML : les use case "top level" et opérationnels (tutorial SysML partie 4)
SysML pour les nuls : de la modélisation des exigences à la réalisation du système
Mettre en pratique une méthode efficace pour modéliser les exigences
SysML : la méthode, les exemples et l'étude de cas dont vous rêviez
SysML : les bonnes pratiques - les étapes pour une modélisation efficace
Comment modéliser vos processus métier avec BPMN (Business Process Model & Notation) ?
Comment mettre en place un jeu de rôles pour modéliser un processus métier ?
BPMN : l'antisèche pour rester incollable en modélisation de processus
BPMN l’exemple type pour tout comprendre sans prendre d’aspirine
BPMN : la norme, toute la norme rien que la norme. L'exemple à lire en attendant une pizza.
N’oublier pas de modéliser vos règles métier avec la norme DMN (Decision Model Notation) et les relier à vos processus métier
Vous pouvez aussi choisir UML (Unified Modeling Language)
Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
Notre palmarès des outils
Les meilleurs outils de modélisation UML, SysML, BPMN, DMN de l'année 2016 et les gagnants sont ...
Le gratuit :
Tutoriel Papyrus : vos diagrammes UML 2 comme à l'époque des manuscrits de l'antiquité !
Le payant (très cher !) :
Expression des besoins : modélisation des exigences avec le "mega extra super" AGL MEGA
Et une petite méthode exotique pour ceux qui aiment :
Ingénierie Dirigée par les Modèles : l'orienté but avec KAOS
Conclusion
Les exigences doivent être rédigées sous la forme « sujet, verbe, complément ».
L’exigence classique du type : « l’adhérent à la mutuelle peut consulter ses remboursements de soins en ligne à tout moment », cache en réalité une exigence fonctionnelle : « l’adhérent à la mutuelle peut consulter ses remboursements de soins en ligne » et une exigence non fonctionnelle « une consultation de remboursement peut être faite à tout moment ».
Les exigences sont rédigées bien sûr par le métier et c’est la responsabilité de l’architecte de faire préciser la formulation des exigences en fonction des impacts potentiels.
Dans le cycle ADM de TOGAF, tout en restant indépendante du domaine considéré, la gestion des exigences s’applique à toutes les phases qui peuvent les analyser et déterminer leurs impacts sur l’architecture.
Avec ces allers-retours, les redondances sont évitées et la cohérence est maintenue.
Les exigences sont rationalisées, hiérarchisées, suivies, possèdent un cycle de vie, des méta informations, …, le tout stocké dans un référentiel spécifique géré par un outil.
À vous de choisir ce que vous voulez utiliser, cela peut être le « Modèle de spécification des exigences de Volere », le langage normalisé SysML, …
Un bon conseil, identifiez les scénarios métiers les plus stratégiques et les plus complexes, simulez grâce à la modélisation ou bien faites réaliser un prototype (POC Proof Of Concept) qui montrera aux sponsors et aux utilisateurs que les projets avancent et qu’ils sont bien alignés avec les objectifs et exigences métiers.
Sinon gare aux dérives.
Rhona Maxwel
@rhona_helena
"Celui qui pose une question est bête cinq minutes, celui qui n’en pose pas l’est toute sa vie."
Proverbe chinois
Articles conseillés :
A découvrir aussi
- La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
- Comment mettre en œuvre la phase E Opportunités et Solutions de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
- Comment mettre en œuvre la phase G Gouvernance de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 799 autres membres