La description de la solution cible

description de la solution cible

 

(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 description de la solution cible est sans doute la plus connue de celles réalisées par le Business Analyst. Et pour cause : ses livrablesles spécifications fonctionnelles générales et détaillées – 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 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.

Comment décrire la solution cible ?

La description de la solution cible regroupe les activités suivantes :

  • Structurer et organiser les besoins métier découverts lors des étapes précédentes.
  • Spécifier, modéliser, contrôler et valider les exigences métier.
  • Identifier les différentes alternatives pour atteindre le périmètre métier ciblé.
  • Estimer la valeur ajoutée de chacune de ces alternatives.

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

Quelle que soit la méthodologie 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 spécifications fonctionnelles 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 l’analyse dépend de l’objectif visé.

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.

Poster un Commentaire

avatar
  S’abonner  
Notifier de