Nous sommes dans le contexte d’une US INVEST, non décomposable au sens métier :
En tant que < utilisateur 1 ou utilisateur 2 …>,
Je veux pouvoir <“libellé de l’US”>
Afin de <justification de l’US>
Cette US a des propriétés associées, notamment une valeur (V), un effort (E en story point), un ROI (V/E), une priorité (P). C’est une tâche de notre produit.
Notions de base de BML
Sachant que nous avons spécifié dans le libellé de l’US qui sont les utilisateurs (En tant que …), les règles de gestion en BML (gabarit de la marque Modern Product Agility) suivent le canevas suivant :
Quand < condition 1> ET < condition 2> ET …
Alors <observation 1> ET <observation 2> ET …
- L’ensemble des conditions s’appelle “clause”
- L’ensemble des observations s’appelle “résultat”.
BML est un langage de spécification des exigences fonctionnelles de la solution. Ce ne sont pas les critères d’acceptation !
Détail des conditions et observations
BML spécifie dans le détail par un ensemble de règles qui définissent la grammaire utilisée :
- Chaque condition est composée de une ou plusieurs affirmations
- Chaque observation est une et une seule affirmation
- Une affirmation : composée d’un “groupe sujet”, d’un “groupe verbal” et éventuellement d’un “groupe complément”.
On entend par groupe verbal, un verbe, ou un verbe agrémenté de détails. Exemples :
- Est (verbe)
- Est supérieur à (groupe verbal)
On entend par groupe sujet (ou groupe complément) un groupe centré sur un nom.
Ex : âge de l’enfant, crédit à la consommation
- Un sujet ou un complément typés : il peut s’agir (liste non exhaustive, mais qui peut être extensible) :
- D’une donnée attribut d’un “Objet Métier”. Par exemple : “l’âge d’un enfant” (donnée âge pour l’objet métier Enfant).
- D’une donnée calculée dont le système est responsable de son évaluation. Ex : “le nombre de tentatives de connexion”, “le total des crédits en cours”, “le délai depuis tel événement”.
Cela peut être aussi le stockage par le système des constantes qui peuvent être modifiées par paramétrage. Ex : “l’heure annoncée de départ du train” …
- Un objet métier. Il s’agit souvent de parler d’un de ses statuts. Exemple : Le crédit à la consommation est “accepté”.
Dans une règle métier de haut niveau les utilisateurs s’expriment directement avec les statuts d’objet métier. Dans une règle de gestion d’US, le PO s’exprimera plutôt en invoquant l’attribut “statut” de la donnée.
- Une liste d’objets métiers. Exemples : “Clients ayant plus de 60 ans” (filtrage sur attribut(s)), “Clients possédant un livret A” (filtrage sur association(s)).
- Un élément fonctionnel du produit (tâche métier, UC, MUC). Il s’agit souvent de spécifier des règles de synchronisation entre eux.
Exemple : “Quand la fonctionnalité “Chercher un client” est terminée …
- Un objet graphique d’une IHM : un hyperlien par exemple.
Attention : si l’objet graphique est une forme de représentation d’une donnée (par exemple un bouton d’option, un choix dans une liste déroulante), on n’utilise pas la représentation de design (qui peut varier) mais la donnée comme sujet (on ne dira pas “la case à cocher “bonus” est sélectionnée, mais “le bonus est choisi”, comme le dit un utilisateur métier)
- Une photo ou une vidéo. Ex : Quand la photo de l’auteur pèse plus de 1Mo, Quand la photo de l’hôtel est inacceptable (floue, rognée, …)
BML et la logique entre affirmations
Souvent les exigences sont posées sans contraintes sur les connecteurs logiques entre affirmations. BML impose ses contraintes.
- Dans une condition on peut avoir 2, ou plus, affirmations, sur un même sujet et séparés par un “OU”.
L’exemple courant est illustré par : le groupe verbal <=.
X<=10 peut se décomposer, d’une part en “X est < 10”, d’autre part X=10.
Donc on peut avoir X<10 OU X=10 (bien que souvent on laisse les symboles <= et le “OU” reste alors “caché”).
Ou encore, et cela devient plus intéressant : X est < 10 OU X>20
Autre exemple de conditions : la lumière du projecteur est de couleur fondamentale (blanc OU noir), OU primaire (rouge OU jaune OU bleu) – sous-entendu, elle n’est pas secondaire (vert OU orange OU violet).
On voit qu’une affirmation (ex: la lumière du projecteur est de couleur fondamentale) laisse des possibilités de plusieurs valeurs de donnée.
- On ne peut pas avoir dans une même condition un “OU” sur des sujets différents. Il faut 2 règles de gestion différentes, même si les deux RG ont des résultats identiques.
- Les affirmations des observations sont séparées par un ET.
Exemples et contre-exemples
Pour rendre les choses explicites …
| Libellé RG | Exemple BML | Contre-exemple BML : pb |
| Quand X>=0 Alors … | X | |
| Quand X=0 ET Y>0 Alors … | X | |
| Quand X=0 OU Y=0 Alors … | Ecrire : Quand X=0 Alors … Quand Y=0 Alors … | |
| Quand X=0 ou X compris entre 10 et 20 (bornes comprises) Alors La couleur du drapeau n’est pas verte (orange ou rouge) | Quand orange ? Quand rouge ? | |
| Quand la photo est de format non compatible (jpeg ou png) OU la photo pèse plus de 1 Mo Alors la photo est refusée (message d’erreur) | X (à condition que le message d’erreur soit le même) |
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.
