Comment organiser les exigences en tant qu'analyste commercial

Un cahier des charges fonctionnel est un document formel qui recense les besoins des parties prenantes d'un projet ou d'un produit. Il n'existe pas de format standard unique pour la présentation des cahiers des charges fonctionnels, mais chaque version doit décrire le produit ou le projet avec suffisamment de détails pour permettre la discussion, l'analyse, la documentation et la validation.

Une exigence métier peut être présentée de l’une des manières suivantes :

• Un tableau ou une feuille de calcul
• Un diagramme (workflow)
• Un graphique
• Un modèle (schéma entité-relation)
• Un prototype ou une simulation
• Une phrase structurée ou un modèle de texte

Comment organiser et présenter une exigence commerciale

Vous trouverez ci-dessous les étapes pour rédiger et organiser les exigences sous forme de… Business Analyst.

Étape 1) Catégoriser les exigences.

• Classez chaque exigence dans la catégorie à laquelle elle appartient.
• Les parties prenantes techniques devraient voir une catégorie d'exigences techniques, et les parties prenantes non techniques devraient voir une catégorie d'exigences commerciales ou génériques.
• Chaque organisation devrait décider quelles catégories correspondent à ses propres normes.
• La catégorisation peut également se baser sur le type d'exigence — fonctionnelle ou métier — bien que cette distinction ne convienne pas à tous les projets.

Étape 2) Organiser les exigences.
Rassemblez et organisez les exigences dans un ordre logique afin que les parties prenantes puissent facilement naviguer dans le document et repérer les éléments manquants.

Étape 3) Préparez une liste.
Établissez une liste de révision des exigences, regroupées par parties prenantes devant les approuver.

Par exemple, un intervenant issu d'un milieu technique ne s'intéressera qu'à l'aspect technique du produit.

Étape 4) Utilisez des identifiants uniques.
If tracIl est difficile de faire correspondre les exigences entre elles ; utilisez des identifiants uniques pour faciliter leur communication. traccapacité plus facile.

Étape 5) Présenter les exigences selon la méthode préférée de la partie prenante.
Il se peut que vous deviez présenter la même exigence sous différents formats selon les parties prenantes : l’une préfère une représentation graphique, tandis que l’autre préfère des phrases structurées.

Étape 6) Préparez une table des matières.
Créez une table des matières reprenant toutes les exigences. Cela aidera les parties prenantes. track et les localiser rapidement.

Étape 7) Utiliser les outils d'analyse commerciale.
Utilisez le Outils d'analyse commerciale qui permettent de présenter et de catégoriser les exigences de manière cohérente d'une version à l'autre.

Étape 8) Organisez les documents d’exigences par flux de processus.
Supprimez les exigences inutiles du document et organisez celles qui restent en fonction du flux de processus qu'elles soutiennent.

Étape 9) Cartographiez les exigences.
Associez chaque exigence recueillie à une étape spécifique du flux de processus afin que les réviseurs puissent relier l'exigence au flux de travail qu'elle prend en charge.

Étape 10) Utilisez un tableau et des puces.
Utilisez des tableaux pour présenter les exigences complexes et des listes à puces pour mettre en évidence les aspects clés de chacune d'elles.

Conseils utiles pour la rédaction et la présentation d'un document de spécifications fonctionnelles

Pour une meilleure présentation et tracEn matière d'exigences commerciales, les conseils suivants sont utiles à tout analyste d'affaires (BA).

• La catégorisation des exigences est chronophage ; il est donc conseillé de définir un ensemble standard de catégories que les analystes fonctionnels, les parties prenantes, les experts du domaine et les équipes techniques pourront réutiliser d'un projet à l'autre au lieu d'en inventer de nouvelles à chaque fois.
• Élaborez chaque exigence en tenant compte de son public cible. Identifiez les acteurs clés, les personnes influentes et les décideurs (parties prenantes, personnel technique, développeurs, etc.).
• Définissez une exigence à la fois. Chaque exigence doit être atomique.
• Évitez toute ambiguïté — n’utilisez pas de qualificatifs vagues tels que « etc. » ou « environ » dans un énoncé d’exigence.
• Ne faites pas référence à une exigence qui n'a pas encore été définie.
• Supprimez les énoncés redondants et contradictoires du document.
• Décomposer les exigences complexes en points plus petits, gérables et vérifiables.
• Décrire est ce que nous faisons le système fera l'affaire, pas how Cela fonctionnera — la mise en œuvre relève de la phase de conception.

Techniques populaires pour visualiser les besoins métier

Un texte indigeste est le meilleur moyen de perdre un interlocuteur. Les analystes d'affaires associent systématiquement chaque exigence textuelle à un visuel afin que l'intention soit claire en un coup d'œil. Les techniques suivantes sont décrites dans le Guide BABOK et utilisées dans la plupart des pratiques d'analyse d'affaires en entreprise.

• Modèle et notation des processus métier (BPMN) : BPMN représente graphiquement les processus métier de bout en bout à l'aide de pools, de couloirs, de passerelles et d'événements. Ce langage est idéal pour indiquer qui fait quoi et quand.
• Diagrammes de cas d'utilisation et Descriptions : Capturez les interactions entre les acteurs et le système, ainsi que les résultats attendus par chaque acteur. Idéal pour les backlogs axés sur les fonctionnalités.
• Histoires d'utilisateurs avec critères d'acceptation : Des énoncés courts du type « En tant que… je souhaite… afin que… » associés à des critères « Étant donné-Quand-Alors ». Le format par défaut dans les équipes agiles.
• Maquettes et wireframes : Écrans de fidélité faible ou moyenne produits en Figma, Balsamiq, ou Axure qui rendent les exigences en matière d'interface utilisateur concrètes pour les parties prenantes non techniques.
• Diagrammes entité-relation (ERD) : Afficher les entités de données que la solution doit stocker et les relations entre elles — un élément essentiel pour les exigences de reporting et d'intégration.
• Diagrammes de flux de données (DFD) : Tracet la manière dont les données circulent à travers les processus, les entrepôts et les acteurs externes, notamment dans les projets d'analyse ou d'intégration.

Adaptez la technique au public : les cadres supérieurs réagissent aux cartographies de processus et aux diagrammes de parcours utilisateur, les développeurs aux diagrammes ER et aux récits utilisateurs, et les utilisateurs finaux aux maquettes fonctionnelles et aux prototypes.

Outils courants pour l'organisation des documents d'exigences métier

Dès que le nombre d'exigences dépasse une vingtaine, un document Word devient inadapté. Les analystes métier se tournent alors vers des outils dédiés qui prennent en charge la définition des exigences de base, la révision, traccapacité et contrôle des changements. Voici les méthodes les plus couramment utilisées dans l'industrie.

• Jira avec Confluence : La combinaison par défaut pour les équipes agiles. Les exigences sont consignées sous forme d'épopées et de récits dans Jira, soutenues par des pages Confluence qui contiennent le descriptif et les diagrammes du BRD.
• Jama Connect : Plateforme d'entreprise axée sur la gestion des exigences, l'établissement de références et la mise en production traccapacité pour les industries réglementées telles que les dispositifs médicaux et l'aérospatiale.
• IBM Engineering Requirements PORTES DE DIRECTION : Outil éprouvé utilisé depuis longtemps dans les secteurs de la défense, de l'automobile et des systèmes critiques pour la sécurité, où chaque exigence doit être respectée. traccapable.
• Modern Requirements pour Azure DevOps : Étend Azure DevOps avec révision, validation, définition des bases de référence et exportation des BRD au format Word directement à partir des éléments de travail.
• Miro or Lucidchart: Des outils de tableau blanc et de diagramme ont été utilisés pour rédiger les diagrammes BPMN, les diagrammes ERD, les parcours utilisateurs et les notes d'atelier qui alimentent ensuite le document BRD formel.
• Balsamiq et Figma: Outils de wireframe et de prototypage permettant de visualiser les exigences d'interface utilisateur plutôt que de les consigner textuellement.

Choisissez les outils adaptés à l'envergure du projet et à ses besoins d'audit. Les petits projets peuvent commencer avec Confluence et Jira, tandis que les programmes réglementés nécessitent généralement Jama ou DOORS. tracAudits de compétences.

Erreurs courantes lors de la présentation des besoins de l'entreprise

Même une exigence bien documentée peut être rejetée si elle est mal présentée. Les erreurs suivantes reviennent fréquemment dans les analyses post-mortem d'analyses fonctionnelles et il convient de les éviter lors de la révision.

• Mélanger quoi et comment : Culotte ping L'intégration de détails d'implémentation dans l'énoncé des exigences enferme l'équipe de conception dans une solution avant même que l'analyse ne soit terminée.
• Formulation ambiguë : Des termes comme « rapide », « convivial » ou « flexible » ne sont pas testables. Remplacez-les par des critères d'acceptation mesurables.
• Un seul format pour chaque partie prenante : Présenter le même point de vue aux dirigeants, aux développeurs et aux utilisateurs finaux ne satisfait généralement personne. Adaptez le format à votre public.
• Manquant traccapacité : Les exigences qui ne sont pas liées aux objectifs commerciaux, aux éléments de conception et aux cas de test ne peuvent être défendues lorsqu'une demande de modification arrive.
• Aucune priorisation : Présenter des centaines d'exigences sans MoSCoW, sans système de notation pondérée ni sans cadre similaire oblige les parties prenantes à débattre de la portée plutôt que de la valeur.
• Documents surchargés : Entasser tous les diagrammes, journaux et justifications dans un seul PDF de 200 pages masque les exigences importantes. Divisez le cahier des charges fonctionnel en sections logiques avec une table des matières claire.
• Skipping Se déconnecter: Présenter le document BRD sans étape d'approbation formelle ouvre la porte à des dérives du périmètre et à des accusations mutuelles plus tard dans la réalisation.

RevLe fait de comparer le BRD à cette liste avant chaque réunion des parties prenantes permet de déceler la plupart des problèmes qui entraînent des reprises lors des phases ultérieures.

FAQ