Exigences & architecture

Traçabilité des exigences : du besoin au composant, et retour

Exigences & architecture · Publié le 2026-10-09

La traçabilité des exigences consiste à relier chaque exigence à ce dont elle provient et à ce qui en découle : le besoin d'origine, les exigences de niveau inférieur, les éléments d'architecture qui la satisfont, les essais qui la vérifient. Sans ces liens, on ne sait ni pourquoi un composant a été conçu ainsi, ni ce que casse une modification. Avec eux, on peut répondre à ces questions en quelques minutes.

Pourquoi tracer ?

La traçabilité répond à trois besoins distincts, qui justifient chacun l'effort qu'elle demande :

• La justification : chaque exigence de bas niveau, chaque choix de conception, doit pouvoir être relié à un besoin. Une exigence orpheline est soit inutile, soit le signe d'un besoin non documenté.
• La couverture : chaque besoin doit être décliné jusqu'aux composants qui le réalisent, et chaque exigence doit être vérifiée. Les trous de couverture sont les défauts les plus coûteux, car on les découvre tard.
• L'analyse d'impact : quand une exigence change, quand un composant est remplacé, quand un essai échoue, les liens permettent de savoir immédiatement ce qui est concerné.

Dans les secteurs réglementés, la traçabilité est en outre une attente explicite des référentiels de certification. Les recommandations de l'aéronautique pour le développement des systèmes, ou les normes de sûreté de fonctionnement du ferroviaire et de l'automobile, demandent de démontrer le lien entre exigences de sécurité, conception et vérification.

Les types de liens

Un lien de traçabilité n'est utile que si sa signification est claire. Les relations définies par SysML pour les exigences offrent un vocabulaire partagé :

À ces relations s'ajoute l'allocation, qui relie des fonctions à des composants et, par transitivité, permet de savoir quelles exigences fonctionnelles portent sur quel élément physique. Ce mécanisme est au cœur du passage entre architectures fonctionnelle, logique et physique.

La chaîne complète

Une traçabilité de bout en bout suit le cycle de vie, dans les deux sens :

1. Besoin d'une partie prenante (par exemple, un exploitant qui demande une disponibilité donnée).
2. Exigence système, formulée en termes techniques et vérifiables.
3. Exigences dérivées, allouées aux sous-systèmes lors de la conception de l'architecture.
4. Éléments de conception (blocs, logiciels, interfaces) qui satisfont ces exigences.
5. Cas de vérification (essais, analyses, inspections) qui démontrent la satisfaction.
6. Résultats de vérification, rattachés à une configuration identifiée du système.

La traçabilité descendante répond à la question « ce besoin est-il couvert ? ». La traçabilité ascendante répond à « pourquoi ce composant, cette fonction, cet essai existent-ils ? ». Les deux sont nécessaires.

Matrices, modèles et outils

La forme la plus ancienne de la traçabilité est la matrice : un tableau croisant exigences et éléments de conception ou cas de test. Elle reste un excellent outil de revue, à condition d'être générée et non saisie à la main. Une matrice tenue manuellement dans un tableur se dégrade très vite : une ligne ajoutée ici, une colonne oubliée là, et plus personne ne lui fait confiance.

Dans une démarche basée sur les modèles, les liens sont des éléments du modèle. Les matrices, les tableaux de couverture et les rapports d'impact sont produits à la demande. Les exigences peuvent aussi vivre dans un outil de gestion des exigences distinct du modeleur ; l'échange entre outils passe alors par des formats comme ReqIF, la spécification d'échange d'exigences de l'Object Management Group, dont la version 1.2 date de 2016.

Exploiter la traçabilité

Une traçabilité bien tenue permet des analyses que les revues manuelles ne font pas :

• Exigences sans élément satisfaisant : un trou de conception.
• Exigences sans cas de vérification : un trou dans le plan de vérification.
• Éléments de conception sans exigence : une fonctionnalité non demandée, ou un besoin non documenté.
• Analyse d'impact : la liste des exigences, composants et essais touchés par une modification proposée, à présenter en comité de changement.
• Suivi de l'avancement : la part des exigences vérifiées, par sous-système et par jalon.

Ces indicateurs n'ont de valeur que si les liens sont justes. La revue des liens, et pas seulement des exigences, doit faire partie des revues de conception.

Les pièges

Trois dérives reviennent souvent. La première est la sur-traçabilité : relier tout à tout, « au cas où », jusqu'à ce que les liens ne signifient plus rien. La deuxième est la traçabilité de fin de projet, reconstituée juste avant un audit : elle coûte cher et ne sert à rien pendant le développement, là où elle aurait été utile. La troisième est l'oubli de la gestion de configuration : un lien entre une exigence et un essai n'a de sens que si l'on sait à quelle version de l'exigence, de la conception et du produit il se rapporte.

La qualité de la traçabilité dépend enfin de celle des exigences elles-mêmes : une exigence composite, qui contient deux besoins, ne peut pas être tracée proprement. Les règles de rédaction présentées dans notre article écrire une bonne exigence sont donc un préalable. Et c'est la vérification qui ferme la boucle.

À lire ensuite

Plus dans Exigences & architecture

Exigences & architecture

Écrire une bonne exigence

Les qualités attendues, des gabarits de phrase, des exemples réécrits et les pièges à éviter.

Exigences & architecture

Vérification et validation

« Le produit est-il bien fait ? » et « est-ce le bon produit ? » : deux questions, deux démarches.

Exigences & architecture

Fonctionnelle, logique, physique

Trois vues d'un même système, l'allocation qui les relie, et la manière d'arbitrer entre architectures.