Modéliser, lier et délimiter un gros volume d’exigences métier quand, en plus, le périmètre est complexe n’est pas facile. Les méthodes UML ou SysML sont orientées conception logicielle, et ne sont pas forcément appropriées à tous les besoins des Business Analysts.
Connaissez-vous le Business Data Diagram (BDD®) ? Il s’agit d’un outil très intéressant pour gérer les exigences, qui peut être utilisé dans presque tous les projets IT, agile ou non (cycle en V ou cascade).
Le Business Data Diagram est l’un des outils de la modélisation RML®. Celle-ci est une approche similaire à l’UML ou au SysML et, de même que l’UML a ses diagrammes, la méthode « Requirements Modelling Language » a ses modèles. La différence essentielle repose dans le fait que l’approche RML® aborde les logiciels du point de vue de l’analyse métier et de la gestion des produits et qu’elle se concentre sur la spécification des besoins, plutôt que sur la conception de solutions.
L’approche RML® est donc un outil de modélisation des exigences qui s’applique à pratiquement tous les logiciels – car presque tous les produits retraitent des données. Même le plus simple des Business Data Diagram, comprenant uniquement quelques catégories de données, peut aider à collecter les règles métier auxquelles le système doit se conformer, aider à réfléchir aux user stories, et modéliser une compréhension fonctionnelle commune permettant de travailler aussi bien avec les utilisateurs et les développeurs.
Concrètement, voici comment ça se passe. Tout d’abord, le Product Owner ou le Business Analyst rédige une première itération du BDD au début du projet (disons pendant le sprint 0 ou la phase de planification). Ce modèle sera amené à évoluer au fur et à mesure que de nouveaux objets métiers sont identifiés dans le cadre du produit à créer. Les BDD peuvent également aider à identifier au début du projet d’autres business models qui pourraient s’avérer nécessaires, par exemple pour décrire des objets métier dont le cycle de vie nécessite un workflow et une modélisation d’états supplémentaires.
Pour identifier les objets à décrire dans le BDD, ainsi que les relations qu’ils ont entre eux, le Product Owner ou le Business Analyst utilise la connaissance collectée auprès des contributeurs et experts du projet. Ce sont eux qui transmettent leur expérience de gestion et d’utilisation des données d’un point de vue opérationnel.
Les analystes IT et les architectes sont également sollicités pour contribuer à la modélisation du Business Data Diagram, car ils l’utiliseront par la suite (ou en parallèle, sur les projets agiles) pour créer l’architecture logicielle et pour définir les données techniques.
Voici un exemple de ce à quoi peut ressembler un BDD :
Je ne sais pas pour vous, mais en ce qui me concerne, cela me fait diablement penser à la méthode MERISE avec ses modèles de données et de traitement ! Si vous avez déjà lu mes articles, vous comprendrez pourquoi je vous invite régulièrement à ne pas être dogmatique face aux nombreuses méthodes et techniques qui fleurissent avec en préfixe un ® ou un © ou un ™.
Ce qu’en disent les Business Analysts
Voici un témoignage intéressant de Megan Jackson, Business Analyst expérimentée aux Etats-Unis (je fouille souvent du côté de nos amis américains pour vous dénicher des retours d’expérience, car ils sont très en avance sur nous, BA du Moyen-Âge francophone – la France étant tout-de-même le pays d’origine de la méthode MERISE dans les années 1970… ).
Je travaillais récemment sur un projet où nous avions d’énormes données d’exigences stockées dans des emplacements séparés :
- l’un était un ensemble de milliers de règles métier, basées sur l’éligibilité des utilisateurs autour des “événements” système.
- Les événements étaient regroupés au sein de groupes de “processus” de ce même système, et répertoriés à l’intérieur d’une autre grande matrice d’exigences, les user stories étant également mappées sur les caractéristiques et les étapes du processus.
- Un troisième ensemble comprenait des exigences fonctionnelles détaillées concernant la saisie des données utilisateur et l’affichage des champs, en lien avec les étapes des processus.
Il aurait été impossible de combiner ces trois documents en un seul, mais nous voulions nous assurer d’avoir une traçabilité complète des trois groupes d’exigences, tout en conservant le détail des exigences pour chaque caractéristique et processus du produit.
Afin de modéliser les relations entre chaque objet d’exigence, nous avons créé un BDD montrant les relations, les cardinalités et l’emplacement stocké de chaque objet d’exigence.
Megan Jackson, Business Analyst
Et vous, comment faîtes-vous pour modéliser de grands volumes d’exigences ? N’hésitez pas à laisser vos témoignages en commentaire 😊
Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!
