BRD (Business Requirement Document) : définition et structure

Dans un projet informatique, l'écart entre ce que le commanditaire voulait et ce que l'équipe a livré vient rarement d'une faute de code. Il vient d'un besoin jamais écrit, ou écrit de façon si vague que deux lecteurs en tirent deux conclusions différentes. Le BRD, ou document des exigences métier, existe pour fermer cet écart avant qu'il ne coûte des mois.

On le trouve sur les projets ERP, les développements applicatifs, les migrations de systèmes et les refontes de processus. Sa rédaction est le cœur du métier de business analyst, parce qu'elle demande de traduire dans une même langue ce que disent les utilisateurs finaux et ce qu'attendent les développeurs.

Le contenu d'un Business Requirement Document

Le BRD décrit de façon structurée les besoins fonctionnels d'un projet du point de vue de l'entreprise. Il énonce ce que la solution doit permettre, jamais la technologie qui la portera. On y trouve six blocs :

• Le contexte et la problématique : pourquoi ce projet existe, quel dysfonctionnement ou quelle opportunité le déclenche.
• Les objectifs métier : les résultats attendus pour l'organisation, gain de productivité, réduction des coûts, amélioration de l'expérience client.
• Les parties prenantes : qui est concerné, qui décide, qui subira le changement.
• Les exigences métier : la liste numérotée de ce que le système doit faire.
• Les contraintes : budget, délais, obligations légales, dépendances avec d'autres chantiers.
• Les critères d'acceptation : ce qui permettra de dire, à la fin, que le projet a atteint son but.

Le BRD se distingue du SRS (Software Requirements Specification), rédigé par les équipes techniques. Il s'adresse à des lecteurs qui ne sont pas développeurs et doit rester lisible par un directeur métier.

BRD, FRD et SRS

Trois documents d'exigences coexistent sur un même projet, à trois niveaux de détail. Le BRD capture le besoin de l'entreprise et répond à la question de savoir ce que le projet doit accomplir pour l'organisation. Le FRD (Functional Requirement Document) traduit ces besoins en fonctionnalités précises, écran par écran, règle par règle. Le SRS descend au comportement du logiciel, avec les cas d'utilisation détaillés, les règles de gestion et les exigences non fonctionnelles de performance, de sécurité et de disponibilité.

Le plan type en huit parties

Aucun modèle n'est imposé, mais la structure suivante s'est stabilisée dans les grandes organisations et dans la communauté des business analysts réunie autour de l'IIBA.

1. Résumé exécutif. Une page au maximum, avec l'enjeu et les bénéfices attendus. Chez beaucoup de décideurs, c'est la seule partie lue en entier, elle doit donc se suffire à elle-même.

2. Contexte et problématique. La situation actuelle, ses dysfonctionnements chiffrés quand c'est possible, et ce qui justifie d'engager des moyens maintenant.

3. Périmètre. Ce que le projet couvre et, tout aussi explicitement, ce qu'il ne couvre pas. Cette liste des exclusions est le seul rempart contre l'extension progressive du périmètre en cours de route.

4. Parties prenantes. Les acteurs, leur rôle, décideur, utilisateur, contributeur ou simplement impacté, et ce que chacun attend du projet.

5. Exigences métier. Le cœur du document. Chaque exigence est numérotée, formulée en langage métier et priorisée, le plus souvent selon la méthode MoSCoW.

6. Contraintes et hypothèses. Les limites connues d'un côté, budget, calendrier, réglementation, et de l'autre les hypothèses de travail dont la remise en cause ferait tomber le raisonnement.

7. Critères d'acceptation. Les conditions vérifiables du succès, qui serviront de base aux tests de recette utilisateur.

8. Annexes. Glossaire des termes métier, description des processus existants, maquettes ou captures d'écran.

Écrire une exigence qui se teste

Une exigence utilisable se reconnaît à ce qu'un testeur peut la vérifier sans demander d'explication à son auteur. Trois défauts la rendent inutilisable, et ils se corrigent tous de la même façon, en remplaçant l'adjectif par une mesure.

Le dernier exemple illustre l'omission la plus coûteuse, celle des cas limites. Un BRD qui ne décrit que le chemin nominal laisse l'équipe de développement inventer le comportement en cas d'erreur, de saisie hors norme ou d'indisponibilité d'un service tiers. Ces choix improvisés reviennent en recette sous forme d'anomalies que personne ne peut trancher, faute de référence écrite.

Qui le rédige, et selon quel processus

La rédaction est pilotée par un business analyst, appelé selon les organisations analyste fonctionnel ou chef de projet MOA. Son travail consiste à faire tenir dans un document unique des besoins exprimés par des personnes qui ne se parlent pas toujours.

• Collecte : entretiens avec les utilisateurs clés, ateliers, observation des processus réels, lecture de la documentation existante.
• Formalisation : transformation de besoins souvent informels et contradictoires en exigences claires et vérifiables.
• Validation : revue avec les parties prenantes, exigence par exigence, jusqu'à ce que chacune soit comprise de la même façon par tous.
• Approbation : signature par les décideurs, qui ouvre officiellement la phase de conception.
• Gestion des changements : toute évolution de besoin passe par une mise à jour du document et une nouvelle validation.

Un BRD mal rédigé fait plus de dégâts qu'un BRD absent, parce qu'il donne l'apparence d'un accord là où il n'y en a pas. La confusion la plus répandue reste celle entre le besoin et la solution. « L'utilisateur consulte son solde à jour » est une exigence. « Le solde est stocké dans une base PostgreSQL » est un choix d'architecture qui appartient au SRS, et qui, glissé dans un BRD, ferme une option technique avant même que la question ait été posée.