Qu'est-ce qu'une matrice de traçabilité des exigences, et pourquoi la NASA en exige six liens à l'intérieur ?

Chiffres tirés de SWE-052 — Bidirectional Traceability, NASA Software Engineering Handbook (NPR 7150.2). Pour un logiciel de classe A, B et C, le responsable du projet doit enregistrer et maintenir une traçabilité bidirectionnelle sur six relations : exigences de niveau supérieur vers exigences logicielles, exigences vers dangers système, exigences vers composants de conception, composants de conception vers code, exigences vers les vérifications du logiciel et exigences vers non-conformités.

Ce que contient une RTM

Une ligne par exigence, une colonne par élément auquel cette exigence se rattache. Les projets varient, mais un jeu de colonnes qui fonctionne ressemble à ceci :

• Identifiant — un identifiant qui survit aux réorganisations. On y revient plus bas.
• Texte de l'exigence, ou une version courte.
• Origine — l'exigence client, la clause ou la réglementation dont elle descend.
• Élément de conception — le composant qui l'implémente.
• Cas de test — la vérification qui prouve que ça marche.
• Statut — où en est ce lien aujourd'hui.

Les projets de sécurité fonctionnelle y ajoutent en général le danger que l'exigence maîtrise, un niveau de criticité comme un ASIL ou un DAL, et la baseline dans laquelle elle a été figée. On croise aussi les appellations matrice de traçabilité, matrice des exigences ou simplement RTM : trois autres noms pour la même chose.

Avant, arrière, bidirectionnelle

Trois termes employés indifféremment alors qu'ils ne le sont pas. La différence décide de ce que votre matrice peut ou ne peut pas vous dire. Changez de sens et regardez quels liens s'allument.

Une RTM de quatre lignes

Voici une matrice de quatre exigences. Coupez un lien de vérification et regardez ce que la matrice a à en dire : c'est tout le travail d'une RTM, ramené à un tableau assez petit pour être vu d'un coup d'œil.

La difficulté d'une RTM n'est ni dans le nombre d'exigences ni dans celui des liens : les deux croissent de pair. Elle est dans l'analyse d'impact. Quand une exigence du haut change, ce qu'il faut revoir se propage de niveau en niveau, et ce compte-là grimpe vite. C'est par là que cela cesse d'être une tâche documentaire, en général vers la deuxième baseline.

Ce que chaque norme exige exactement

« La norme exige de la traçabilité » est vrai et presque inutile. Ce qui change d'une norme à l'autre, c'est la profondeur de la preuve et le document dans lequel elle atterrit. Choisissez celle qui s'applique à vous.

Un détail utile si plusieurs normes vous concernent. ISO 26262 et Automotive SPICE exigent toutes deux la traçabilité bidirectionnelle, et sur l'axe central — exigences, conception, tests — les liens se réutilisent. Mais ils ne se recouvrent pas aux extrémités : Automotive SPICE ne traite ni l'analyse de dangers ni les ASIL, et ISO 26262 ne demande pas de tracer les exigences qui ne relèvent pas de la sécurité. Une seule infrastructure, oui ; un seul jeu de liens, non. Les confondre, c'est arriver à l'un des deux audits avec la moitié qui manque.

Là où le tableur cesse de suffire

Presque tous les projets démarrent leur RTM dans un tableur, et pour un premier prototype c'est une décision parfaitement raisonnable. Personne n'achète un outil d'exigences pour en gérer quarante. Le mode de défaillance, lui, est prévisible, et il arrive toujours dans le même ordre.

L'identifiant dérive

Dans un tableur, une exigence est une ligne. Insérez-en une au-dessus et toute référence croisée qui pointait vers « la ligne 47 » pointe désormais ailleurs. Les équipes contournent avec une colonne d'identifiants saisie à la main, ce qui tient jusqu'au jour où deux personnes modifient le fichier le même après-midi et où l'une des deux gagne.

Personne ne sait ce qu'un changement a invalidé

Le client modifie une exigence de haut niveau. Quelles exigences logicielles deviennent douteuses ? Quels tests ne valent plus ? Un tableur ne peut pas répondre, parce que le lien est du texte et non une relation. Quelqu'un devra le déduire en lisant, et il le fera la semaine avant la livraison, c'est-à-dire au moment où l'on lit le plus vite et le plus mal.

La matrice est une photo, pas un état

La RTM rangée dans le dossier était vraie le jour de son export. Qu'elle le soit encore aujourd'hui relève de la foi. Les auditeurs ont appris à demander quand elle a été générée et à partir de quoi : La question est polie ; la réponse, pas toujours.

Ce que change un outil de gestion des exigences

Les organisations ne passent pas à un outil de gestion des exigences parce qu'il dessine une plus jolie matrice. Elles y passent parce que la matrice cesse d'être un document que quelqu'un maintient pour devenir une vue générée à la demande à partir de liens qui existent déjà.

Dans IBM DOORS, chaque exigence est un objet doté d'un numéro absolu qui ne change jamais. À savoir dès le début : la numérotation hiérarchique affichée à l'écran (1.1, 1.2) se renumérote bel et bien quand on insère au-dessus, exactement comme dans un tableur. Ce qui ne bouge pas, c'est le numéro absolu, et c'est lui qu'il faut référencer. Les liens entre modules sont de vraies relations et non du texte saisi, si bien que la couverture se calcule au lieu de se compiler. Et lorsqu'une exigence source change, les liens situés en dessous sont automatiquement marqués comme suspects : l'outil vous dit quoi revoir au lieu d'attendre que quelqu'un s'en aperçoive.

La différence se voit le jour de l'audit. Produire la matrice passe d'une semaine de la vie de quelqu'un à un rapport que l'on exécute, et ce rapport peut être automatisé, et la réponse à « quand cela a-t-il été généré ? » devient « à l'instant, à partir de la baseline que vous regardez ».

Cinq façons de se tromper

• Ne tracer que vers l'avant. C'est la moitié de l'exigence, et celle à laquelle un auditeur se fie le moins.
• Une seule matrice pour tout le programme. Découpez par sous-système ou par baseline. Personne ne lit un tableau de quatre mille lignes, à commencer par celui qui l'a fait.
• Lier vers des documents plutôt que vers des exigences. « Voir le paragraphe 4.2 » est une référence, pas de la traçabilité. Cela ne survit pas à la première réorganisation du document.
• Un statut en texte libre. Si « Fait », « fait » et « OK » cohabitent dans la même colonne, la matrice ne se filtre plus, et une matrice qu'on ne peut pas filtrer est une matrice que personne n'utilise.
• La construire à la fin. Une RTM montée le mois avant la certification documente ce qui s'est passé. Une RTM tenue depuis le début change ce qui se passe.

Questions fréquentes