Ingénierie des exigences et traçabilité

L'ingénierie des exigences est la discipline qui transforme objectifs, contraintes, réglementations et besoins des parties prenantes en une base technique maîtrisée pour la conception, la vérification, la validation et la certification.

Pour les systèmes complexes, la principale difficulté consiste rarement à rédiger des exigences individuelles. Elle est de maintenir dans le temps la cohérence entre des milliers d'exigences, d'interfaces, de modifications, d'essais, de documents et d'obligations externes.

La traçabilité n'est donc pas une surcharge administrative. Elle fait partie de l'architecture technique du projet.

Les exigences peuvent provenir de plusieurs niveaux :

• besoins client ;
• spécifications système et sous-système ;
• analyses de sécurité ;
• scénarios d'exploitation ;
• définitions d'interface ;
• normes et réglementations ;
• exigences de certification ;
• contraintes fournisseurs ;
• décisions de conception ;
• enseignements issus de la validation et de l'exploitation.

Ces sources ont des autorités et des processus de mise à jour différents.

Une baseline d'exigences utile doit préserver cette distinction.

Une exigence devrait être :

• nécessaire ;
• non ambiguë ;
• vérifiable ;
• cohérente avec les exigences liées ;
• suffisamment précise pour son niveau ;
• rattachable à une source ;
• allouée au bon niveau système.

Une affirmation peut être techniquement plausible et néanmoins constituer une mauvaise exigence si son critère d'acceptation est flou.

Des termes comme « suffisant », « approprié », « rapide » ou « robuste » nécessitent une interprétation explicite lorsqu'ils sont utilisés comme exigences contractuelles ou vérifiables.

La traçabilité relie les exigences aux artefacts d'ingénierie qui les justifient, les implémentent, les vérifient ou les contraignent.

Une chaîne typique est :

[ ext{source} ightarrow ext{exigence système} ightarrow ext{exigence sous-système} ightarrow ext{conception} ightarrow ext{vérification} ightarrow ext{preuve}.]

La traçabilité bidirectionnelle est importante.

Il doit être possible de répondre aux deux questions :

• Pourquoi cette exigence existe-t-elle ?
• Quelle preuve démontre qu'elle est satisfaite ?

Une matrice de traçabilité n'est utile que si les liens ont un sens et sont maintenus.

Les projets de certification introduisent une couche supplémentaire d'exigences.

Les textes réglementaires contiennent des obligations qui doivent être interprétées et rattachées à l'architecture du projet.

Le travail d'ingénierie ne consiste pas simplement à copier des paragraphes réglementaires dans une base de données.

Il exige :

• d'identifier les clauses applicables ;
• d'interpréter leur intention technique ;
• de déterminer leur applicabilité au projet ;
• d'allouer les obligations aux systèmes ou documents ;
• de les relier aux exigences projet ;
• d'identifier les preuves de conformité attendues ;
• de maîtriser les écarts et points ouverts.

Pour les projets ferroviaires, cela peut inclure les Spécifications techniques d'interopérabilité (STI), les règles techniques nationales françaises et les exigences convenues avec les organismes d'évaluation de conformité et l'exploitant.

IBM DOORS est couramment utilisé pour gérer des ensembles d'exigences maîtrisés et leur traçabilité.

Les tâches d'ingénierie typiques comprennent :

• importer et structurer des modules d'exigences ;
• définir les attributs ;
• relier les exigences entre niveaux ;
• maintenir les baselines ;
• suivre les changements ;
• filtrer par applicabilité ou état ;
• extraire des ensembles de revue ;
• comparer les exigences externes aux exigences projet.

L'outil est utile parce qu'il préserve structure et traçabilité, mais la qualité du résultat dépend toujours du modèle d'ingénierie sous-jacent à la base de données.

Une base remplie de liens n'est pas automatiquement un système traçable.

Un problème récurrent consiste à vérifier qu'un ensemble d'exigences projet couvre correctement une source réglementaire ou contractuelle externe.

Un flux de comparaison utile peut comprendre :

1. normalisation des exigences externes ;
2. identification des exigences projet candidates ;
3. comparaison du texte et de l'intention technique ;
4. classification de la couverture ;
5. revue des correspondances absentes ou ambiguës ;
6. conservation du résultat comme preuve auditable.

Les états de couverture possibles comprennent :

• couvert ;
• partiellement couvert ;
• non couvert ;
• non applicable ;
• couvert indirectement ;
• clarification nécessaire.

Les catégories doivent être définies avant d'introduire l'automatisation.

Python peut réduire le coût manuel de l'analyse d'exigences.

Les automatisations utiles comprennent :

• extraction de données d'exigences structurées ;
• normalisation des identifiants et du texte ;
• détection des doublons ;
• comparaison des révisions ;
• vérification des liens manquants ;
• génération de tableaux de revue ;
• identification de changements suspects ;
• préparation de rapports ;
• présélection de correspondances candidates.

L'automatisation doit soutenir le jugement d'ingénierie plutôt que le remplacer silencieusement.

Un score de similarité sémantique, par exemple, peut identifier des correspondances candidates. Il ne peut pas à lui seul démontrer une conformité réglementaire.

Les exigences ne sont pas statiques.

Une modification peut affecter :

• les exigences aval ;
• les interfaces ;
• les hypothèses de conception ;
• les procédures de vérification ;
• les résultats d'essais ;
• les preuves de certification ;
• les engagements fournisseurs.

L'impact d'une modification dépend donc du graphe de traçabilité.

Un processus robuste de changement doit identifier les artefacts affectés avant l'acceptation de la nouvelle baseline.

Une baseline définit un état projet maîtrisé.

Sans baseline, une affirmation comme « l'exigence a été vérifiée » est ambiguë, car l'exigence peut avoir changé après l'essai.

Chaque preuve doit pouvoir être interprétée relativement à une version connue de :

• l'exigence ;
• la configuration système ;
• la procédure d'essai ;
• le logiciel ou matériel soumis à l'essai ;
• la référence externe applicable.

La gestion de versions est donc aussi importante pour les exigences et les preuves que pour le logiciel.

De nombreuses défaillances système sont des défaillances d'interface.

L'ingénierie des exigences doit rendre les interfaces explicites :

• interfaces physiques ;
• interfaces électriques ;
• interfaces de communication ;
• interfaces fonctionnelles ;
• interfaces organisationnelles.

Une exigence d'interface doit préciser non seulement ce qui traverse la frontière, mais aussi les hypothèses formulées par les deux côtés.

Cela devient particulièrement important lorsque plusieurs organisations développent des parties différentes du système.

Une exigence devrait normalement disposer d'une méthode de vérification prévue.

Les méthodes courantes comprennent :

• essai ;
• analyse ;
• inspection ;
• démonstration ;
• revue des preuves de conception.

La méthode de vérification doit être compatible avec la formulation de l'exigence.

Une exigence qui ne peut être vérifiée au moyen de la preuve proposée devrait être retravaillée avant la fin du projet.

La couverture des exigences n'est pas équivalente à des essais réussis.

Une vue complète des preuves pose les questions suivantes :

• Chaque exigence applicable est-elle reliée à une preuve ?
• La preuve est-elle valable pour la configuration actuelle ?
• La preuve teste-t-elle ou démontre-t-elle réellement l'exigence ?
• Les écarts sont-ils clos ?
• Les hypothèses sont-elles explicites ?
• Les preuves héritées ou externes sont-elles maîtrisées ?

Les métriques de couverture sont utiles pour les contrôles de complétude, mais ne peuvent pas déterminer l'adéquation technique.

La revue indépendante reste essentielle.

Les questions utiles comprennent :

• L'exigence source est-elle correctement interprétée ?
• L'applicabilité est-elle justifiée ?
• L'exigence projet est-elle équivalente dans son intention ?
• La preuve est-elle suffisante ?
• La configuration est-elle maîtrisée ?
• Un écart est-il masqué derrière un champ d'état ?
• Une exigence a-t-elle été marquée terminée uniquement parce qu'un lien existe ?

Ces questions ne peuvent pas être réduites à des contrôles de cohérence de base de données.

Un flux d'analyse des exigences devrait être reproductible.

Pour un traitement automatisé, cela signifie conserver :

• les exports d'entrée ;
• les scripts ;
• la configuration ;
• les règles de correspondance ;
• les rapports de sortie ;
• les décisions de revue ;
• les horodatages ou identifiants de baseline.

L'objectif est de rendre une analyse révisable des mois ou des années plus tard, pas seulement répétable aujourd'hui sur le poste de l'ingénieur.

Les principaux principes que j'applique sont :

• préserver la source et l'autorité de chaque exigence ;
• rendre l'applicabilité explicite ;
• maintenir une traçabilité bidirectionnelle ;
• distinguer similarité textuelle et équivalence technique ;
• relier les preuves à des baselines maîtrisées ;
• automatiser les contrôles de complétude avant l'interprétation ;
• préserver la revue humaine pour le jugement technique ;
• traiter les changements comme des impacts à l'échelle du graphe plutôt que comme des modifications isolées ;
• rendre chaque conclusion de conformité auditable.