Les Inclassables

Tutoriel : le Business Requirements Document (BRD)

A la base d’un projet informatique réussi, on retrouve souvent un document d’exigences métiers de qualité : le Business Requirements Document (BRD). Le BRD décrit les problèmes métiers que le projet tentera de résoudre ainsi que les résultats attendus de la solution cible. En d’autres termes, un Business Requirements Document détaille la valeur ajoutée du projet. Savez-vous bien le rédiger ?

Le BRD est le fil conducteur du projet, permettant à tous les intervenants de partager la vision et les objectifs métiers à atteindre. Cependant, comme beaucoup de documentation que l’on rencontre sur les projets de systèmes d’information, le BRD peut facilement devenir source d’ambiguïté, voire être difficile à appliquer au moment de la conception fonctionnelle et technique. Et il arrive même que, dans certains cas, le BRD induise tellement en erreur qu’il fasse dérailler le projet.

>> Lire aussi : Pourquoi 83% des projets informatiques échouent-ils ?

Pourquoi 71pc des projets échouent ils
Pourquoi 71pc des projets échouent-ils

 

En 2015, le Standish Group a publié une étude internationale massive (le Standish Group Chaos Report 2015) après avoir analysé plus de 10000 projets informatiques du monde entier, de toutes tailles et couvrant de multiples secteurs d’activité.

 

Seuls 29% des projets informatiques réussissent

Bien qu’en progression par rapport à sa dernière mouture de 1995, le taux de réussite des projets IT reste dramatiquement bas – aux alentours de 30%. Les méthodes agiles, dont l’utilisation remplace progressivement la gestion de projet traditionnelle, sont un facteur clé d’amélioration de ces statistiques. Du moins, lorsque l’agilité est bien appliquée, comme le démontre clairement le rapport !

 

>> Lire aussi : Marre des pseudo-projets agiles !

 

Ce qui est intéressant, c’est l’analyse des causes expliquant pourquoi 71% des projets IT continuent d’échouer. Celles-ci ont été identifiées par le biais de sondages qualitatifs principalement réalisés auprès des Directions des Systèmes d’Information (DSI).

Les facteurs suivants (non hiérarchisés) font partie du Top 5 des DSI permettant d’expliquer l’échec de leurs projets informatiques :

  • Une équipe projet peu ou pas assez qualifiée,
  • Le manque de maturité émotionnelle du management (attentes irréalistes, peu de recherche de consensus…),
  • Pas ou peu de recherche d’optimisation de la chaîne de valeur de l’organisation,
  • Le manque d’implication des utilisateurs,
  • Et des objectifs métier peu clairs.

 

Le BRD : la pierre angulaire pour des objectifs métier clairs et partagés

Un Business Requirements Document exhaustif et bien rédigé est l’une des pierres angulaires pour partager une vision et des objectifs métiers clairs auprès de toutes les strates de l’organisation et de l’équipe projet. Ce document est donc un facteur clé de succès des projets informatiques.

Un BRD décrit les aspects métiers d’un projet : besoins et attentes de l’utilisateur, but de la solution cible ainsi que toutes les contraintes de haut niveau qui pourraient avoir un impact sur le succès de la mise en œuvre.

L’objectif principal d’un BRD est de :

  • Servir de ligne directrice, de fil rouge aux parties prenantes afin de s’assurer que le projet reste aligné sur les objectifs généraux de l’entreprise ;
  • Aider à la priorisation des choix de conception ;
  • Aider à cadrer précisément le périmètre fonctionnel du projet.

 

BRD, cahier des charges, Spécifications Fonctionnelles Détaillées

Un Business Requirements Document décrit les besoins métiers du point de vue du client et des utilisateurs finaux.

 

>> Lire aussiTutoriel : identifier les besoins métiers

 

Il est parfois confondu avec d’autres documents qui, pourtant, n’ont pas du tout la même vocation :

  • Le cahier des charges : il définit le contexte du problème que souhaite résoudre l’organisation, précise l’objectif du projet, formalise les besoins de haut niveau, et définit les aspects commerciaux et contractuels de mise en œuvre. Ce document est donc un livrable officiel, signé par la maîtrise d’œuvre et la maîtrise d’ouvrage, qui engage les deux parties autour d’un projet commun.
  • Les Spécifications Fonctionnelles Détaillées (que l’on peut également rencontrer sous le terme de SRD – System Requirements Document) décrivent très précisément comment le logiciel ou le système d’information cible va satisfaire les besoins métier retenus. Les SFD sont beaucoup plus spécifiques, ciblées et rédigées du point de vue du système cible. Les exigences fonctionnelles et non fonctionnelles décrites représentent ainsi les moyens mis en œuvre pour satisfaire les exigences métier.

 

>> Lire aussiComment décrire les exigences non fonctionnelles

 

Bien que la distinction ait l’air subtile, il est important de ne pas faire la confusion entre Business Requirements Document, cahier des charges et Spécifications Fonctionnelles Détaillées.

En effet, une erreur fréquente est de commencer à décrire la solution avant d’avoir défini et acté l’ensemble des besoins métier – qui est la raison d’être du Business Requirements Document.

Le BRD devrait donc être rédigé avant de démarrer les activités de maîtrise d’œuvre.

 

Les éléments clés du BRD

La plupart des entreprises utilisent des modèles de documentation, et fournissent aux Business Analysts un « template », c’est-à-dire un cadre structuré permettant la rédaction de BRD standardisées.

Cette structure et ce format peut varier selon les organisations. Néanmoins, un BRD bien rédigé devrait être constitué des éléments suivants :

  • Objectif et description du projet : vision, objectifs et contexte
  • Facteurs de succès
  • Périmètre du projet : situation actuelle et situation future souhaitée
  • Identification des parties prenantes principales
  • Description des besoins métiers auxquels le projet devra répondre
  • Périmètre et portée de la solution
  • Contraintes métiers applicables au projet. C’est ici que l’on peut parfois confondre BRD avec cahier des charges, car certaines entreprises ajoutent dans cette section le calendrier et le budget du projet.
  • Mesures de contrôle de la qualité : il s’agit des indicateurs permettant de vérifier l’adhérence de la solution aux besoins métier.

 

Le BRD inclut fréquemment la cartographie des processus métiers existants, parfois également les besoins de formation, et autres objectifs liés à la conduite du changement.

>> Lire aussiLes 6 erreurs classiques en modélisation des processus (et comment les éviter)

 

7 conseils pour rédiger un BRD

Malheureusement, ce n’est pas parce que je vous donne cette trame d’un bon Business Requirements Document que vous aurez en main la baguette magique permettant de réduire à néant vos risques projet…

Le contenant ne fait pas la qualité du contenu. Voici donc mes conseils pour mettre de votre côté toutes les chances de bien rédiger vos BRD.

  • Peaufinez l’élicitation : le recueil des besoins exprimés, non exprimés, cachés ou latent est tout un art qui s’appuie sur des techniques variées. Cela ne s’improvise pas, alors soignez cette étape cruciale préalable à la rédaction de votre BRD.
  • Initiez l’ingénierie des exigences au plus tôt – et cela commence dès le BRD. N’oubliez pas que vous serez amené à tracer les liens entre la vision du projet, les besoins métier, les exigences de la solution, et les cas de tests. Un BRD bien rédigé permet de tracer ce lien : il ne s’agit donc pas d’écrire un document philosophique de 1200 pages, ni une synthèse de 2 pages. Gardez donc cet objectif en tête en rédigeant votre Business Requirements Document.
  • Identifiez les principales parties prenantes. Une partie prenante est une organisation, un individu ou un groupe d’individus qui trouve un intérêt à la solution cible, même s’il n’en est pas l’utilisateur final. Bien identifier les principales parties prenantes permet par conséquent de balayer la source des besoins métiers et de sécuriser la définition d’objectifs clairs et partagés.
  • Utilisez un langage clair et non ambigu que tout le monde peut comprendre. Si vous recourez à des acronymes ou à du jargon métier, n’oubliez pas de les définir dans une rubrique dédiée ou dans un glossaire séparé. Cela vous resservira ultérieurement, pour réaliser vos analyses complémentaires, votre conception fonctionnelle, vos tests métier, ou encore les supports de formation utilisateur.

 

>> Lire aussi: Le cauchemar des acronymes (Le Petit Guide de survie pour une communication claire)

 

  • Exploitez les Retours d’expérience
    • Les retours d’expérience sont un bon moyen de démarrer votre processus de documentation, en recherchant des projets similaires que votre organisation a réalisés par le passé.
    • Examiner la documentation de ces projets et utilisez ces informations pour vous aider à identifier les exigences et autres points clés à inclure dans votre propre BRD. Ces projets peuvent également aider votre équipe à justifier certaines exigences sur la base de résultats antérieurs positifs.
  • Faites valider le BRD une fois que vous l’aurez rédigé. Cette étape est cruciale pour ne pas passer à côté d’exigences clés ou risquer de laisser des erreurs critiques qui pourraient mettre votre projet sur la mauvaise voie. Ne croyez pas que vous pouvez rédiger un document aussi important pour la réussite du projet tout seul dans votre coin… La réussite comme l’échec se jouent en équipe.
  • Incluez des éléments visuels: une image vaut mille mots. Les diagrammes, les maquettes et autres éléments visuels permettent non seulement de lever les ambiguïtés, mais également et surtout de décrire simplement des informations complexes.

Voilà pour cette introduction et ce tutoriel au Business Requirements Document. J’espère que cela vous a aidé à mieux comprendre son importance dans le succès de vos projets de systèmes d’information et que vous serez désormais en mesure de définir et partager les objectifs métiers clairs et non ambigus 🙂

Cet article vous a plu? Partagez-le et suivez-moi sur les réseaux sociaux!

Share on facebook
Share on twitter
Share on linkedin
Alice Svadchii
Alice Svadchii
Auteure du blog et Business Analyst enthousiaste

2 réflexions au sujet de « Tutoriel : le Business Requirements Document (BRD) »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *