Le projet SI : une histoire d’exigences

Article paru le 18 novembre 2014 | Partager sur les réseaux sociaux

Classé dans : Transformation SI Tribune

La réussite d’un projet SI repose avant tout sur ces premières phases, au moment où les besoins doivent être captés et décrits. Documenter les attentes pour définir une solution qui y réponde pertinemment est en effet un exercice difficile, et faire partager et maintenir cette vision tout au long de sa mise en œuvre n’est pas moins compliqué. La gestion par les exigences définit ainsi une méthode pour répondre à ces problématiques, définissant un cadre pour que chacun des acteurs ait une vue commune et claire des qualités du système à obtenir.

Les exigences sont avant tout l’expression, voire la traduction de besoins métiers. Elles documentent ce que le produit final doit être et doit faire. En construction dès la rédaction du cahier des charges, les exigences sont la base de la relation client-fournisseur, et peut former le cadre contractuel pour le suivi de la prestation. Elles doivent être formulées de sorte qu’elles ne soient pas différemment interprétables d’un interlocuteur à l’autre, et suffisamment documentées afin de permettre la fourniture d’une solution pertinente, complètement cohérente avec les attentes initiales. La réunion de l’ensemble des exigences constitue ainsi un référentiel global, qui d’après les normes IEEE doit avoir les propriétés suivantes : exact, non ambiguë, complet, cohérente, hiérarchisée en fonction de l’importance, vérifiable, modifiable et traçable. La relecture et validation de ce référentiel est indispensable et fait intervenir, d’une part les futurs utilisateurs pour vérifier que leurs besoins sont bien pris en compte, et d’autre part l’intégrateur pour s’assurer que la description de ces besoins est explicite et clairement compréhensible.

Afin de les tracer efficacement, les exigences doivent être catégorisées en différents niveaux et leurs attributs définis dès leur construction.

On distingue par exemple parmi ces attributs :

  • L’identifiant : Chaque exigence est ainsi identifiée de manière unique, satisfaisant le critère de non-redondance
  • Le type : On ne détaillera pas une exigence aboutissant une fonctionnalité de la même manière qu’une exigence décrivant une contrainte purement technique
  • Le libellé : Celui-ci doit être assez explicite pour résumer succinctement le besoin
  • La priorité : Indispensable pour prévoir les arbitrages, et distinguer l’essentiel de ce qui peut être reporté.
  • L’état : Chaque exigence possédant un cycle de vie, il est important savoir si l’exigence correspondante a été validée par l’ensemble des acteurs impliqués.
  • La date et la version.

Le référentiel des exigences sert ainsi de ciment tout au long du projet sur toutes les phases, et permet de structurer et tracer les besoins métier jusqu’à la mise en production. Il justifie en amont la présence des différentes fonctionnalités en les reliant directement aux besoins. Ce même référentiel se retrouve également en aval au moment de la recette, pour rédiger et organiser les cas de test permettant de vérifier le travail de conception et de développement. Il est même amené à perdurer entre les différentes versions de la solution une fois celle-ci mise à disposition des utilisateurs, les évolutions des besoins entrainant évidemment des évolutions sur les exigences.

On devine au final que la notion d’exigence est assez générique et peut s’étendre, au-delà de l’ingénierie des SI, à bien d’autres domaines tels que l’industrie, les télécoms, l’aéronautique, l’économie ou même la politique. Les démarches qualité et d’optimisation des coûts sont d’ailleurs applicables sur tout projet peu importe le domaine, car la gestion par les exigences tire bien son existence de ces finalités.

Tribune de Hector Sounthone, consultant mc²i Groupe.

Lire la tribune sur le site : ITR Manager.com

Partagez cet article sur les réseaux sociaux