Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Business Intelligence : le recueil des besoins
  3. Quelles informations recueillir et quand ?
Extrait - Business Intelligence : le recueil des besoins La boîte à outils du business analyst
Extraits du livre
Business Intelligence : le recueil des besoins La boîte à outils du business analyst
1 avis
Revenir à la page d'achat du livre

Quelles informations recueillir et quand ?

Introduction

Assez parlé d’informatique ! Faisons une pause gastronomique ! Un projet décisionnel, sous certains aspects, se gère comme un restaurant. Cette analogie aide à expliquer la granularité nécessaire du besoin, mais aussi à quel moment recueillir quel besoin. Une fois bien comprise, elle facilite grandement la communication avec les parties prenantes non fonctionnelles.

Classification des besoins

Il existe plusieurs manières de catégoriser le besoin.

L’une des façons traditionnelles de classifier est l’opposition des besoins fonctionnels et des besoins non-fonctionnels.

Les premiers décrivent une fonctionnalité de la solution. Par exemple, la plateforme devra permettre de télécharger les rapports sur le disque de l’utilisateur.

Les seconds décrivent le "comment" ces fonctionnalités sont remplies ou les contraintes qui y sont associées. Par exemple, le téléchargement devra se faire dans un ".pdf" et devra être sécurisé.

Une classification qui est moins connue, mais capitale pour comprendre nombre de problèmes que peuvent rencontrer les projets, est celle développée par Edwards J, Coutts I, Mc Leod S (2000) : Support for system evolution through separating business and technology issues in a banking systems development. In : Proceedings of 2nd international symposium on requirements engineering, York, England, IEEE CS Press, p. 68-80. Elle se présente sous la forme d’une matrice décrivant les besoins de l’organisation, du produit et du projet à différents niveaux : stratégique, tactique et opérationnel.

Stratégie

Tactique

Opérationnel

Besoins organisationnels

Stratégie de l’organisation. Compétitivité....

Analogie du restaurant : les protagonistes

J’ai pu utiliser cette analogie durant de nombreuses années. Elle facilite la communication entre les parties prenantes fonctionnelles et non fonctionnelles.

Cette analogie apporte plusieurs avantages. Elle permet de bien comprendre le besoin nécessaire pour chaque étape du projet. Ensuite, elle permet d’expliquer les délais et les durées nécessaires pour réaliser le travail de back-end. Il est en effet parfois difficile de justifier le travail sous-jacent. Cette méthode permettra aux parties prenantes fonctionnelles de conceptualiser le travail à effectuer.

Avec un peu de pratique, j’ai vu des utilisateurs venant à mon bureau : "j’ai besoin des chiffres de ventes de ce produit. Où sont les données ? Dans le frigo ? Dans le champ ? Sur l’étagère du self ?" Ma réponse : "dans le champ, elles ne sont pas encore plantées". Cela lui donne rapidement une idée de la faisabilité de son projet pour demain matin, et des raisons pour lesquelles cela n’est pas envisageable.

1. Les aliments ou la donnée

"Les produits... il faut d’abord les étudier pour les comprendre au naturel, en saisir l’essence, en déchiffrer toutes les subtilités. Ensuite, il faut les comparer entre eux, afin de découvrir les affinités d’où naîtront les chefs-d’oeuvre de la cuisine" - Joël Robuchon

Comme les légumes et les fruits, la donnée...

Analogie du restaurant : le processus et le timing

Nos protagonistes sont identifiés, nous allons maintenant nous intéresser au timing du projet. Il devient alors plus facile d’identifier si la charge de travail se mesure en minutes, heures, jours, mois ou même peut être années. Cela aidera aussi à comprendre quelles sont les équipes techniques qui doivent être réunies autour de la table.

1. Quelques mois avant…

Quelques mois ou années avant que les données ne soient consommées, il faut bâtir les historiques de données. Si ce n’est pas fait en amont, il est très coûteux, voire impossible, de recréer des historiques. Les données, comme les légumes pour être bio et de bonne qualité, ont besoin de temps.

Il arrive souvent que les développeurs doivent recréer un historique à partir de traces, de données partielles… avec des résultats d’une qualité discutable. Haaa… les pesticides ! Personne ne veut recréer cinq ans d’historique à partir des logs des bases de données opérationnelles. Ceux-ci étant récupérés grâce aux sauvegardes quotidiennes du serveur…. La joie des projets légaux !

Il est important donc de ne pas attendre que le chef soit en cuisine pour planter...

Analogie du restaurant : la granularité

Nous avons les protagonistes et les tâches à effectuer pour délivrer la solution. Nous avons défini quand ils doivent commencer et expliqué les raisons. Mais comment anticiper le besoin ? C’est une histoire de granularité.

1. Stratégique

Pour planter ses légumes et les conditionner, le fermier aura besoin de connaître la stratégie du restaurant : est-ce que le restaurant est végan, bio, qu’il est spécialisé dans un produit particulier, combien de couverts et de quantités estimées ?

Le fermier n’a pas besoin de savoir dans quel plat va finir la carotte qu’il a plantée mardi, encore moins de savoir quelle bouche la mangera. Il paraîtrait tout à fait étrange d’avoir un panneau : "la carotte de Paul pour le repas de Noël de l’année prochaine" planté à côté de la graine.

De même, pour bâtir un historique il n’est pas nécessaire d’avoir la liste des tables du modèle de données qu’il utilisera, il n’est pas non plus nécessaire de savoir dans quelle visualisation cet historique finira.

Alors avec quoi bâtir un historique ? L’historique est bâti à partir d’une source de données. Est-ce que cette source...