La gestion des exigences, clé de voûte du succès d’un projet

Les similitudes apparentes entre un projet et un autre peuvent être trompeuses. Les conséquences de la réutilisation des mêmes données pour satisfaire les exigences d’un client peuvent alors conduire à des résultats inappropriés  pour le client.
Ceci était l’une des leçons retenues d’un projet de déploiement chez une filiale d’un client opérateur de téléphonie en Amérique Latine.
En effet, ce projet, ne présentant pas de difficultés particulières, était le 4ème déploiement d’une même solution. Il semblait alors pertinent et évident de réutiliser, en l’adaptant, la même base d’exigences que les projets précédents.

Cependant, en préparation de la phase de la recette client, étape critique pour la réussite du projet  le chef de projet brésilien avait refusé de valider le cahier de recette soumis par l’équipe projet pour approbation.
En effet, la liste des exigences fonctionnelles spécifiques à sa filiale n’avait pas été couverte en termes de tests. Aucune traçabilité entre les exigences fonctionnelles et techniques n’était retranscrite dans le cahier de recette.

Il était alors évident que l’équipe projet avait omis de détourer de manière formelle et précise toutes les exigences spécifiques à ce client.
Nous allons voir au travers de cet article que la gestion des exigences est définitivement l’une des clés de voute du succès d’un projet.

Approche théorique de la notion d’exigence client

Le PMBOK®  définit l’exigence (« requirement » en anglais) comme « la condition ou capacité qu’un système, un produit, un service, un résultat ou un composant doit satisfaire ou présenter pour être conforme à un contrat, une norme, une spécification ou tout autre document imposé formellement. Les exigences comprennent les besoins, les demandes et les attentes, quantifiés et documentés, que le commanditaire, le client et d’autres parties prenantes font valoir ». Le CMMI®  ajoute l’expression  d’un besoin utilisateur à prendre en compte pour résoudre un problème ou atteindre un objectif, sans que celui-ci (le besoin) soit formellement explicite. Le besoin peut provenir de toute partie prenante : utilisateur, client, entreprise… (cf. ICB® et Prince2®), et de l’analyse des risques et opportunités relatifs au projet, ou à un cas d’utilisation spécifique (exemple : conditions d’utilisation d’un matériel sur mer => exigence de tenue au  brouillard salin, exemple : puissance émise plus forte que le besoin intrinsèque du produit pour permettre l’alimentation d’un matériel redondant ou annexe,…). Tous les besoins doivent être déclinés en exigences Spécifiques, Mesurables, Atteignables, Réalistes et planifiables dans le Temps (méthode SMART).

Différents types d’exigences sont considérés : techniques, non-techniques, fonctionnelles et non-fonctionnelles. Les exigences techniques sont directement liées au produit, service ou résultat attendu (Puissance, Consommation, Masse, Volume, etc…) et sont généralement tracées dans un document de « spécifications techniques ». Les exigences non-techniques portent sur les contraintes de coûts, de planning, mais aussi toutes les dispositions imposées par le contexte du client ou de l’utilisateur final (exemples : clés de paiement en fonction de la Valeur Acquise (« Earned Value »), la périodicité du « Reporting » client, la langue de rédaction des documents, nombre d’exemplaires à fournir, etc …)

Les exigences fonctionnelles concernent les performances du produit ou du service tandis que les exigences non-fonctionnelles sont plutôt liées à l’ergonomie,  la sécurité, fiabilité, disponibilité et maintenabilité du produit ou du service. Ces dernières auront un intérêt majeur dans le coût de possession du produit ou du service, et peuvent devenir prioritaires selon les objectifs, la stratégie du client.

Les sources des exigences sont diverses, celles provenant du client peuvent parfois nécessiter une mise au point explicite pour en préciser le contenu et la couverture; d’où les activités de Développement des Exigences (« Requirements Development ») préconisées par le CMMI®. On identifiera aussi les exigences d’interfaces entre les différents composants constituant le produit ou le service.

Il y a bien sûr celles provenant de l’interne (règles de gouvernance, stratégie de développement, politique produit, etc…)  celles provenant  des fournisseurs (mise à disposition de moyens matériels, logiciels, logistique, etc…), et encore celles provenant des règlements ou lois diverses (normes environnementales, législations locales, droit du travail etc…).

Figure1 : le Développement des exigences

La définition des exigences doit être menée en même temps que la stratégie de validation associée, afin d’assurer la capacité à valider chacune des exigences.

L’atteinte des objectifs d’un projet est intimement liée à la gestion des exigences, depuis leur définition jusqu’à leur démonstration auprès du client (parties prenantes externes ou internes). Il faut entendre par « gestion des exigences », l’analyse, la documentation et le suivi de chaque exigence, de manière à s’assurer de la conformité du produit / service avec les besoins exprimés par le client. Cette gestion doit permettre la traçabilité entre les exigences d’entrée et  les critères d’acceptation du client quelle que soit la méthode de validation utilisée (Inspection, Analyse, Démonstration, Test – IADT). La traçabilité consiste aussi à identifier les interfaces entre les différentes exigences. La gestion des exigences sera menée tout au long du cycle de vie du produit/service, de préférence, de manière parallèle avec l’activité de développement des exigences, et celle de la construction de la solution technique (produit, service) afin d’intégrer au plus tôt toutes évolutions du projet. Elle est outillée par plusieurs logiciels informatiques disponibles dans le commerce
Une fois identifiées, les exigences doivent être déclinées à chaque composant du produit ou du service, qui doit confirmer son engagement formel. Pendant l’exécution du projet, si une exigence n’est pas tenue (non atteignable, trop chère,…), la traçabilité bidirectionnelle nous permettra de remonter au plus vite aux performances impactées.

Figure2 : cycle de vie des  exigences

Quand toutes les conditions de vérification (conformité à la spécification) et de validation (conformité aux besoins fonctionnels de l’utilisation finale) sont réunies, on présente le produit/service en acceptation client.

Dans la prochaine partie de cet article, nous allons voir aux travers d’exemples de vécus projets, deux illustrations de gestion d’exigences pour deux typologies de projets respectivement représentatifs d’une approche dite « monolithique » et d’une approche davantage personnalisée.