Rappelons que la spécification des exigences fonctionnelles concerne le produit tel qu’il est ou tel qu’il sera à l’instant t et donc les artefacts à considérer ne sont pas les tickets de réalisation mais ceux de l’architecture fonctionnelle, par exemple les cas d’utilisation (UC composés de tâches métiers) ou un parcours client composé de macro-UC (MUC).
BML pour rédiger les exigences fonctionnelles des artefacts métiers
Prenons l’exemple ci-après pour montrer un exemple BML de cette nature, c’est-à-dire utilisant la palette de modélisation métier que nous avons vue dans un précédent article.
Pour produire progressivement des scénarios de test d’un macro-élément contenant des éléments, ceux-ci ayant déjà été testés, il suffit d’appliquer un algorithme sur les cibles possibles de son modèle graphique.
La forme textuelle, bien que possible, n’est pas utile et efficace pour générer les tests … Nous l’expliquerons avec un prochain article décrivant “l’algorithme des tamis successifs” pour ces macro-fonctionnalités.
Equivalence d’une modélisation graphique et d’exigences haut niveau
Chaque élément graphique peut donner lieu à une phrase de type “gabarit d’exigence”.
Suivant le gabarit on peut avoir différentes exigences. Par exemple (d’autres choix de gabarit pourrait être possible) :
- Etant donné que je suis manager,
Quand j’exécute “Faire le traitement A”
Alors X est calculé (X>=0 ou X<O)
Les 2 alternatives sont mises en avant par l’analyste, car ces 2 cas sont importants pour la suite de l’exécution du modèle, même si X est calculé et suffit pour le développeur du traitement A.
De plus, ce choix de l’analyste est conforme à la table de décision interne au traitement A. Celui-ci vise in fine le calcul de X et on peut cerner, à ce niveau de détail, 2 “objectifs” importants : X>=0 et X<0, même si en interne du traitement A on a pu tester bien des possibilités pour atteindre ces objectifs.
- Etant donné que “Faire le traitement A” a été exécuté par le manager
Quand (Y=1 ou Y=2) ET Z=1
Alors le traitement “faire le traitement B” peut être exécuté
On voit que le modèle graphique est plus compact que l’énoncé des règles métiers textuelles. Le nombre d’exigences textuelles peut en effet devenir important.
Nous retiendrons donc la modélisation graphique comme support de la réflexion à venir sur les scénarios de test de ces macro-fonctionnalités (scénarios que nous pourrons appeler en agile “critères d’acceptation” …).
Le modèle graphique est autosuffisant
Quand un PO réalise ses tests, il a besoin d’un guide pour son scénario, pas d’une liste détaillée de cas. Il sait prendre de la hauteur et connaît ses applications. Par analogie avec la vie courante, pour aller d’une ville A à une ville B par les nationales, vous avez besoin de la liste des villes traversées vous permettant de suivre la direction à suivre, même dans les villes, pas d’un roadbook détaillant chaque carrefour !
Le modèle graphique fournit des transitions et des alternatives possibles à utiliser … Il n’est pas nécessaire de documenter en tables de décision supplémentaires à ce niveau. L’agilité prend son sens avec ce formalisme simple : il est auto-porteur pour les métiers.
L’auteur
Didier JOLIOT, Ingénieur Coach agile et formateur
Didier a une grande expérience professionnelle : développeur puis responsable qualité et certification de logiciels temps réels critiques. Ex : Airbus (A320, A340), missiles, spatial, nucléaire, sous-marins, … Il a été ensuite expert spécifications et tests auprès d’équipes MOE, puis de MOA bancaires. Il a été aussi directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il pratique depuis 2012 l’agilité. Il a été coach agile pour le Product management de très gros projets « agiles à l’échelle » au Crédit Agricole et à la Société Générale, et pour de nombreuses équipes Scrum.
Il a écrit 5 livres et de nombreux articles. Il enseigne, depuis des années, dans plusieurs écoles d’ingénieur et dans les entreprises. Il a créé, de plus, plusieurs méthodes : le langage « Business Modeling Language (BML) », l’algorithme ATDD des tamis successifs, la CNV-A, etc.
