L’expression « traçabilité des exigences » comporte en elle-même différentes significations :
– le terme exigences fait-il référence strictement aux besoins des futurs utilisateurs, et/ou aux critères et contraintes du maître d’ouvrage, et/ou aux exigences générées par les choix techniques et les contraintes de réalisation ? se situe-t-on à un niveau système ou équipement ?
– le terme traçabilité fait-il référence à la trace entre le besoin et la solution, ou la trace des choix, ou à la logique de déclinaison des exigences selon l’arborescence technique, ou à une logique de validation ou preuve de la pertinence de la solution,…?
Avant de parler de démarche et outils pour tracer les exigences (« comment tracer »), il nous parait fondamental avant tout de déterminer :
pour qui tracer ? et pour quelle utilisation ? et donc que faut-il tracer ?
La première contribution méthodologique du MV n’est-elle pas d’imposer la définition du problème avant d’étudier sa résolution ?
Parle -t-on :
– de traçabilité pour faciliter/maîtriser l’évolution du système dans le futur
– ou de traçabilité pour vérifier/valider la solution proposée
– ou de traçabilité pour justifier sa propre solution
– ou de traçabilité pour s’assurer de la cohérence de développements confiées à différents concepteurs/réalisateurs?
– ou de traçabilité pour vérifier que la solution est non seulement bonne mais aussi la meilleure ?
– ou de traçabilité pour faciliter la prise en compte des évolutions des exigences ?
ce terme évolution des exigences comportant lui-même plusieurs sens : compléments d’exigences, modifications, évolution du besoin, levées d’incertitudes.
– ou traçabilité pour anticiper les risques de non-atteinte des exigences ?
Il serait illusoire – et dangereux – de penser qu’une même réponse méthodologique ou encore pire organisationnelle puisse être apportée, de manière pertinente, à des buts aussi différents !… mais il serait agréable de penser qu’il pourrait y avoir une « structure commune » dans ces réponses méthodologiques qui se différencieraient alors par les éléments de structure qu’elles traiteraient …
la maîtrise des exigences se fondent sur la rigueur d’expression des besoins….
Des méthodes et outils existent dans ce domaine, et l’apport de méthodes et outils tels que l’analyse de la valeur, la maîtrise des risques est évident dans ces phases.
Ces approches doivent se référer à une approche systémique tant du système que du projet, prenant en compte :
– les besoins et contraintes liées aux phases d’utilisation mais aussi aux autres phases de vie du système,
– les exigences tant en mode nominal qu’en modes dégradés,
– mais aussi l’ensemble des points de vue : organisationnel, temporel, technique.
mais ces exigences initiales évoluent…
Pour un système complexe, il est «normal » que les exigences exprimées en amont ne soient ni stables ni complètes.
– Instables parce qu’elles reposent elles-mêmes sur des hypothèses d’utilisation et d’environnement et sur des choix stratégiques de maîtrise d’ouvrage, définis à un temps donné,
tracer les exigences requiert également de tracer les hypothèses et décisions sur lesquelles elles reposent.
– Incomplètes parce que le système que l’on développe n’est jamais complètement autonome, et que certains choix de conception imposeront de clarifier des exigences complémentaires liées aux choix d’architectures, de mise en œuvre, ou aux impacts engendrés sur des systèmes techniques ou organisationnels en interface.
tracer les exigences requiert également la possibilité de les compléter à chaque étape de la conception et donc d’établir des « retours» (maîtrisés) sur l’expression initiale de besoins,
tracer les exigences requiert fondamentalement une approche systémique replaçant chaque choix dans son environnement technique, organisationnel et temporel.
la déclinaison des exigences est liée aux choix de conception…
Quand l’architecte trace un trait sur son plan, c’est l’aboutissement d’une logique de conception et donc d’une succession et d’une synthèse de choix : c’est cette logique qui fait le lien (et donc la traçabilité) entre le problème à résoudre et les traits qu’il trace.
Ce sont ces choix successifs – des principes généraux jusqu’aux principes techniques – qui transforment les exigences à chaque niveau et font « passer » du besoin aux caractéristiques pertinentes de la solution.
tracer les exigences d’un système complexe nécessite la maîtrise et la formalisation d’une méthode de conception, pour expliciter les liens entre exigences de niveaux différents et donc d’expliciter les choix successif qui les transforment.
tracer les exigences requiert une rigueur de différenciation, à chaque niveau, des exigences, découlant des besoins initiaux, ou des choix de principes, ou d’architecture ou d’organisation. Leurs rasons d’être différant, elles ne peuvent être traitées de manière identique.
Schéma A Schématisation d’une méthode de conception intégrant l’analyse de la valeur et l’ingénierie systèmes
Schéma B Schéma de conception et origines des exigences
Schéma C : Outil de traçabilité des choix et des logiques de choix (Arbre des Voies Technologiques de la méthode APTE)
mais les choix sont eux aussi entachés d’incertitudes …
Pour avoir une traçabilité exploitable, il faut se référer non seulement aux choix, mais aussi aux raisons d’être de ces choix à un temps donné, à leurs limites de pertinence.
tracer les exigences requiert la prise en compte de la traçabilité des logiques qualitatives et économiques associées aux choix, des hypothèses et des risques associés.
Des réponses méthodologiques existent….
Les quelques schémas proposés dans ces pages, illustrent, de manière très succincte, des propositions méthodologiques fondés sur des démarches d’analyse systémique, de management par la valeur et de maîtrise des risques.
Restant partielles, elles éclairent de nombreuses pistes de recherche :
Peut-on mieux préciser les buts recherchés dans la traçabilité des exigences, et ainsi clarifier les informations utiles et juste nécessaires à tracer selon les types de projets, les risques, les acteurs,…
Comment résoudre, dans le respect de chacun, le dilemme suivant :
– le maître d’ouvrage, pour valider la pertinence de la solution proposée, a besoin de connaît re les choix successifs qui l’on fait naître,
– comment le maître d’œuvre peut-il fournir ses logiques de conception sans révéler ses propres choix stratégiques et une part de savoir-faire, qu’il souhaite maintenir confidentiels ?
Des avancées sur ces deux derniers points contribueront, à notre sens, à la clarification des contenus des documents produits tout au long d’un projet, ainsi qu’à leur cohérence.
– peut-on définir des règles-type de transformation des exigences à travers les choix de principes : selon des types de principes, des types d’environnement, des types de fonctions-mères, des types d’associations de principes.. ?
– peut-on améliorer la modélisation des logiques de conception, en comprenant mieux les mécanismes heuristiques de ces logiques de créativité et de décision ?
Des avancées dans ces domaines, en se rapprochant des sciences cognitives mais aussi de la technologie (dans le sens sciences des techniques), ne pourront qu’aider à éclairer les démarches d’allocation des exigences, qui constituent un corollaire à leur traçabilité.
Mme Catherine Laval, Journée AFAV, 28/09/2000 « Maîtriser la dynamique d’expression des exigences »