L’ingénierie des exigences assistée par des outils méthodologiques

Cet article est issu de notre expérience de travail avec les industriels depuis plus de 20 ans, dans un grand nombre de secteurs d’activité : automobile, aéronautique/défense, pharmaceutique, biens d’équipements industriels et domestiques, nucléaire, transport, …

Résumé

Le présent document traite de quatre points relatifs à l’ingénierie des exigences. Tout d’abord, après un cadrage de la thématique, sont abordés les enjeux dans la chaîne client / fournisseurs : L’ingénierie des exigences est de plus en plus importante pour l’ensemble des partenaires impliqués dans la conception d’un système complexe ; cet enjeu ne se limite plus, en effet, au seul donneur d’ordres mais aussi à ses fournisseurs directs et indirects, ce qui implique une approche collaborative de la gestion des exigences dans ce que l’on appelle l’entreprise étendue.

En deuxième point, nous ferons la distinction entre les activités de gestion des exigences, pour en assurer leur traçabilité, et l’ingénierie des exigences, pour en assurer également leur mise en œuvre (élucidation, support à la propagation dans l’action, aspect dynamique…).

Dans le troisième point, il est montré que l’utilisation des méthodes et outils usuels de conception (notamment l’analyse fonctionnelle, l’analyse de la valeur et l’analyse des risques) conduit naturellement à faire émerger et structurer les exigences d’un système ; la place des diverses activités de l’ingénierie des exigences dans le cycle de vie d’un système complexe est alors décrite.

Enfin nous ouvrirons la réflexion sur la gestion des exigences dans le cadre de l’ingénierie système.

D’autre part, la grande difficulté des organisations actuelles n’est pas seulement de définir les modes de fonctionnement méthodologiques qui vont permettre de garantir une bonne gestion des exigences durant tout le cycle de vie du produit, mais aussi le déploiement des processus de travail des équipes sur le terrain dans un environnement de plus en plus complexe : multi-sites, multiculturel, multi-client et de plus en plus concurrentiel.

Les réflexions conceptuelles seront étayées par des applications informatiques qui aident à mettre en œuvre ces techniques. Notre offre, avec Robust Engineering Suite, nous situe dans les phases amont du développement et de l’industrialisation avec les outils d’extraction et de formalisation des besoins, des risques, des défaillances, … qui constituent la matière première des exigences. Ensuite, lorsque cela se justifie, nous pouvons passer la main aux logiciels de gestion des exigences comme Doors®, Reqtify® ou TEEXMA® qui « compilent » les exigences en provenance de sources métiers diverses pour en assurer leur traçabilité globale.

Mots clés

ingénierie des exigences, complétude, traçabilité, méthodes de conception, analyse de la valeur, analyse de risques, ingénierie système, Robust Engineering Suite, Suite TDC.

Cadrage de la thématique exigences

Définitions des exigences

Selon l’AFIS (Association Française d’Ingénierie Système) la définition est la suivante : « Quelque chose qui prescrit ce qu’un produit doit faire, avec quelles performances et sous quelles conditions, pour atteindre un but donné » (www.afis.fr)

On notera aussi l’usage suivant qui est fait dans les grands projets : est considéré comme exigence toute entité qui doit être tracée durant la vie du produit.

Il faut bien distinguer dès maintenant les exigences et les besoins. Si un besoin engendre bien une ou plusieurs exigences, les exigences ne se limitent pas à la voix du client. On trouvera dans les exigences la caractérisation des fonctions de service certes, mais aussi les normes à respecter, certains risques majeurs, les règles métier à respecter ainsi que les coûts et délais  objectifs. La nature d’une exigence qui peut être très variable est aussi liée au point de vue. Une assertion peut être une exigence pour une partie mais pas pour d’autres.

Pour exister, une exigence doit impérativement être vérifiable, c’est-à-dire permettre de déterminer si elle a été atteinte ou non.

Pourquoi parler d’exigences

• Pour maîtriser les relations clients/fournisseurs
• Pour permettre de vérifier, puis valider que le produit/service correspond à ce qui est demandé par le client mais aussi tout l’écosystème associé.
• Pour optimiser la conception
• Pour avoir confiance dans le passage des jalons du processus de conception
• Pour communiquer sur les objectifs et impliquer les équipes de développement

Le problème majeur du domaine des exigences : l’incomplétude

Le constat est qu’un tiers des causes d’échec des projets proviennent d’une INCOMPLÉTUDE des exigences (The Standish Group : The CHAOS Report 1994). Nous nous appuierons dans ce qui suit sur ce constat pour privilégier cette recherche d’exhaustivité et de clarté.

Origines des exigences

Les exigences sont soit « imposées » issues en particulier des besoins et contraintes exprimées par les demandeurs, soit des exigences « dérivées » produites pendant l’activité de conception du produit et process.

Les enjeux dans la chaîne client / fournisseurs

Les enjeux des années 80 étaient axés sur la qualité et les performances des produits, puis dans les années 90 s’est ajoutée la pression sur les coûts, puis les délais et, enfin maintenant, la capacité d’innovation qui préoccupe les industriels avant que n’arrive, selon nous, la gestion des talents. 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 plateformes collaboratives. Ces dernières se limitent essentiellement aujourd’hui à la mise à disposition d’un espace de communication numérique entre les acteurs du processus associé à de la gestion de projet (GANTT). Ces environnements permettent de partager essentiellement les données structurelles et physiques du système étudié ainsi que les données projet, mais pas encore suffisamment les exigences. L’innovation engendre elle, une bonne gestion du changement. La conséquence est la perte de temps dans le projet inhérente à la nature même des exigences : complexes, floues, incomplètes et évolutives.

La complexité, l’imprécision et l’incomplétude (le problème majeur de ce domaine) peuvent être traitées selon nous par une méthodologie d’énoncé du besoin telle que l’analyse fonctionnelle du besoin (AFB) selon les normes européennes 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’explicitation du besoin initial, dont la partie explicite est généralement exprimée en langage naturel, afin d’aboutir à un document formalisé (Cahier des Charges Fonctionnel : CdCF) et 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é, 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 bien 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 qui émergeraient ultérieurement, amèneraient à 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 comme la « pieuvre » (outil graphique de la méthode APTE®) et les matrices de découvertes permettent d’exprimer les besoins initiaux en termes 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é, 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 efficacement par les supports informatiques de gestion des exigences surtout s’ils sont collaboratifs. Cette évolutivité doit au passage être tracée entre l’expression initiale des besoins clients et leur modélisation fonctionnelle. Si la phase de structuration 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.

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 ces exigences seront explicitées et transformées 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 de 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 ou 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, et de mettre en évidence les caractéristiques que ceux-ci doivent avoir en fonction des activités qu’ils sont sensés assister.

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 offertes pour permettre une bonne gestion des exigences.

Figure 2 : Grille d’analyse des besoins pour la prise en compte des exigences (d’après les travaux de thèse de Maria Paz Claros Salinas du Laboratoire G-SCOP – INPG)

Vue « management de projet »

Sur cet axe sont représentées les étapes du projet. 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. Ces outils permettent de valider plus rapidement le passage à la phase avale.

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, des blocs diagrammes fonctionnels ou le SaDT.
• 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 en mécanique.

Vue sur les propriétés du processus de conception pour la gestion des exigences

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 (élucidation). 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). Du point de vue de la capitalisation de l’information, il est nécessaire de garder une trace (historique) des décisions prises, et de leurs raisons, concernant l’évolution des exigences.

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

• « Elicitation » / capture (élucidation) : Cette propriété concerne la capacité à faire sortir, faire émerger, découvrir les besoins de l’ensemble des clients externes et internes. 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), les scénarios opérationnels.
• Formalisation : La formalisation est une propriété qui permet, par l’existence d’un langage partagé par les acteurs multi métier de la mécatronique en particulier, d’écrire et 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 des fonctions de service et de leur triptyque critères-niveaux–flexibilité est une méthode qui permet 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 bien 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 de service (et inversement). Nous définissons la propagation comme la capacité de créer des liens entre les exigences de ces niveaux différents. Ces relations doivent nous permettre 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. En conséquence, 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.
• 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. L’arbre des voies technologiques est le support méthodologique idéal de mémorisation des choix de conception.

Contrairement aux solutions informatiques usuelles de gestion des exigences qui assistent dans la plupart des phases du projet sauf l’élucidation, le module Need® de Robust Engineering Suite s’appuie sur l’analyse fonctionnelle externe pour assister 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ées au niveau des fonctions de service et de leur caractérisation. La justification et la caractérisation des exigences et également assurée. La Robust Engineering Suite est un système intuitif de CREATION d’exigences à partir des méthodologies déjà en place dans les entreprises. Ces démarches permettent à la fois de tendre vers l’exhaustivité et la bonne formulation en terme de service à rendre et non pas de solution. En cela, Robust Engineering Suite de Knowllence aide à la complétude des exigences dès les phases amont.

Les entreprises utilisent de nombreux outils métiers selon leurs domaines d’application : mécanique, électronique, software, mais aussi selon leur historique avec les rachats successifs. La variété des outils supports de conception est incontestable. Pour différentes raison (résistance au changement, reprise de l’existant, sans parler du risque de dépendance avec un seul fournisseur) ces données métiers ne doivent pas être unifiées dans une seule solution logicielle par nature trop généraliste. La stratégie à privilégier pour s’assurer toutefois d’une bonne traçabilité de l’ensemble des exigences, est de garder les outils métier comme référentiel de l’information puis de consolider les données marquées comme des exigences dans un outil comme DOORS,  Reqtify de Dassault ou TEEXMA de Bassetti , de façon transparente pour les créateurs de sources d’exigence, donc sans impacter leur efficacité !

Les logiciels proposés par Robust Engineering Suite

Vous permettant de véritablement PARTAGER les données méthodologiques de conception, Robust Engineering Suite est composée de différents modules, indépendants et communicants :

• Need : analyse fonctionnelle du besoin, élaboration de cahiers des charges fonctionnels, expression du besoin

• Structure : Analyse fonctionnelle interne, Croisement Fonctions / Composants, Blocs Diagrammes Fonctionnels (BDF), SADT et tableaux d’analyse fonctionnelle (TAF)

• FMEA : Etudes AMDEC Produit, AMDEC Process, Plan de contrôle, AMDEC  Moyens, Analyses Préliminaires de risques

• FTA : Arbres de défaillance

Découvrez comment enchaîner ces méthodes de conception (webinaire)

Figure 3 : Couverture fonctionnelle de Robust Engineering Suite

En tant qu’outil D’INGENIERIE des exigences, Robust Engineering Suite est complémentaire aux outils de GESTION des exigences.

Des liens sont d’ailleurs déjà opérationnels chez certains donneurs d’ordres.

La structuration de facto des exigences assistée par les méthodes de conception

Les concepts de base des exigences avec leur structuration, le collaboratif et l’approche ingénierie étant exposés, force est de constater que sur le terrain, un autre besoin émerge : celui de la pérennisation de ces approches. En la matière, Knowllence a acquis une expérience de près de 20 ans dans la mise en place de solutions informatiques dédiées aux méthodes de conception avec cet objectif de pérennisation.

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, 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.

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

On peut aussi noter qu’avec Robust Engineering Suite, on fournit directement les Exigences Fonctionnelles Quantifiables pour la réalisation des simulations numériques adéquates.

Gestion des exigences et ingénierie système

Selon l’AFIS (www.afis.fr) « L’Ingénierie Système (ou ingénierie de systèmes) est une démarche méthodologique générale qui englobe l’ensemble des activités adéquates pour concevoir, faire évoluer et vérifier un système apportant une solution économique et performante aux besoins d’un client tout en satisfaisant l’ensemble des parties prenantes. 

Plus précisément, l’Ingénierie Système peut se définir comme :

• un processus coopératif et interdisciplinaire de résolution de problème,
• s’appuyant sur les connaissances, méthodes et techniques issues de la science et de l’expérience,
• mis en œuvre pour définir, faire évoluer et vérifier la définition d’un système (ensemble organisé de matériels, logiciels, compétences humaines et processus en interaction)
• apportant une solution à un besoin opérationnel identifié conformément à des critères d’efficacité mesurables,
• qui satisfasse aux attentes et contraintes de l’ensemble de ses parties prenantes et soit acceptable pour l’environnement,
• en cherchant à équilibrer et optimiser sous tous les aspects l’économie globale de la solution sur l’ensemble du cycle de vie du système.»

Dans ce contexte d’ingénierie système, l’ingénierie des exigences est une des pièces maîtresses. En effet, elle permet de gérer plus facilement les interfaces entre les systèmes parents mais aussi entre les systèmes frères.

Complémentaire à Robust Engineering Suite, la solution Teexma permet de supporter ce fonctionnement de gestion des exigences et de leurs relations :

• Structurer une hiérarchie d’exigences sans limitation dans le nombre de niveaux
• Définir les parentés et dépendances entre exigences
• Gestion des versions et historiques associés aux exigences
• Capitalisation des procédures de vérification et validation liées
• Capitalisation des rapports de vérification et validation liés
• Détermination des impacts suite à modification
• Notifications et alertes sur les exigences à (re)valider