Analyse fonctionnelle complément de la gestion des exigences

La gestion des exigences supportée par des outils méthodologiques

Conférence lors des journées organisées par le Centre pour la Maîtrise des Systèmes et du Logiciel (CMSL) du Conservatoire National des Arts et Métiers (CNAM), Paris – 5-7 décembre 2006.

Intervenants
Thierry BEAUJON, Directeur de Knowllence – BP 4 – 25 520 Goux les Usiers Tél. : 0 381 382 950 – FAX : 0 381 382 959
Maria Paz Claros Salinas, Guy Prudhomme,  Laboratoire 3S – Pôle Conception intégrée – INPG.

Pour en savoir plus sur l’état de l’art actuel, inscrivez-vous à l’un de nos webinaires :

Enjeux de la gestion des exigences: client / fournisseurs

Les enjeux des années 80 étaient axés sur la qualité/performance des produits, puis dans les années 90 s’est ajouté la pression sur les coûts et enfin maintenant ce sont les délais qui préoccupent les industriels. Le besoin d’accélérer les processus de conception entre le donneur d’ordre et ses fournisseurs impose de plus en plus l’utilisation de plate forme collaborative. Ces plates formes se limitent essentiellement aujourd’hui à la mise à disposition d’un espace de communication numérique entre les acteurs du processus. Ces environnements permettent de partager essentiellement les données structurelles et physiques du système étudié ainsi que les données projet (comme le permet par exemple la plate forme Visioconcept à Montbéliard pour la filière automobile), mais pas encore assez les exigences. La conséquence est la perte de temps dans le projet inhérent à la nature même des exigences : complexes, floues, incomplètes et évolutives.

La complexité, l’imprécision et l’incomplétude peuvent être traitée selon nous par les méthodologies d’élicitation du besoin telles que l’analyse fonctionnelle du besoin (AFB) selon les normes européenne EN 1325-1 pratiquée en groupe de travail pluridisciplinaire. En effet, le schéma ci-dessous décrit les étapes à suivre pour donner toutes les composantes utiles à l’élicitation du besoin initial, dont la partie explicite est généralement exprimé en langage naturel, afin d’aboutir à un document formalisé qu’est le Cahier des Charges Fonctionnel (CdCF) avant de passer aux étapes de recherche de solutions.

Figure 1 : Positionnement et étapes de l’analyse fonctionnelle du besoin

Cette description progressive et formalisée du besoin est nécessaire car le besoin est complexe à cerner. En effet, il se présente initialement sous trois formes : exprimé, mais aussi implicite et potentiel. L’objectif de cette démarche structurante d’analyse fonctionnelle du besoin est de n’avoir en fin de processus que des besoins exprimés afin de limiter au maximum les dérives qui s’en suivront inévitablement dans le projet. Les besoins initialement implicites ou potentiels vont émerger ultérieurement et amener à remettre en cause des choix de conception et donc agir directement sur les coûts et délais du projet. Les besoins implicites sont ceux dont on ne parle pas car ils sont dans les standards de fait (ou dans la tête des concepteurs) ! Le problème est que ces standards de fait ne sont pas forcément partagés entre le donneur d’ordre et les fournisseurs, en particulier avec le turn-over existant dans les entreprises. Les besoins potentiels eux ne sont même pas consciemment connus des demandeurs. Les outils méthodologiques utilisés comme la « pieuvre » (outil graphique de la méthode APTE, ), les matrices de découvertes permettent d’une part d’exprimer les besoins initiaux en terme de services à rendre et non pas de solutions, mais aussi de mettre en évidence, donc de passer à l’état exprimé, les besoins implicites et potentiels. La caractérisation, avec les concepts de critère de performance, de niveau associé et de degré éventuel de négociation du niveau (flexibilité) et avec la valorisation des fonctions, permet d’éviter l’imprécision latente des expressions de besoin.

L’évolutivité des exigences, elle, peut être traitée par les supports informatiques de gestion des exigences à condition qu’ils soient collaboratifs. En effet, si la phase d’expression initiale du besoin à l’aide de l’analyse fonctionnelle du besoin se réalise en groupe de travail en « présentiel », les besoins qui seront complétés par des contraintes de conception, normatives, … deviendront des exigences amenées à évoluer dans le processus de conception éclaté géographiquement, surtout pour les systèmes complexes, avec la difficulté supplémentaire de gestion des interfaces. Cette gestion des interfaces est traitée efficacement par l’approche système.

Positionnement Gestion et Ingénierie des exigences

Nous faisons ici la distinction entre les activités de gestion des exigences qui permettent d’assurer leur traçabilité au sens où est conservée une trace des exigences et des liens qui peuvent être construits entre différents niveaux d’exigence, et l’ingénierie des exigences au cours de laquelle seront explicitées et transformées ces exigences tout au long de la conception. La littérature scientifique fait référence à ce concept d’ingénierie des exigences et lui attribue le but de déterminer et définir les exigences. Celles-ci sont alors définies comme l’ensemble des besoins auxquels le produit devra répondre et des contraintes liées à son cycle de vie. Les méthodes existantes préconisent de les faire émerger de façon assez détaillée au début du processus de conception. Notre point de vue est qu’il n’est pas possible d’identifier et définir toutes les exigences avant de commencer le processus de conception, même si l’organisation industrielle et les outils permettent le travail collaboratif (en « présentiel » ou à distance). En cours de conception, les exigences préalablement identifiées vont évoluer (propriété d’évolutivité évoquée précédemment) et des nouvelles exigences apparaîtront. Ces exigences viennent non seulement du donneur d’ordre (client externe) mais aussi des différents services de l’entreprise comme par exemple la production, la fabrication (client interne).

Nous avons développé, sur trois axes, une grille d’analyse des besoins relatifs à la gestion ou à l’ingénierie des exigences au cours du processus de conception des produits. Cette représentation doit nous permettre d’analyser quelles sont les caractéristiques que possèdent les outils traitant des exigences actuellement sur le marché, et de mettre en évidence les caractéristiques que ceux-ci doivent avoir en fonction des activités qu’ils sont sensés supporter.

La grille d’analyse est présentée ci-dessous et les différents axes sont ensuite explicités. Puis nous illustrerons notre analyse avec deux outils à partir de cette grille: Doors® et TDC Need®.

Chaque axe de la grille d’analyse correspond à un point de vue sur le processus de conception :

Une vue Management de projet, parce que le processus de conception reste avant tout un projet, avec un début, une fin, des objectifs à atteindre, …
Une vue représentation du produit car tout au long du processus de conception les concepteurs vont manipuler de manière coordonnée différentes représentations du produit (fonctionnelle, structurelle et physique)
Et sur le troisième axe nous avons défini les propriétés du processus de conception qui doivent être supportées pour permettre une bonne gestion des exigences.

Figure 2 : Grille d’analyse des besoins pour la prise en compte des exigences

 

Vue Management de projet

Sur cet axe sont représentées les étapes du projet parce que le processus de conception d’un produit mécanique s’inscrit dans un projet qui est celui de concevoir un produit. Le processus de conception doit donc prendre en compte les différentes phases ou étapes définies par la gestion de projet, avec des jalons et des délais à respecter. Le passage d’une phase à une autre est marqué par des réunions pour la prise des décisions et les choix des solutions. Cette vue est très utile, car elle nous permettra d’identifier les phases du projet qui sont supportées par les outils traitant des exigences.

 

Vue Représentation du produit

Au cours du processus de conception, le produit est représenté de différentes façons par les concepteurs. Au début du processus de conception la représentation du produit sera plutôt fonctionnelle, ensuite elle sera principalement structurelle et finalement physique :

Représentation fonctionnelle : Dans cette représentation nous trouvons les fonctions auxquelles le produit à concevoir doit satisfaire, que ces fonctions soient de service ou techniques. Selon la méthode de l’Analyse Fonctionnelle, une fonction est caractérisée par des niveaux , des critères et une flexibilité.
Représentation Structurelle : Cette représentation est une description de la structure du produit avec ses composants et les liaisons entre eux. Ceci peut être fait par exemple en utilisant des schémas ou des blocs-diagrammes.
Représentation Physique : C’est une description géométrique et technologique des propriétés du produit. Des représentations 2D ou 3D ainsi que des prototypes sont des exemples de représentations utilisées.

 

Vue sur les propriétés du Processus de Conception

Les objectifs de cet axe sont d’identifier les propriétés du processus de conception relativement aux exigences afin d’analyser les activités qui sont actuellement assistées par des outils, et comment elles le sont, et celles qui ne le sont pas. Nous nous plaçons dans un contexte de conception collaborative, dans lequel des concepteurs, experts de différents métiers, sont amenés à travailler ensemble pour prendre en compte au plus tôt les contraintes des différentes étapes du cycle de vie du produit. En conséquence chacun de ces acteurs aura un point de vue et des exigences différents vis-à-vis du produit, ceux-ci étant issus de son domaine d’expertise. Ils devront exprimer leurs attentes vis-à-vis du produit afin que l’équipe de conception en prenne connaissance et en construise un sens commun (élicitation et formalisation). La première expression des exigences va servir de base à la recherche de solutions, d’un point de vue fonctionnel ou/et structurel. Ces solutions seront évaluées au regard de critères techniques qui devront être en lien avec les critères des fonctions de service (propagation) et cohérents entre eux (corrélation). Ces évaluations peuvent conduire à des remises en cause des solutions mais aussi des exigences établies (dynamique). D’un point de vue capitalisation de l’information, il peut être utile de garder une trace (traçabilité) des décisions prises, et de leurs raisons, concernant l’évolution des exigences.

Cet axe est donc composé de ces six principales propriétés du processus de conception, au regard des exigences, que nous allons décrire plus précisément :

Elicitation : Cette propriété concerne la capacité à faire sortir, faire émerger, découvrir les besoins de l’ensemble des clients. Les concepteurs ont besoin de méthodes performantes pour pouvoir développer cette activité. Parmi les méthodes les plus utilisées par les concepteurs nous retrouvons l’expression fonctionnelle du besoin, le brainstorming, le QQQOCP (quoi, quand, qui, où, comment, pourquoi).

Formalisation : La formalisation est une propriété qui permet, par l’existence d’un langage partagé par les acteurs, d’écrire, de mettre en forme ces exigences. Ce langage doit permettre aux concepteurs de partager leurs points de vue ainsi que de négocier sur les caractéristiques du futur produit. L’Analyse Fonctionnelle, au travers du triptyque fonctions-critères-niveau (-flexibilité) est une méthode qui doit permettre la formalisation des exigences.

Corrélation : La corrélation rend compte de la cohérence entre les exigences à un niveau d’expression donné. C’est une relation entre les différentes exigences qui rend compte de la possibilité (ou de l’impossibilité) de les respecter de manière concomitante. Le toit de la maison de la qualité dans les méthodes QFD rend compte de cette corrélation.

Propagation : Les exigences à différents niveaux sont liées entre elles. Un paramètre de définition du produit (une cote, une rugosité, …) est lié à un (ou plusieurs) critère d’appréciation d’une fonction au niveau structurel qui est lui même lié à un critère d’appréciation de fonction(s) de service. Nous définissons la propagation comme la capacité de créer de liens entre les exigences de ces niveaux différents. Ces relations doivent nous rendre capable d’identifier l’impact de modifications relatives aux exigences dans un sens amont-aval (fonctionnel-physique) ou aval-amont au cours du processus de conception.

Dynamique : Pendant le processus de conception de nouvelles exigences peuvent apparaître et d’autres disparaître. En conséquences des nouveaux liens entre celles-ci et les exigences existantes doivent pouvoir être créés ou être supprimés sans remettre en cause la globalité de la structure existante. Par exemple le QFD est un outil qui supporte les propriétés de corrélation et de propagation mais ne supporte pas cette propriété de dynamique de l’expression des exigences.

Traçabilité : Au cours du processus, des solutions seront remises en cause parce qu’elles ne répondent pas à une exigence, ou une exigence sera abandonnée (flexibilité) parce qu’on ne connaît pas, à un instant donné, de solution pouvant la satisfaire. La traçabilité est la capacité de garder un historique de ces orientations dans le but de réutiliser ces données ou simplement pour être capable de comprendre les spécifications qui ont défini les caractéristiques du produit.
Maintenant que nous avons décrit les différents axes de notre grille, nous allons la faire fonctionner pour analyser deux outils qui sont mis à la disposition des concepteurs pour traiter des exigences : Doors® et TDC Need®.

 

Etapes du projet

TDC Need® : Les premières données introduites dans le logiciel sont des informations générales sur le projet. Les équipes de conception doivent répondre à un questionnaire basé sur les normes AFNOR. Ensuite, les besoins sont identifiés à partir de l’utilisation du graphe des interacteurs (« pieuvre ») et sont introduits en termes des fonctions, critères, niveaux et flexibilité dans le tableau de caractérisation (proposé par l’Analyse Fonctionnelle). Ce logiciel est très utile pendant les deux premières phases du projet.

Doors®: Pour utiliser ce logiciel, les exigences du produit doivent être définies au préalable. Une fois les exigences introduites dans le système, le concepteur est capable de créer les liens entre les exigences et suivre leur évolution tout au long du processus de conception. L’outil supporte la plupart des phases du projet sauf l’élicitation.

 

Représentation du produit

Logiciel TDC Need® : Il supporte principalement la représentation fonctionnelle du produit grâce à la méthode de l’Analyse Fonctionnelle. Il permet de représenter les besoins du client en termes de fonctions. La représentation structurelle est supporter par le module logiciel complémentaire TDC Structure®.

Doors®: Ce logiciel supporte la représentation fonctionnelle du produit tout au long du cycle de vie du produit.

 

Propriétés du processus de conception

TDC Need® : La méthode de conception à la base de ce logiciel (Analyse Fonctionnelle) assiste les concepteurs dans l’expression des exigences et de leur formalisation. L’outil permet de garder les différentes versions. La traçabilité et la propagation sont assurés au niveau des fonctions et des critères.

Doors®: L’outil assiste les concepteurs dans la formalisation des exigences ainsi que dans la création des liens entre les différents niveaux. L’outil permet aussi de construire les liens de propagation. Doors® permet au concepteur d’avoir une vue globale sur l’évolution des exigences (changement, ajout…).

 

A partir de l’analyse précédente, nous avons positionné les outils sur la grille d’analyse. (cf. figure xx). Nous pouvons observer que ces deux outils ne supportent pas les mêmes activités. Doors®, sert principalement à surveiller les changements et évolution des exigences, tandis que TDC Need® assiste les concepteurs dans l’expression et formalisation des exigences. Les deux outils sont plutôt complémentaires : l’un est un outil de gestion des exigences, l’autre est un outil d’ingénierie des exigences.

Figure 3 : Positionnements respectifs de Doors® et TDC Need®

Nous pouvons aussi observer qu’il y a des phases qui ne sont pas supportées par les ces outils de gestion de exigences.

Le but a long terme est de fournir une liste de fonctionnalités qui doivent être inclues dans les logiciels de gestion des exigences pour mieux supporter les entreprises dans la gestion de ses exigences.

 

Exigences structurées de facto par les méthodes de conception

Les besoins de base des exigences avec leurs structurations, le collaboratif et l’approche ingénierie étant exposé, force est de constater que sur le terrain un autre besoin émerge : celui de la pérennisation de ces approches. Pour ce faire nous avons acquis l’expérience depuis plus de 16 ans de la mise en place de supports informatiques dédiés aux méthodologies de conception dans cet objectif de pérennisation. Le témoignage suivant va par exemple dans ce sens :

« Parmi les produits proposés par la société Knowllence, le logiciel TDC FMEA est un atout majeur pour PLASTIC OMNIUM dans le cadre du déploiement de son organisation AMDEC. Cette application, adaptée à nos besoins par le biais des paramétrages, répond clairement à nos objectifs de productivité, de capitalisation de notre expérience et de traçabilité des données. Grâce à l’acquisition de nombreuses licences TDC FMEA par nos équipes de développement et nos sites de fabrication, la méthode AMDEC n’est plus considérée comme une contrainte imposée par nos clients mais comme un véritable outil de travail indispensable au développement de nouveaux produits. Les AMDEC, de part leur mise en œuvre avec TDC FMEA, font désormais la force de la division Auto Exterior du groupe PLASTIC OMNIUM. C’est également un progrès largement apprécié par tous nos clients français mais aussi étrangers. »
David BELCASTRO , Ingénieur Méthodes Qualité au Centre Technique PLASTIC OMNIUM Auto Exterior
12 février 2002 »

L’outil informatique éprouvé comme un bon moyen de pérennisation est ici positionné également comme le bon moyen de générer les exigences dans le cadre d’un projet complexe sans que cela ne soit une fin en soi. Ainsi les pratiques déjà en place dans l’entreprise, comme dans le témoignage précédent avec les analyses de risques de type AMDEC, mais aussi lors des activités d’analyse fonctionnelle du besoin, d’analyse fonctionnelle technique, de créativité, de résolution de problème, de choix de solutions permettent de faire émerger des exigences de facto sans même s’en rendre compte. Il s’agit donc de s’appuyer sur les activités usuelles de conception pour organiser les informations entre-elles et ainsi pouvoir ensuite les exploiter avec la vision gestion des exigences grâce à des logiciels adéquats.

Le schéma ci-après positionne les différentes activités d’ingénierie dans le cycle en V de la conception qui permettent de créer, organiser et ensuite exploiter les exigences dans la vie du projet.

Figure 4 : Activités de création des exigences dans le cycle en V de conception de systèmes

 

Un exemple sur un gros Système d’Information

Nous aborderons ici le cas des spécifications d’un système d’information de quelques dizaines de millions d’euros, dans le cadre d’une relation client / fournisseur, qui a été menée à partir d’une autre méthode de conception qu’est l’Analyse de la Valeur.

Le contexte de ce projet était de réduire de 50% le budget alloué à un gros investissement de système d’information dans un délai de moins de deux mois. La démarche d’Analyse de la Valeur a été retenue avec le support informatique de la Suite TDC et en particulier le module TDC Need. Six séances de travail en séance plénière d’une journée et du travail hors séance d’affectation des coûts aux besoins ont été suffisantes pour aboutir à l’objectif dans le délai imparti. La solution retenue et mise en place a consommé 54% du coût initial pour tout de même 79% du besoin global. Cette démarche supportée par des logiciels adéquats a en outre permis de mettre en œuvre l’ingénierie des exigences dans la suite du projet dans le cadre des relations client / fournisseur retenu pour la prestation. La non disponibilité à l’époque d’une sur-couche collaborative à ce support informatique a compliqué la gestion entre les différents acteurs du processus.

La description fonctionnelle détaillée du système est constituée d’une centaine d’exigences caractérisées et valorisées. Vous trouverez ci-après quelques extraits volontairement incomplets et transformés pour des raisons de confidentialité de la partie analyse fonctionnelle avant affectation des coûts.

 

Des logiciels support de l’ingénierie des exigences

Nous démontrerons enfin très sommairement les concepts développés à partir de la « Suite méthodologique TDC (Robust Engineering Suite) » et sa plateforme collaborative d’ingénierie système en cours de réalisation dans le cadre d’un programme de R&D soutenu par BPIFrance (OSEO ANVAR) et par le pôle de compétitivité Véhicule du Futur.