La notion d’exigence est centrale en business analyse. Beaucoup de personnes confondent une exigence et un besoin, souvent par méconnaissance, manque de formation aux bonnes pratiques de l’analyse métier, ou encore à cause d’une erreur de traduction du terme anglais « requirement ».
Avant que le logiciel ou le système d’information soit développé par l’équipe technique, le ou la business analyst identifie et analyse les besoins métier, puis définit en détail les exigences de la solution cible. C’est ce qu’on appelle la conception fonctionnelle.
L’un des écueils à franchir pour sécuriser la qualité logicielle est de rédiger des exigences fortes – par opposition aux exigences faibles.
Avant d’expliquer l’importance de bâtir la conception fonctionnelle d’un système d’information sur des exigences fortes, je vous propose de lever l’ambiguïté et les abus de langage autour de la notion de besoin et d’exigence.
La norme de qualité AFNOR NF X50-150 nous explique qu’un besoin est une nécessité, un désir, un manque ou une insatisfaction éprouvée par un utilisateur ou un client.
Besoins vs. exigences
La spécificité d’un besoin, qui constitue une différence majeure avec l’exigence, est que celui-ci n’est pas toujours exprimé – et quand bien même il l’est, méfiez-vous, car il peut ne pas correspondre au besoin racine à satisfaire.
De son côté, le terme d’ « exigence » représente une condition ou une capacité que doit impérativement posséder un produit ou un service.
Les catégories d’exigences diffèrent selon les normes de qualité (IEEE, ISO, CMMi), et les schémas de certification à la Business Analyse ou à l’ingénierie des exigences ne sont pas non plus tous d’accord sur leur classification.
Personnellement, je distingue les exigences fonctionnelles, les exigences non fonctionnelles et les exigences de transition. Retenez en tout cas qu’un besoin métier n’est pas forcément traduit en exigence dans le logiciel cible.
Lire aussi : Gérez vos exigences avec la matrice de la Connaissance et de la Conscience
Exigences fortes vs. exigences faibles
Alors, qu’est-ce qu’une exigence forte ? Les exigences fortes peuvent être définies comme les descriptions détaillées et documentées d’une demande émanant d’un utilisateur ou d’un client, qui permettent de comprendre les exigences de la solution de leur point de vue.
A contrario, si les exigences faibles documentent elles aussi en détail une demande émanant d’un utilisateur ou d’un client, elles font abstraction du point de vue de ces derniers.
On peut donc dire que les exigences fortes sont « customer centric » tandis que les exigences faibles sont « product centric ». Historiquement, les logiciels informatiques étaient développés par des développeurs IT sans trop se préoccuper si le résultat apportait de la valeur ajoutée aux utilisateurs finaux. La technologie prévalait sur la satisfaction client, et c’est d’ailleurs encore le cas dans de nombreux projets de systèmes d’information.
Lire aussi : Comment tirer profit des réclamations de vos clients
Depuis des années, cette vision « product centric » que l’on retrouvait d’ailleurs en marketing et dans les préoccupations de développement commercial des entreprises, a évolué vers la vision « customer centric ». L’entreprise place enfin le client au cœur de ses préoccupations.
Décrire des exigences fortes est tout un art – celui du Business Analyst formé à son métier, ce qui, je vous le rappelle, n’est le cas que de 2% d’entre eux dans les pays francophones. 98% des BA sont autodidactes, faute de formation disponible et de conscience – par leurs employeurs – de l’impact de leur non-formation sur la réussite de leurs projets de systèmes d’information.
[Master Class] Devenir Business Analyst en S.I.
Les Fondamentaux de A à Z
50 heures de formation qualifiante complète en e-learning pour se professionnaliser au métier de Business Analyst en systèmes d'information.
La conception fonctionnelle basée sur les exigences fortes
Ainsi, au moment de la phase de conception fonctionnelle de la solution, l’immense majorité des Business Analysts recueillent comme ils le peuvent des informations hétérogènes appelées par abus de langage « besoins métier ».
En réalité, on a dans le lot :
- Des informations contextuelles,
- Des contraintes,
- Des règles métiers,
- Des besoins métiers exprimés et conscients (le plus dur étant d’éliciter les besoins inconscients, latents, cachés),
- Des exigences fonctionnelles non priorisées,
- Des exigences non fonctionnelles (celles qui sont conscientisées),
- Des exigences techniques (qui n’ont rien à faire là)
- Et éventuellement quelques exigences de transition.
Difficile, dans ce cas, de concevoir une solution informatique solide, satisfaisante, sur la base d’exigences fortes.
L’impact de la qualité des exigences sur le projet et le logiciel
Les exigences faibles impactent négativement la réalisation du logiciel, augmentant son délai de livraison, encourageant la désinformation, déclenchant des modifications de planning de dernière minute, et in fine, entraînant une dilapidation de temps et de ressources ainsi une déperdition de qualité.
La qualité des exigences a donc un impact sur toute une chaîne d’événements et de ressources utilisés pour faire progresser le traitement d’une demande client jusqu’à la livraison ou la mise à jour du logiciel.
Le processus de haut niveau de cet enchaînement d’activités et de ressources commence par la communication de la bonne compréhension, par le Business Analyst, de la demande du client. L’étape d’après est la priorisation et la planification des activités et tâches nécessaires au traitement de la demande. Par la suite, le Business Analyst doit faire le lien avec l’équipe technique, s’assurant de la compréhension claire et non ambiguë de la demande par les développeurs afin qu’ils créent la solution souhaitée. A la fin du processus, le retour des utilisateurs et du client permet d’évaluer la solution informatique créée et de confirmer son alignement sur les besoins métiers.
Les discussions initialement menées par le Business Analyst avec les utilisateurs et les clients pour clarifier leur demande constituent un point de départ crucial dans le processus d’élicitation d’exigences fortes. Cela peut bien entendu nécessiter plusieurs allers-retours (itérations) entre le business analyst, les pôles métiers, les développeurs, et le chef de projet.
Exemple de traduction d’une demande client en exigence forte
Pour illustrer la façon dont une demande client peut être traduite en exigence forte, voici un exemple concret :
- Le client envoie par mail la demande suivante : “Livraison / Vs transferts internes, séparer l’interface de livraison de l’interface de transfert”.
- Sur ce point de départ, le Business Analyst pose sa compréhension et ses questionnements :
- Le client a une demande,
- La demande n’est pas bien définie,
- La demande initiale implique que :
- Le système existant a apparemment une fonctionnalité intégrant la livraison et le transfert,
- Une fonction de transfert est donc, dans le système actuel, une sous-fonction incluse dans la fonction de livraison,
- Le client souhaite que les fonctions de livraison et de transfert soient séparées,
- Cette demande entraînera probablement des modifications de l’interface utilisateur et du flux de travail.
En tant que BA, nous nous retrouvons donc, à ce stade, avec de nombreuses questions et clarifications complémentaires à obtenir. Nous identifions que nous devons aller nous renseigner auprès du demandeur (pôle métier), mais également auprès de l’équipe technique pour mieux comprendre comment fonctionne le SI, quelles sont les contraintes de la fonction livraison / transfert, les interconnexions avec des systèmes externes etc.
Pour affiner cette demande et en faire une exigence forte, il a donc fallu interroger le client afin d’obtenir la compréhension claire, exhaustive, non ambiguë et consensuelle de ce qu’il voulait et pourquoi il en avait besoin.
La sur-analyse : le risque caché d’éliciter des exigences fortes
L’un des risques cachés lorsqu’on commence à clarifier et affiner la demande d’un utilisateur dans le but d’en faire une exigence forte est de provoquer une situation de “paralysie analytique”. En gros, plus on cherche, plus on trouve, et plus on doit continuer de chercher pour comprendre et s’assurer qu’on n’a rien oublié. La phase d’analyse peut vite devenir un parcours sans fin.
N’allez donc pas plus loin que nécessaire dans la recherche d’informations détaillées, et pas au-delà d’un certain périmètre que vous aurez identifié au préalable. Faites-le suffisamment rapidement pour obtenir des résultats en temps voulu. Si vous identifiez des risques à ne pas éliciter des problématiques que vous venez de découvrir, échangez immédiatement avec le chef de projet pour savoir si une gestion des risques est nécessaire ou si une modification des délais est envisageable pour sécuriser la conception fonctionnelle.
En synthèse
Il est crucial de prendre le temps de construire des exigences fortes centrées sur le point de vue utilisateur. Les conséquences d’appuyer la conception fonctionnelle sur des exigences fortes sont, entre autres, les suivantes :
- La diminution du risque d’apparition d’événements inattendus (par exemple, la découverte de besoins non exprimés ou cachés) ;
- La sécurisation de la livraison dans les délais d’un logiciel satisfaisant les besoins métiers ;
- La compréhension claire et partagée par le métier et l’IT des attentes des parties prenantes ;
- L’alignement entre les visions stratégique, tactique, opérationnelle et technologique.
Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!
Source : point de départ pour cet article inspiré par le billet de Timothy Figueroa, puis largement complété par mes propres réflexions
