Spécifications, Exigences et Cahier des charges : Qui, Quand ?

Plus j’interviens dans les projets de développement informatique (Logiciel, Application Web, Sites Internet, INTRANET, EXTRANET …), plus je m’aperçois du caractère essentiel mais complexe, de trois activités, qui bien menées, désormais dans une dynamique agile, maximisent pourtant les chances de réussite des projets:

  • Recueillir et exprimer le besoin (Expression des besoins, Cahier des Charges, Vision …)
  • Spécifier le besoin (Dossier de spécification, SRS, Use cases, User stories …)
  • Gèrer et tracer les exigences (Backlog de produit, Liste des exigences, manuelle à base d’attributs ou sur des outils dédiés)

Évidemment, l’intensité, la répartition de ces activités va varier selon la taille et la nature du projet (Applications mètier, Sites Internet…), selon le contexte (Projet interne, R&D, Client, Appel d’offres), mais toutes trois se doivent d’être présentes et définies sur vos projets de conception…. D’ailleurs, dans un prochain billet, je détaillerai davantage le Quoi, et vous proposerai une réflexion sur le Comment.

Sans détours et sans vous rappeler les rapports CHAOS du Standish Group, je vous affirmerai pourtant que:

  • La capture est souvent incomplète, biaisée, mal maîtrisée.
  • La spécification souvent confuse, inadéquate, incorrecte, incompréhensible pour ses destinataires.
  • La gestion des exigences faite dans l’urgence voire absente, et de toute façon sous estimée.

Sans détours, j’ajouterai même que le recueil, la spécification et la gestion du besoin, nécessitent au final une véritable expertise, la maîtrise de diverses techniques souvent complémentaires (issues des Sciences Humaines), et pas mal de rigueur
bref, moins de blabla, moins d’artisanat, plus de professionnalisme et de méthode.

QUI
Vaste débat… et potentiellement pas mal de dérives…

Dans un contexte agile, on parlerait de Product Owner. Plus largement, l’Analyste, le Consultant, le Client sont des acteurs récurrents … mais aussi l’Ergonome qui de par son savoir-faire, ses objectifs et sa démarche centrée utilisateur doit en effet être un acteur privilègié du recueil et de l’analyse du besoin. Souvenez-vous , un produit « ergonomique » est un produit utile (issu d’un besoin EXPRIME ou NON) et utilisable : la présence de l’ergonome à ce stade est donc plus que légitime.

QUAND
L’expression des besoins et autres Cahiers des charges (suffisamment ouverts) sont quant à eux le fruit de l’activité de recueil, et servent souvent de déclencheurs pour la suite des opérations en mode agile, itératif ou séquentiel.

Dans une perspective séquentielle (cascade ou V: le pire), l’enchaînement est simple et bien connu. Les disciplines d’ingenierie (Spécification, Conception, Developpement, Intégration, Test) vont se dérouler dans un ordre trés précis avec la nécessaire validation de l’étape précédente pour passer à la suivante.
Les écueils de cette démarche sont nombreux : feedbacks et retours en arrière non prévus, corrections difficiles, pas de pilotage par les risques, manque de visibilité… Dans ce cadre, la gestion des exigences sera au mieux menée de manière transversale, servant de fil rouge à l’ensemble des acteurs et au projet; toutefois la plupart du temps la gestion des exigences ne sera pas envisagée ou sera traitée dans l’urgence.

Non ce qui marche, c’est l’AGILITE avec une bonne dose d’analyse, de test et d’expérience utilisateur.

Dans une perspective agile donc (l’idéal)

… de type SCRUM, méthode Agile la plus populaire, le degré de formalisme sera diffèrent; le tout intégré à chaque Sprint. Un effort particulier sera fait dans le cadrage projet (équivalent d’un Sprint 0), l’ingenierie des exigences se jouera principalement au travers du Backlog de produit  & User Stories dans une dynamique plus collaborative, toute aussi disciplinée mais moins formelle. Le backlog de produit servira donc de fil rouge

Dans une perspective seulement itérative

… de type Processus Unifié (« Unified Process »), le concept ou plutôt la discipline « Ingènierie des exigences » prend cette fois tout son sens puisque prévue, formalisée et cadrée, permanente et continue. Les acteurs chargés de ces activités vont donc suivre le projet du début à la fin, certes avec plus de spécification en 1ère partie du projet (80% des cas d’utilisation doivent être rédigés en fin d’Elaboration), et davantage de gestion des exigences dans la seconde partie.

A bientôt pour plus de détails sur le Quoi et une idée du Comment.

Si vous désirez en savoir plus sur notre approche du cadrage agile avec Eveil Agile® Projet, ou sur le coaching agile en général; n’hésitez pas à nous contacter par mail à l’adresse suivante : jcgrosjean@gmail.com ou par téléphone au 06 20 98 58 40.