Traçabilité des exigences

L’ingénierie des exigences qui regroupe toutes les activités liées à l’identification, au suivi, à la gestion de l’évolution des exigences d’un projet a d’abord été déployée dans le domaine logiciel et se déploie aujourd’hui dans les sociétés produisant des systèmes matériels complexes. L’exemple qui peut être pris est celui de PSA Peugeot-Citroën qui a mis en place très récemment, depuis le milieu de l’année 1999, la première équipe d’ingénierie système [9]. Cette équipe a contribué à déployer un premier processus d’ingénierie des exigences.

Les outils d’ingénierie système s’inscrivent dans le contexte de cycle de développement en V, dans lequel, dans un premier temps les exigences sont identifiées et suivies dans la branche descendante du V, puis sont intégrées au traitement de la branche ascendante. Le principe de base de la traçabilité est d’établir des liens entre toutes les étapes de conception, ce qui correspond souvent à établir des liens inter documents et à vérifier la cohérence des exigences ou à valider un modèle à tous les stades de développement d’un projet. Le but est de garder une cohérence claire et directe entre les exigences spécifiées et les représentations du système.

D’une manière générale, les outils de traçabilité ont les fonctions suivantes : • créer des liens inter documents,

• extraire des informations filtrées des documents texte (à l’aide de mots clefs contenu dans un lexique),

• éditer un nouveau document texte « spécialisé » (après un filtrage adapté),

• paramétrer l’état d’une exigence pour accéder à un suivi temporel de son implémentation (exemple de noms d’états associés à un lexique : en analyse, en négociation, en reformulation, référent, obsolète),

• visualiser une matrice d’impact, • visualiser une matrice de conformité, • visualiser une matrice de vérification.

La traçabilité permet de suivre une exigence formulée sur un cahier des charges tout au long d’un projet. Les outils de traçabilité actuels sont orientés « texte » et sont efficaces sur des documents textuels. Ils consistent à faire des liens entre des zones de textes marquées, ou des liens entre des zones de texte et des images, des graphiques, ou des tableaux qui illustrent un élément des spécifications. Il faut impérativement avoir une structuration claire du document pour faciliter l’indexation semi-automatique du document et la recherche de champs du document.

La Figure 2-7 illustre l’exemple d’un élément X que l’on retrouve dans 3 documents édités au cours d’un projet : le cahier des charges, la description du prototype et les procédures de tests. Ces 3 documents sont représentatifs de la structure en « V » du cycle de développement. Les liens sont ici représentés par des flèches bidirectionnelles. Le marquage de l’élément X est réalisé par le biais de « drapeaux » déposés à l’endroit voulu par le concepteur après l’analyse fine du texte. La plupart des outils du commerce utilisent le langage XML (eXtensive Markup Language) comme moyen d’établir ces liens.

1 --- 2 --- 2.2 --- 2.3 --- 3 --- • --- • --- • --- • --- • --- • ---- • ---- • ---- • --- • --- • ---- •--- • --- • ---- • ---- • ---- • ---- • ---- • --- • --- • ---- •--- • --- • ---- • ----

Cahier des Charges Fonctionnel Procédures de Test

Description du Prototype Virtuel

Figure 2-7 : Traçabilité obtenue par le biais de liens qui pointent un même élément X sur plusieurs documents.

Au delà de ce simple lien, la traçabilité des exigences permet de répondre à des questions telles que :

• Quels sont les constituants concernés en cas de modification d’exigences du client ? • Quelles exigences systèmes sont mises en cause par un changement technique ou une

non-conformité d’un constituant ?

Lorsqu’une modification de spécification du système a lieu, ces outils de traçabilité permettent de faire apparaître les correspondances relatives, l’impact de ce changement d’exigence sur les autres documents du projet qui décrivent le système. Cette caractéristique permet d’envisager

efficacement la réutilisation d’une partie ou de la totalité des spécifications déjà écrites dans de nouveaux projets et de fait de garder les liens vers d’autres dossiers de documentation associés.

Dans le cadre de notre projet, nous avons mis en œuvre ces considérations sur 3 documents à l’aide de l’outil DOORS [10] : le cahier des charges fonctionnel, le document de conception, et le code VHDL-AMS du prototype virtuel. Cet outil est à rapprocher de ses concurrents : Requisite- Pro [11] et IRqA [12], qui aident aussi à la gestion des exigences. Nous avons choisi DOORS pour une raison de facilité d’accès à EDF R&D. Il joue un rôle de pointeur d’exigences et établit des liens entre plusieurs documents qui instaurent, complètent, vérifient, ou définissent les exigences des spécifications d’un système. DOORS est le noyau qui permet de lier tous ces documents qui sont créés au cours d’un cycle de développement pour établir, à tout moment du projet, une matrice des liens d’interdépendances. Cet outil a toutes les fonctions des outils de traçabilité décrites en début de section.

Ces 3 documents se situent aux extrémités des branches du cycle de développement en V. Ils cernent ainsi la globalité du cycle. Avant d’utiliser un outil de traçabilité, le concepteur ou l’ingénieur système doit procéder à une phase d’analyse qui consiste à indexer chaque paragraphe pertinent d’un document afin de pouvoir ensuite les différencier et les classer par catégories. L’ingénieur est libre de créer les catégories qui sont pertinentes et qui correspondent au métier propre à chaque exigence. La liste des catégories formera un lexique que le concepteur et les autres intervenants utiliseront tout au long du projet.

Prenons dans un premier temps, l’exemple de l’analyse faite sur notre cahier des charges. Nous avons choisi de classer les lignes de texte par les catégories suivantes (visibles sur la colonne de droite de la Figure 2-8) :

• Fonction. • Contrainte. • Description.

• Méthodes d’évaluation.

• Critères d’acceptation.

Figure 2-8 : Vue du cahier des charges et du classement des lignes indexées par catégories.

Si nous choisissons par exemple la catégorie « Méthodes d’évaluation » comme filtre : nous voyons apparaître uniquement les méthodes d’évaluation car toutes les lignes n’appartenant pas dans cette catégorie sont cachées. Cet exemple est simple mais il permet de montrer l’efficacité de la méthode. Nous voyons ici l’intérêt direct que peut avoir la génération d’un document texte. Par ce biais, nous obtenons un document allégé qui contient toutes les procédures de test et qui pourra être utilisé dans la phase d’intégration finale.

Le document suivant (Figure 2-9) que nous avons analysé sous DOORS est le document de

conception. Il fait apparaître les fonctions qui sont modélisées par des blocs sous HiLeS. Chaque

fonction satisfait une exigence particulière du cahier des charges. Ainsi, chaque bloc représenté sous HiLeS a été lié à une exigence fonctionnelle. Le lien est bidirectionnel, ce qui nous permet de

naviguer d’une représentation à l’autre en gardant une trace des spécificités de chaque bloc. Le suivi de l’impact est double : descendant (top-down) lorsqu’une modification des spécifications provoque une modification du système, et à l’inverse ascendant (bottom-up) lorsqu’une modification touche directement un constituant du système, nous pouvons remonter aux spécifications globales du système. Nous avons ajouté une propriété supplémentaire qui est d’indiquer les liens inter-blocs. La Figure 2-9 fait apparaître, dans la fenêtre grisée, les liens du bloc considéré avec les autres blocs : le bloc « Measure treatment » est connecté aux blocs « Transceiver », « Sensor test », et « Power ».

Figure 2-9 : Liens établis entre la description HiLeS et les exigences du cahier des charges.

Nous avons ensuite utilisé la matrice de traçabilité pour avoir une représentation des liens inter blocs, présentés sur la Figure 2-10. Les carrés gris foncés marquent la ligne et la colonne relative aux éléments sélectionnés. Les carrés noirs désignent l’existence d’un lien entre deux éléments.

Ainsi, nous visualisons les connexions entre le bloc « Measure treatment » et les blocs

« Transceiver », « Sensor test », et « Power ».

Figure 2-10 : Matrice de traçabilité entre les blocs HiLeS et les exigences du cahier des charges.

Le troisième document que nous voulons analyser est le document qui regroupe les codes VHDL-AMS du prototype virtuel. Nous y avons établi des liens de correspondance avec les deux documents précédents (cahier des charges et document de conception).

Nous avons démontré la faisabilité de la mise en place d’un processus de traçabilité qui permet de garantir la cohérence de la description du système, des spécifications au prototype virtuel. Nous avons franchi deux transitions successives pour arriver au prototype virtuel du système : le passage du cahier des charges au document de conception, et puis le passage du document de conception au code VHDL-AMS. Cet outil nous permet une première vérification relative à la cohérence de nos documents (Figure 2-11). Le défaut majeur de cette méthode est de faire reposer l’analyse sur des documents textes. Cependant, d’une manière générale, les codes informatiques évoluent rapidement et sont sujets à des modifications ou à des améliorations successives. Ici, il a fallu regrouper dans un document texte unique les codes VHDL-AMS, document qui devenait figé une fois édité. Tout l’intérêt de la flexibilité de la démarche est alors de fait diminué. Nous préconisons le pointage direct vers le fichier source, répertorié dans une bibliothèque appropriée.

Figure 2-11 : Vue schématique de notre approche de conception.

Nous avons vu que pour éviter au maximum l’ambiguïté d’un cahier des charges rédigé en langage naturel, il convient de suivre une structure et des règles de présentation. Ceci n’est pas encore suffisant pour établir un moyen d’analyse fiable facilitant le passage vers une représentation formelle pour une première vérification. Il convient alors d’utiliser une représentation semi-formelle qui puisse atteindre les buts suivants :

• Aider l’analyse des diverses représentations du système selon la bonne abstraction, • Faciliter la traduction en modèles HiLeS.

Nous aborderons ce point dans le paragraphe suivant.