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

Posté par jc-QualityStreet le 27 juin 2007

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, 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 tels que DOORS, Requisite Pro, Caliber-RM …)

Evidemment, 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 : maîtrise de diverses techniques souvent complémentaires (issues des Sciences Humaines), pas mal de rigueur et une bonne dose de formalisme :
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…

L’Analyste, le Consultant, le Client : 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 sont quant à eux le fruit de l’activité de recueil, et servent souvent de déclencheurs pour la suite des opérations en mode itératif ou séquentiel.

Dans une perspective séquentielle (cascade ou V), l’enchaînement est simple et bien connu, et même si, comme le souligne fort justement Claude Aubry, le cycle de vie en V n’existe pas, 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.

Dans une perspective 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.

• 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 en Sprint 0, l’ingenierie des exigences se jouera principalement au travers du Backlog de Sprint & User Stories dans une dynamique plus collaborative, toute aussi disciplinée mais moins formelle.

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