Dans la continuité du billet précédent et de la comparaison des méthodes classiques et agiles, nous allons décrire la phase de recueil des besoins pour un projet avec une gestion dite traditionnelle.

Tout projet commence par le recueil des besoins du client. Cette étape, est indispensable et très importante car une mauvaise définition des besoins aurait un impact sur la satisfaction finale du client.

 
Le modèle classique propose que ce recueil soit fait en deux parties :

• L’identification des besoins
• La définition des exigences

Identification des besoins:

Le besoin est généralement apparenté à un souhait de l’utilisateur. A cet instant aucune notion technique n’est abordée. On peut prendre comme exemple un des projets de CLT où le client voulait avoir la possibilité de lister les demandes d’un chargé d’affaires. Au-delà d’une simple description, le besoin peut également décrire la manière dont la fonctionnalité sera utilisée, mais aussi son ergonomie….
Afin d’être formalisés et validés, l’utilisateur devra indiquer l’intégralité de ses besoins.

Comme vous l’aurez compris cette tâche est très consommatrice en temps entre la clarification pour certains, l’ajout de nouveaux ou la suppression due à des erreurs. Ce recueil est réalisé d’après la connaissance actuelle du produit désiré par l’utilisateur, dans un contexte donné.
Pour procéder à ce listing, l’équipe a à sa disposition plusieurs moyens.
Dans un premier temps il sera demandé à l’utilisateur de les exprimer.
Ensuite dans le cas où il y aurait des doutes, plusieurs solutions sont disponibles :

• le brainstorming, qui consiste à faire de petites réunions au cours desquelles les différentes personnes impliquées vont discuter, affiner, ajouter ou supprimer des besoins. Elles peuvent aussi travailler sur un thème regroupant un ensemble précis de besoins. Pendant ce type de réunions aucune censure ne doit être faite quant aux idées. On retiendra celles qui au final sont nécessaires.
  
• des analyses concurrentielles, des analyses de produits déjà existants sur le marché.  Une fois l’identification terminée, on aura déterminé le périmètre fonctionnel pour la conduite du projet.

Définition des exigences:

Par définition des exigences, on entend formalisation. Cette étape va
nous permettre de vérifier notamment la cohérence entre les différents besoins qui viennent d’être récupérés. Ils seront transformés pour que les équipes plus techniques puissent les comprendre. La plupart du temps cette formalisation se fait sur un support papier, un cahier des charges qui a la caractéristique d’être assez volumineux. On peut également les trouver sous forme de cas d’utilisation (langage UML) ou autres.
C’est à partir de ces documents que la validation finale des besoins va se faire.
La notion d’exigence est définie par le CMMI. Le CMMI est un ensemble de bonnes pratiques du développement logiciel, et un référentiel d’évaluation de la capacité à gérer et terminer un projet. Elle est prioritaire car c’est sur elle que va reposer en majorité la phase de planification. On y consacre donc temps et ressources nécessaires.
D’après ce modèle la définition des exigences correspond au niveau 2 sur 5 à savoir : Gérer les exigences des produits et des composants produit du projet et identifier les incohérences entre ces exigences et les plans produis intermédiaires du projet

Suite dans le prochain billet, où l’on parlera de la planification.