La conception fonctionnelle

(temps de lecture moyen: 1 m 30 s)

Comment décrire la solution cible ?
Décrire la solution cible : une démarche incrémentale et itérative

La conception fonctionnelle de la solution cible est sans doute l’une des activités la plus connue parmi celles réalisées par le Business Analyst. Et pour cause : ses livrables – les spécifications fonctionnelles générales et détaillées, en gestion de projet traditionnelle, et le Product Backlog et les User Stories dans les contextes agiles – constituent une contribution majeure aux activités des autres intervenants du projet :

• L’architecte : pour bâtir l’architecture de la solution cible ;
• Le développeur : pour créer ses algorithmes et le programme informatique ;
• Le chef de projet : pour répartir la charge de travail dans la suite du cycle de vie du projet ;
• Le testeur : pour construire ses scenarios et cas de test ;
• Le formateur : pour préparer ses documents de formation / guides utilisateur;
• Et bien sûr le client, pour valider que la solution cible est conforme à ses besoins et à ses règles métier.

Qu’est-ce que la conception fonctionnelle?

La description de la solution cible est l’objectif de la conception fonctionnelle, et elle regroupe les activités suivantes :

• Structurer et organiser les besoins et processus métier.
• Identifier, prioriser, modéliser, contrôler et valider les exigences de la solution (exigences fonctionnelles, non fonctionnelles et de transition).
• Identifier les différentes alternatives pour atteindre le périmètre métier ciblé.
• Estimer la valeur ajoutée de chacune de ces alternatives pour les utilisateurs et le client final (le payeur).

La conception fonctionnelle: une activité  incrémentale et itérative

Quelle que soit la méthode choisie (voir Techniques et Méthodes), le Business Analyst travaille de manière incrémentale et itérative.

En d’autres termes, la rédaction des livrables de la conception fonctionnelle de la solution cible se fait petit à petit, depuis l’ébauche de la solution jusqu’à sa description précise, claire et non ambiguë.

La profondeur de la description dépend de l’objectif visé, de la méthode et de l’organisation projet.

Par exemple, dans le cas des spécifications fonctionnelles générales, le Business Analyst répertorie de manière macroscopique les cas d’utilisation. Il peut ainsi identifier, dans une vue Système, les fonctionnalités de haut niveau.

Globalement, la démarche est la suivante :

• Au début du processus, le Business Analyst demande au Client de lister toutes ses attentes de la future solution.
• Il se retrouve ainsi avec une « liste au Père Noël » de fonctionnalités de haut niveau. Celles-ci sont triées selon leur criticité et leur degré d’urgence.
• Le Client est amené à faire un choix en fonction de critères dépendant du contexte projet.
• Sur la base de la sélection de ces fonctionnalités de haut niveau, le Business Analyst décrit ensuite le fonctionnement des sous-fonctions.
• Celles-ci sont parfois directement liées à l’outil choisi, que le Business Analyst doit donc connaître pour savoir définir son paramétrage. Il s’agit notamment de solutions de Business Intelligence, d’ERP, de PLM ou encore de CRM.

L’affinement itératif de la description se fait en relation étroite avec le Client, afin de s’assurer de la conformité aux règles et besoins métier.