Parfois, vos parties prenantes vont vous prendre pour le Père Noël et vont vous soumettre un besoin, qui n'en est finalement pas un.
Alors, vous allez vous lancer dans une analyse détaillée de ce besoin. Votre demandeur va détailler un peu plus son besoin. souvent en parlant déjà d'une solution.J'ai besoin d'une nouvelle moto pour aller bosser.
Je voudrais une Ducati Hypermotard SP
Puis, vous allez interviewer les différentes parties prenantes :
En tant que marketeux, je pense que vous devriez rouler en BMW R 1200 RT.
En tant qu'assureur je pense que le plus raisonnable serait une Honda CB 500 X.
En tant que banquier je pense que vous n'avez pas le budget.
En tant que Sécurité Routière, je pense que c'est trop risqué de rouler en 2 roues.
En tant qu'expert, je pense que ça tombe bien, c'est le salon de la moto, allons essayer une présélection de modèles puis on fera une analyse comparative.
...
Alors là, je dis STOP. On est allé trop vite. Avant de détailler, modéliser, valider ces exigences, il faut avoir vérifier que le besoin était bien compris. Dans le Business Analysis Body of Knowledge, on parle de "elicitation". Ce terme a été traduit dans la version en français par "élicitation" et est défini comme suit :
L’élicitation peut se définir de la manière suivante : se renseigner pour connaitre divers éléments (latents ou potentiels), poser des questions, s’informer pour obtenir de l’information ou des réponses.
Les techniques à utiliser pour cette phase critique de la gestion des exigences sont : brainstorming, étude de la documentation existante, groupes de discussion, interviews, storyboards, sondage/questionnaire... Des techniques assez ouvertes qui facilitent la découverte.
Dans mon exemple, le vrai besoin de cette partie prenante est de se rendre au boulot en moins d'une heure. Et comme la batterie de sa moto actuelle est faible, elle ne démarre pas. Finalement il suffira juste de recharger la batterie de sa Honda Hornet, et ça roule.
Le Système d'Information, c'est pareil.
!
