Capturer les besoins clients internes et externes, et les consolider est une activité qui se décompose en 3 étapes :
1. identifier et organiser les parties prenantes du système sous la forme de diagramme(s) hiérarchique(s) et d’un diagramme d’environnement qui précise les interfaces/interactions de ces parties prenantes avec le système considéré ;
2. cadrer la demande des parties prenantes du système en capturant l’objectif qui motive le développement du système donné, et décrivant de manière succincte le périmètre opérationnel, fonctionnel et technique du système cible et des principaux indicateurs de performance à atteindre ;
3. capturer les besoins des parties prenantes du système en commençant par la capture des besoins «bruts» des parties prenantes, tels que ces dernières les expriment, à l’aide des sources d’information disponibles (interviews, documents, etc.), puis en formalisant ces besoins bruts à l’aide d’un cadre standard d’énoncé de besoin et en hiérarchisant enfin les besoins formalisés.
L’architecte identifie le périmètre externe à prendre en compte et clarifie les missions du système ainsi que les objectifs à atteindre. Il formalise et hiérarchise tous les besoins des parties prenantes en garantissant leur non-ambiguïté et leur exhaustivité.
Parmi les principaux écueils, on notera :
• Que des problématiques d’organisation peuvent surgir lorsque la capture des besoins menée par l’architecte entre en conflit avec les activités business (BU ou Business Analyst) ;
• Vouloir aller trop loin dans la modélisation de l’environnement. Pour éviter cela, il faut sans cesse raisonner en termes de valeur et donc voir ce qui a un impact substantiel sur le système d’intérêt. Connaître les processus métiers de l’entreprise permet de mieux évaluer la valeur ;
• Omettre de consulter les parties prenantes de certaines phases de vie (développement, maintenance, etc.) ;
• Les acteurs principaux ne sont pas alignés sur le périmètre défini du système (cela arrive souvent car on ne prend pas le temps de faire cet effort).
Voici quelques bonnes pratiques à prendre en compte :
- Ne pas laisser l’aspect organisationnel devenir le moteur principal dans la définition du périmètre. Cela permet d’éviter de biaiser les choix d’architecture dès cette étape ;
- Faire comprendre la valeur : l’architecte apporte un aspect analyse de risque et valeur, là où les business analysts sont dans une optique de couverture et de consistance. On peut procéder soit par un partage des peines (analyse des irritants, des problèmes, de tout ce qui empêche d’atteindre les objectifs) soit par une démonstration de l’apport d’une méthodologie ;
- S’assurer du bon niveau de connaissance des acteurs impliqués dans la validation des cas d’utilisation et du bon niveau de responsabilité (au sens décisionnel) vis- à- vis des impacts potentiels. Ceci est vrai pour l’ensemble des activités d’architecture ;
- Ne pas freiner les gens dans l’expression du besoin : s’ils expriment plutôt des solutions il faut les noter et remonter au besoin (par la méthode des 5 pourquoi par exemple) ;
- Il faut veiller à intégrer les contraintes/attentes des équipes safety, cyber sécurité…
Nous avons compilé ici un certain nombre de verbatims de chef de projet ou d’architecte système de différentes entreprises, et qui font écho à cette phase de captation des besoins :
“ Nous avons fait challenger les livrables existants par les équipes. Cela a naturellement fait émerger le besoin de mettre en place une nouvelle méthodologie sur la capture des besoins, ce que nous avons fait en accompagnant les collaborateurs via des formations
“ Nous faisons des boucles très courtes entre boîte noire et boîte blanche afin de mettre en évidence les implications des besoins sur les contraintes induites dans l’architecture.
“ Nous préparons les deux visions boîtes noires et boîtes blanches, et mettons les éléments qui sont plutôt de l’ordre de la solution possible dans la partie boîte blanche avant de remonter au besoin.
Vos commentaires seront étudiés par les membres du Cercle lors de la prochaine réunion mensuelle.