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
💥 1 livre papier acheté 
= la version en ligne automatiquement offerte. Cliquez ici
  1. Livres et vidéos
  2. Business Intelligence : le recueil des besoins
  3. Importance du recueil des besoins
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

Importance du recueil des besoins

Introduction

L’ingénierie des besoins est un domaine nécessaire à tous les développements logiciels. Elle l’est encore plus dans le cadre d’une l’implémentation d’une solution décisionnelle. Nous verrons dans quelle mesure l’exercice du recueil des besoins est important : les spécificités des projets décisionnels, leurs principaux écueils, les coûts induits et les risques, les mythes.

Définition du besoin

Commençons par notre domaine. Qu’est-ce qu’un besoin et quels sont les différents types de besoins ?

Dans ce livre, les termes "exigence" et "besoin" sont interchangeables. Ils correspondent à la traduction du terme anglais requirement. L’utilisation d’un mot ou de l’autre n’est là que pour répondre à des contraintes de lisibilité. Selon le consortium IEEE, un requirement est :

  • une condition ou une capacité nécessaire à un utilisateur pour résoudre un problème ou atteindre un objectif,

  • une condition ou une capacité nécessaire qui doit être atteinte ou réalisée par un système ou un composant d’un système pour remplir un contrat, un standard, une spécification ou tout autre document formel.

Les besoins peuvent émerger d’un utilisateur, d’un groupe d’utilisateurs, de contraintes techniques, légales, de standards de l’industrie…

Il existe plusieurs façons de classifier les besoins.

De l’importance du recueil des besoins

Pour pouvoir développer une solution décisionnelle et que celle-ci soit utilisée, il faut comprendre à quels besoins elle répond, comment la solution les supportera et comment ses fonctionnalités seront développées.

Le recueil des besoins : l’élicitation, la modélisation, la spécification, la priorisation, la gestion des dépendances, l’évaluation de l’impact, les négociations et le contrôle de la qualité des exigences sont autant de points importants pour le succès d’un projet et d’un produit.

Comprendre la question c’est détenir 50 % de la solution. En effet, il y a toujours de nombreuses routes pour arriver à des résultats semblables. Il va falloir en choisir une, et avant de s’engager, il est préférable de savoir quelle route emprunter. 

Quelques chiffres sur l’importance de l’ingénierie des besoins.

1. Du côté de la recherche de l’ingénierie des besoins

Certaines études ont montré que l’inadéquation entre les développements et les besoins, d’une part, et les changements de besoins (changement de scope), d’autre part, sont deux facteurs importants dans l’échec des projets (Timothy G. Olson - Successful Strategies to Improve Your Requirements...

Processus décisionnel

Le système décisionnel est souvent opposé aux systèmes opérationnels.

Le premier est là pour supporter un processus décisionnel. Il permettra d’accéder à des informations centralisées, homogénéisées, historisées. L’organisation des données est optimisée pour des requêtes de masse interrogeant un gros volume de données.

Les seconds ont pour vocation de supporter un processus métier. Ils sont optimisés pour permettre à l’utilisateur d’accéder à une ou un petit nombre d’informations en temps réel.  

La frontière est de plus en plus perméable entre les deux types de systèmes qui autrefois s’opposaient de manière plus évidente. C’est notamment le cas avec les systèmes d’analyse de risques bancaires et les systèmes d’assurance.

Cependant, une constante reste. Le système décisionnel est un support à la décision. Il implique donc que le process de décision soit défini même s’il est protéiforme. Il existe une grande variété de façons de prendre une décision : allant de l’automatisme total à l’intuition en passant par le processus collectif… 

En réalité...

Coûts et risques

On parle ici des risques liés à une mauvaise gestion des exigences : que l’on ne maîtrise pas bien le processus et les besoins ambigus ou que l’on fasse complètement l’impasse sur cette étape.

Plusieurs types de coûts sont possibles : les coûts et risques pour le projet, pour la solution livrée et pour les utilisateurs.

On parlera ici indifféremment des coûts ou des risques. Les coûts ne sont pas uniquement pécuniaires et les risques sont des coûts hypothétiques.

1. Les coûts pour le projet

Une recherche effectuée par Boehm et Papaccio (Understanding and controlling software cost : fixing error cost) montre que les coûts de la correction d’une erreur augmentent exponentiellement en fonction de la phase du projet.

L’explosion des coûts

Il sera de 1 USD lors d’une correction en phase de définition des besoins, le coût moyen passera à 5 USD en phase de design, 10 USD lors d’une correction pendant les développements, 20 USD pendant les tests et jusqu’à 200 USD pour une correction après la mise en production.

Cette étude, bien qu’un peu ancienne, a été mise à jour et il semble que le ratio reste stable, mais les coûts ont, eux, tendance à augmenter.

Les projets dont les délais sont serrés et les organisations poussant pour des livraisons rapides sont dans une zone à risque concernant des erreurs sur les recueils des besoins. En effet, poussant les équipes à livrer plus vite, on optera pour la solution la plus rapide et donc celle qui sera la moins fiable. Le recueil des besoins et les tests sont en général les premières étapes qui passent à la trappe. Ces pratiques font multiplier le nombre de bugs par quatre.

L’explosion des délais

L’adage dit : "si on n’a pas le temps de faire les choses...

Mythes

Les mythes sont ici les idées qui favorisent un statu quo et empêchent d’améliorer nos pratiques au quotidien. Loin de vouloir atteindre un idéal, se poser les bonnes questions permet déjà d’envisager des alternatives.

1. "Les utilisateurs changent d’avis"

Avec les variantes suivantes : "ils ne savent pas ce qu’ils veulent", "ils ne comprennent pas leur propre besoin"…

…Ou alors, le besoin exprimé n’est pas associé avec la stratégie métier des utilisateurs. Si vos besoins sont "flottants", ils ne sont pas ancrés et pas justifiés par un besoin métier, il est alors facile de les changer. Il sera beaucoup plus compliqué de changer une exigence si elle répond à une stratégie, une tactique et un processus opérationnel des parties prenantes fonctionnelles.

…Ou alors vos parties prenantes sont expertes dans leur domaine (marketing, finance…), mais pas en design de solution pour supporter leur quotidien. Lorsque Steve Jobs a lancé son iPhone, peu de futurs utilisateurs auraient été aptes à définir les fonctionnalités d’un smartphone. Elles étaient alors définies en prenant en compte une vision, une problématique des utilisateurs et les capacités d’innovation de l’entreprise. De la même façon, il est souvent difficile pour vos utilisateurs de décrire les caractéristiques de la future solution.

…Ou alors vos parties prenantes ont une réelle justification au changement. La stratégie change, le management change, le marché change, le processus métier change, donc le système décisionnel doit s’adapter. Lorsqu’on voit apparaître ce genre de changement, il est rare que les développeurs ou les analystes pensent que leurs parties prenantes font les girouettes.

Oui, les changements sont inévitables lors d’un projet, encore faut-il qu’ils soient signifiants pour la réalisation de l’objectif global défini.

2. "Ne pas livrer dans les délais : c’est normal"

Voici l’une de mes histoires préférées. L’histoire de Tchouri et Rosetta, une mission spéciale...