BRD vs FRD

Dernière mise à jour le 4 décembre 2023 par Ewen Finser

La documentation du projet est l'une des étapes les plus critiques de tout processus de développement d'entreprise ou de logiciel. Les parties prenantes doivent avoir une compréhension commune de ce qu'elles veulent construire. En documentant avec précision les exigences, les entreprises peuvent éviter les dérapages, s'assurer que tout le monde est sur la même longueur d'onde et accélérer le développement. 

Une étude réalisée en 2014 par le Project Management Institute (PMI) révèle que 37% des projets échouent en raison d'une collecte inexacte des exigences. En établissant des exigences correctes dès le départ, on évite de devoir procéder à des modifications coûteuses par la suite.

Les analystes commerciaux utilisent généralement deux exigences différentes documentsLe document des exigences commerciales (BRD) et le document des exigences fonctionnelles (FRD). Cependant, d'autres documents existent, et ils fonctionnent ensemble pour fournir une vue d'ensemble du projet.

Certains de ces documents comprennent :

• Document sur les exigences du produit (PRD)
• Document de spécification des cas d'utilisation (USD)
• Matrice de traçabilité des exigences (RTM)
• Document sur les exigences du marché (MRD)
• Histoires d'utilisateurs 

Nous nous concentrerons ici sur BRD vs FRD. Ces deux documents sont importants, mais ils ont des objectifs différents. Nous verrons plus loin en quoi ces deux documents diffèrent, quelles sont leurs caractéristiques et quand il convient d'utiliser chacun d'eux.

La ligne de fond au départ

La principale différence entre le DRB et le DRF est que le DRB se concentre sur ce que le produit doit faire alors que le DRF se concentre sur la manière dont le produit doit le faire.

Un document d'exigences commerciales (BRD) est un contrat formel entre le client et le fournisseur qui capture tout le travail d'un projet. Un document d'exigences fonctionnelles (FRD) définit de manière exhaustive la solution requise pour répondre aux besoins de l'entreprise identifiés dans le BRD.

Principales différences entre BRD et FRD

Les principales différences entre BRD et FRD sont les suivantes :

• Le public principal d'un BRD est constitué des parties prenantes, des clients et des consommateurs, tandis que le public principal d'un FRD est constitué de l'équipe de développement, des ingénieurs et des testeurs.
• Un BRD décrit ce que le produit doit faire, tandis qu'un FRD décrit comment le projet doit le faire.
• Un BRD a pour but d'obtenir les exigences du client, tandis qu'un FRD a pour but de définir les exigences pour l'équipe de développement. 
• Le format d'un BRD est libre, avec un mélange de textes et de visuels, alors que le format d'un FRD est plus rigide, utilisant souvent Langage de modélisation unifié (UML).
• Un analyste commercial prépare le document BRD, tandis que l'analyste commercial prépare le FRD sous la supervision d'un expert technique (c'est-à-dire un architecte).

Qu'est-ce qu'un document d'exigences commerciales (BRD) ?

Un document sur les besoins de l'entreprise (BRD) est une vue de haut niveau d'un projet. Les analystes métier utilisent les BRD pour définir les objectifs d'un projet du point de vue de l'entreprise ou de l'organisation. Il s'agit de l'une des premières étapes du processus de développement d'un logiciel, et il est généralement créé avant que le travail technique ne commence.

Les développeurs l'utilisent comme un outil pour exécuter le projet et construire la bonne solution. Le BRD contient une vue d'ensemble de ce que le produit doit faire, des personnes qui l'utiliseront et de la manière dont elles l'utiliseront. Il établit également des critères de réussite mesurables nécessaires pour évaluer si le produit final répond aux besoins de l'entreprise.

En tant que document qui établit les étapes ultérieures et guide le développement, un BRD est essentiel pour construire le bon produit. Chaque projet ayant ses propres exigences, l'analyste métier doit créer un BRD qui reflète précisément les besoins spécifiques du projet en question. 

Composants d'un document d'exigences commerciales (BRD)

Le caractère unique d'un BRD signifie qu'il n'existe pas de modèle standard pour ce document. Cependant, tous les BRD ont des caractéristiques et des éléments communs. Les éléments essentiels d'un BRD sont les suivants

1. Déclaration sommaire: L'exposé sommaire du BRD doit fournir une vue d'ensemble du projet. Il établit un lien entre les objectifs du projet et les besoins de l'entreprise. Il répond essentiellement à la question suivante : "Quel problème essayons-nous de résoudre et comment ce projet nous aidera-t-il à y parvenir ?"
2. Portée du projet: La portée du projet est une vue d'ensemble de ce que le projet permettra de réaliser et comprend les produits à livrer, les délais, les coûts et les risques. Il explique les responsabilités de l'organisation, de l'entreprise et de l'équipe de développement.
3. Aperçu des objectifs : La vue d'ensemble des objectifs énumère les buts spécifiques que le projet doit atteindre. Chaque objectif doit être SMART : spécifique, mesurable, réalisable, pertinent et limité dans le temps. Elle décrit le contexte du projet et énumère les parties prenantes, les moteurs de l'activité (opérationnels, commerciaux, financiers, etc.) et les principaux facteurs de réussite.
4. Processus d'identification des parties prenantes : Un processus d'identification des parties prenantes est un outil permettant d'identifier et d'analyser les parties prenantes d'un projet. Les analystes d'entreprise l'utilisent pour comprendre le rôle de chaque partie prenante, évaluer leur influence sur le projet et développer des stratégies pour gérer les attentes. 
5. Mesurables: Les mesurables sont des indicateurs clés de performance qui permettent d'évaluer si le projet a réussi. Les exemples incluent l'augmentation des revenus, la diminution des coûts ou l'augmentation de la part de marché.
6. Contraintes du projet: Chaque projet comporte des contraintes, c'est-à-dire des conditions ou des limites susceptibles d'affecter la réussite du projet. Les exemples les plus courants sont le budget, le temps, la portée et les ressources.

Ces composantes couvrent les éléments de base d'un BRD. Cependant, le document peut également inclure d'autres caractéristiques, comme des hypothèses et des risques spécifiques au projet. 

Objectifs d'un document d'exigences commerciales (BRD)

Un BDR est le fondement d'un projet, ses objectifs sont donc vastes. En général, un BDR doit :

• Obtenir les exigences des parties prenantes: Pour construire le bon produit, les développeurs doivent comprendre les besoins de l'entreprise. Un BRD est l'une des premières étapes de la collecte de ces besoins.
• Définir les critères de réussite: Les éléments mesurables du BRD permettent d'évaluer la réussite du projet.
• Minimiser les dérapages: En documentant les objectifs, les risques et les contraintes du projet, un BRD peut aider à prévenir les dérives.
• Servir de point de référence: Le BRD est un document vivant qui doit être constamment mis à jour. Cependant, c'est aussi un point de référence pour toutes les parties prenantes. Il fournit une vue d'ensemble des buts, des objectifs et des résultats attendus du projet.
• Établir un consensus avec les parties prenantes : Un BRD peut aider les analystes d'entreprise à obtenir l'adhésion des parties prenantes. En mettant tout le monde sur la même longueur d'onde dès le départ, ils peuvent éviter les malentendus et les désaccords.

Qu'est-ce qu'un document de besoins fonctionnels (FRD) ?

Un document d'exigences fonctionnelles (FRD) est un type de document d'exigences qui spécifie ce qu'un système doit faire et comment il doit fonctionner.  Il contient des informations plus spécifiques sur la manière dont le produit ou le projet doit fonctionner, y compris des descriptions de chaque caractéristique. Il s'agit en fait d'un dérivé du BRD, qui met en évidence les exigences fonctionnelles. 

Les analystes commerciaux, sous la supervision d'un expert technique, sont chargés de créer un FRD. Le document doit être clair, concis et exempt de jargon technique. Il doit également être facile à comprendre pour toutes les parties prenantes. Comme un BRD, il décrit également une vue d'ensemble de haut niveau des fonctionnalités, mais se concentre sur les détails techniques et spécifiques.

Par exemple, un FRD pour une application Web peut spécifier que la page de connexion doit comporter des champs pour un nom d'utilisateur et un mot de passe. Il décrira également comment le système doit gérer l'authentification. En revanche, un DRB pour la même application pourrait simplement indiquer que la page de connexion doit être sécurisée. 

Composants d'un document d'exigences fonctionnelles (DEF)

Il n'existe pas de norme fixe à laquelle tous les DRF doivent se conformer. Toutefois, la plupart des DRF comportent des éléments similaires, notamment

1. Introduction: L'introduction doit présenter le système et son objectif. Elle doit détailler l'objectif, la référence de la portée, les hypothèses et les contraintes du système. Les principales parties prenantes doivent également être identifiées.
2. Le contexte : La section sur le contexte fournit plus de renseignements sur le système. Elle doit décrire l'état actuel du système et les problèmes que le nouveau système est censé résoudre. 
3. Exigences fonctionnelles : La section des exigences est le cœur du FRD. Elle contient une liste de toutes les exigences fonctionnelles, organisées par catégorie. Chaque exigence doit avoir un identifiant unique, un nom, une description et une source. Dans certains cas, les exigences peuvent accompagner un critère d'acceptation.
4. Interfaces utilisateur: La section relative à l'interface utilisateur doit fournir une vue d'ensemble des interfaces du système. Elle doit décrire la manière dont les utilisateurs interagiront avec le système et toute exigence particulière concernant l'interface. 
5. Illustrations de modélisation : La section de modélisation doit fournir des représentations visuelles du système. Ces illustrations peuvent inclure des diagrammes, des organigrammes, des prototypes et des maquettes. Elles doivent également inclure les besoins des utilisateurs, les cas d'utilisation et d'autres modèles pertinents.
6. Glossaire : Le glossaire doit contenir une liste de tous les termes, acronymes et abréviations utilisés dans le DRF. Il doit également fournir des définitions pour chaque terme technique. 

L'utilisation des DRF dépend de l'organisation, du projet et du produit. Elle doit suivre les politiques, les processus et les procédures de l'organisation.

Objectifs d'un document de besoins fonctionnels (FRD)

Bien que les objectifs d'un FRD puissent varier d'une organisation à l'autre, il existe des buts communs que la plupart des FRD visent à atteindre, notamment :

• Définir la fonction d'un système : L'objectif premier d'un FRD est de définir la fonction d'un système. Il doit décrire ce que le système doit faire et comment il doit fonctionner. 
• Liens de dépendance : Un FRD doit également identifier toute dépendance entre les différentes fonctions. Par exemple, la fonction de connexion peut dépendre de la fonction d'authentification.
• Estimer les risques et les coûts : Un FRD peut également aider à estimer les risques et les coûts associés à un projet. En décrivant toutes les exigences, il est plus facile d'identifier les risques potentiels au cours du processus de développement. 
• Améliorer la communication : Un DRF peut également améliorer la communication entre les différentes parties prenantes. En fournissant une vue d'ensemble claire et concise du système, il est plus facile pour chacun de comprendre les exigences et les objectifs du projet. 
• Fournir une vue d'ensemble de chaque exigence : Le DRF doit fournir une vue d'ensemble de chaque exigence, aussi petite ou insignifiante qu'elle puisse paraître. Par exemple, l'obligation d'afficher un message d'erreur lorsqu'un utilisateur saisit un mot de passe non valide peut sembler insignifiante. Il s'agit néanmoins d'une exigence à inclure dans le DRF. 

Principales différences entre les DRB et les DRF

Maintenant que nous avons abordé les principes de base des BRD et des FRD, examinons plus en détail les principales différences entre ces deux types de documents. 

1. Champ d'application

La différence la plus importante entre un BRD et un FRD est leur portée. Un BRD est une vue d'ensemble de haut niveau de l'ensemble du projet. Il doit fournir une vue d'ensemble des objectifs, des exigences et du calendrier du projet. En revanche, un DRF est un document plus détaillé qui se concentre sur les exigences fonctionnelles du système.

Lorsque l'on examine la portée d'un projet, il est essentiel de garder à l'esprit l'objectif de chaque document. Le BRD doit fournir une vue d'ensemble du projet, tandis que le FRD doit donner une vision plus détaillée du système. Par exemple, le BRD peut indiquer que le projet doit "augmenter les ventes de 10%". Le DRF détaillera ensuite la manière dont le système doit atteindre cet objectif. 

2. Audience

L'audience d'un BRD est le sponsor du projet, la direction générale, ou d'autres décideurs critiques. Le BRD doit fournir suffisamment d'informations pour que ces parties prenantes puissent prendre des décisions éclairées sur le projet. 

Le public cible d'un FRD est généralement l'équipe de développement. Il doit fournir suffisamment d'informations pour que ces intervenants puissent comprendre les exigences du système et commencer à travailler sur le projet. Il fournit également au personnel chargé de l'assurance qualité les informations nécessaires pour créer des plans et des cas de test. 

3. Longueur

La longueur d'un BRD peut varier en fonction du projet. Par exemple, un petit projet peut ne nécessiter que quelques pages, tandis qu'un projet plus important peut exiger un document plus détaillé. En général, cependant, les DRB ont tendance à être plus courts que les DRF. 

Les FRD, quant à eux, sont généralement des documents plus longs. Ces documents fournissent une documentation détaillée des exigences du système. Par conséquent, ils ont tendance à être beaucoup plus longs que les BRD. Un DRF standard compte entre 10 et 100 pages, mais un projet plus important peut nécessiter un document plus long. 

4. Qui prépare le document ?

Les analystes commerciaux sont les seuls responsables de la création du BRD. Certaines organisations peuvent faire appel à des chefs de projet pour s'assurer que le document répond aux besoins du projet. 

Les analystes métier travaillent sous la supervision d'analystes système ou d'experts techniques pour préparer un FRD. Une équipe de mise en œuvre peut participer à l'élaboration d'un DRF. Toutefois, son implication se limite à fournir des informations sur les fonctionnalités du système. 

5. Flexibilité

Les BRD sont généralement plus flexibles que les FRD car ils traitent de concepts de haut niveau qui sont moins susceptibles de changer au fur et à mesure de l'avancement d'un projet. Les DRF, en revanche, sont plus rigides car ils décrivent souvent des détails techniques spécifiques qui doivent être suivis de près pour qu'un système fonctionne correctement. 

Quand utiliser le BRD et le FRD

Les documents BRD et FRD sont tous deux essentiels à tout projet. Une fois que vous avez le BRD, vous pouvez l'utiliser pour créer le FRD. Une fois le DRF terminé, vous pouvez l'utiliser pour élaborer les spécifications fonctionnelles du projet. 

Cependant, il peut arriver que vous deviez utiliser un document plutôt qu'un autre. Par exemple, si vous présentez le projet à la direction générale, vous devrez utiliser le BRD. En revanche, si vous travaillez avec l'équipe de développement, vous devrez utiliser le DRF. 

Vous trouverez ci-dessous un résumé du moment où il faut utiliser chaque document : 

Utilisez BRD lorsque : 

• Vous devez convaincre la direction d'approuver le projet. 
• Vous présentez le projet pour la première fois 
• Vous souhaitez fournir une vue d'ensemble des objectifs, des exigences et du calendrier du projet. 
• Lors de la définition des exigences du projet 
• Lors de la création d'un aperçu de haut niveau du projet 

Utilisez le FRD lorsque : 

• Vous souhaitez fournir des informations détaillées sur la fonctionnalité du projet 
• Vous travaillez avec des développeurs pour créer les spécifications fonctionnelles du système. 
• Vous devez vous assurer que tous les membres de l'équipe comprennent les exigences du système. 
• Lors de la définition des spécifications techniques détaillées du projet 
• Lorsqu'il s'agit de fournir des informations que les développeurs utiliseront pour créer des plans de test et des cas de test. 

Une organisation plus importante peut utiliser les deux documents du début à la fin. Dans ce cas, le BRD est utilisé pour obtenir l'approbation du projet. Une fois le projet approuvé, l'analyste métier crée le DRF. Une fois le DRF terminé, il est transmis à l'équipe de développement pour qu'elle élabore les spécifications fonctionnelles du système. 

Tous les projets ou entreprises n'ont pas besoin des deux documents. Par exemple, une petite entreprise ou un petit projet peu complexe peut n'avoir besoin que d'un BRD. Cependant, un projet ne peut pas fonctionner uniquement avec un DRF, car il s'agit d'un dérivé du BRD. 

FAQs

Conclusion

Le BRD et la FSD sont des documents essentiels pour tout projet. La principale différence entre les deux est que le BRD est un document de haut niveau qui décrit les objectifs de l'entreprise, tandis que le FRD est un document plus détaillé qui décrit les exigences fonctionnelles du projet.

Les deux documents sont préparés par l'analyste commercial et revus par les parties prenantes et les experts en la matière. 

Pour choisir le document à utiliser, il est essentiel de tenir compte de l'objectif du projet et des personnes qui utiliseront le document. Les petites entreprises peu complexes peuvent n'avoir besoin que d'un BRD, tandis que les grandes entreprises ou les projets plus importants peuvent avoir besoin des deux documents.