L’analyse des besoins

(temps de lecture moyen : 2 min)

Pourquoi faire une analyse des besoins?
L’analyse de l’activité de l’entreprise
L’analyse des besoins des Acteurs
L’analyse des besoins : développer une vision

Pourquoi faire une analyse des besoins?

En tant que Business Analyst, votre objectif est de définir et de communiquer aux autres intervenants les fonctionnalités et/ou processus cibles.

Vos tâches de haut niveau sont donc :

• Comprendre les besoins des utilisateurs finaux;
• Comprendre les besoins du  client (la partie prenante qui finance le projet) ;
• Documenter, hiérarchiser et partager les exigences de la solution;
• Négocier les exigences et faciliter la conduite du changement.

Les deux premières tâches sont décrites dans cette section, et sont un prérequis à la description de la solution cible.

L’analyse de l’activité de l’entreprise

Selon l’impact des nouveaux logiciels sur l’Organisation, l’analyse des besoins peut parfois demander un effort conséquent de réingénierie à l’échelle du département ou de l’Organisation elle-même.

Par conséquent, celle-ci commence par la compréhension de l’activité de l’entreprise. C’est là que le Business Analyst devra faire appel à ses compétences de :

• modélisation métier (composante de l’analyse des besoins) ;
• traduction des modèles métier en exigences logicielles.

Diverses techniques peuvent être employées, cependant la plus usuelle (car la plus claire) est celle des cas d’utilisation. Ceux-ci permettent de mettre en valeur les processus métier mis à disposition des différents partenaires ou clients (les acteurs métier externes). Ils conduisent aussi à identifier les applications requises pour supporter ces processus métier.

Les rôles et les livrables des processus peuvent également être représentés par des classes et des objets dans modèle objet métier.

L’analyse des besoins métiers et des exigences techniques

Une fois l’activité bien appréhendée, l’analyste doit identifier les fonctionnalités de haut niveau du système. Notez qu’il est souvent nécessaire d’orienter la liste de souhaits initiale, sinon vous risquez de faire face à une liste au Père Noël sans grande cohérence ! 

Vous pouvez, par exemple, posez des questions du type :

• Quels sont les problèmes que vous rencontrez dans le système actuel ? (= résultats de l’analyse de l’existant),
• Quelles sont les tâches auxquelles vous consacrez le plus de temps ?
• Ou encore : quelles sont les tâches quotidiennes qui pourraient être automatisées ?

En documentant les besoins, assignez-leur une priorité, une criticité et indiquez-en l’initiateur.

Différenciez bien les besoins des acteurs externes (clients, fournisseurs…), et internes (départements / services de l’Organisation), qu’ils soient physiques ou systèmes (autres applications ou systèmes d’information connectés).

Pour regrouper les besoins de manière cohérente et consensuelle, le Business Analyst s’attache à identifier une vision commune.

L’analyse des besoins : développer une vision

Une vision définit le point de vue des intervenants quant au produit à développer. Ce point de vue sera décrit en termes de spécifications fonctionnelles et non fonctionnelles. La vision ainsi décrite servira ensuite de base à la définition des exigences fonctionnelles et non fonctionnelles détaillées, puis à la conception technique et au développement informatique de la solution cible.

Voici les éléments les plus importants qui la composent :

• la liste des contributeurs (SME – Subject Matter Experts)
• la liste des contraintes de fonctionnement de la solution: c’est ce qu’on appelle les exigences non fonctionnelles. Il peut s’agir d’impératifs financiers, de choix technologiques, de compatibilité avec l’infrastructure existante etc…
• l’énoncé du problème à résoudre
• la liste des fonctionnalités de haut niveau

A la fin de l’analyse des besoins, il est recommandé de mettre à jour un glossaire. En effet, l’ennemi public numéro 1 pour un Business Analyst – et a fortiori un risque majeur pour le projet – est l’ambiguïté. Mieux vaut éviter de démarrer le projet sur la base d’une vision faussée par le mauvais usage de la terminologie !

Les livrables qui formalisent cette activité sont, entre autres :

• la description des processus existants.
• les règles métier
• les cas d’utilisation
• Le Business Requirements Document (BRD)