Leçons tirées de la gestion des exigences : le programme de sous-marin S-80

Le programme de sous-marins S-80 nous montre pourquoi les exigences, les contraintes, les modifications de conception et les vérifications de validation doivent rester connectées dans les projets de développement de produits matériels.

Dans le développement de produits matériels, une modification de conception peut résoudre le problème immédiat tout en soulevant de nouvelles questions ailleurs dans le système. C’est pourquoi la gestion des exigences ne consiste pas seulement à consigner ce que le produit doit faire, mais aussi à garder visibles les contraintes associées, les décisions de conception et les vérifications de validation à mesure que la conception évolue.

Le programme de sous-marins S-80 de l’Espagne illustre clairement ce schéma. Au cours du développement, le programme a rencontré un important problème de poids et de flottabilité. La refonte a permis de traiter ce problème, mais les dimensions mises à jour du navire ont introduit un nouveau problème pratique : le sous-marin était désormais trop long pour le port qu’il devait utiliser.

Voici une leçon transposable à toutes les équipes qui développent des produits matériels, qu’il s’agisse d’un sous-marin ou d’un appareil électronique : lorsque les exigences, les contraintes, les modifications de conception et les vérifications de validation sont déconnectées, les équipes ont du mal à voir quels autres éléments une modification peut affecter.

Points clés à retenir

• Conflits d’exigences apparaissent souvent lorsque des contraintes critiques se trouvent en dehors du flux de travail utilisé pour examiner les modifications de conception.
• Les équipes peuvent réduire ce risque en reliant les exigences aux contraintes, aux décisions de conception et aux vérifications de validation qu’elles affectent.
• Un flux de travail d’exigences connecté permet plus facilement de voir ce qui a changé, ce que cela affecte et ce qui doit être revu avant que les reprises ne deviennent coûteuses.

Ce qui s’est passé dans le programme S-80

L’Espagne a lancé le programme S-80 pour développer une nouvelle classe de sous-marins. Au cours du développement, le programme a été confronté à un sérieux problème de poids et de flottabilité. Le navire était devenu plus lourd que prévu, ce qui a soulevé des inquiétudes quant à sa marge de flottabilité suffisante pour refaire surface de manière fiable après une plongée.

La conception a été révisée pour résoudre ce problème. L’un des changements clés a été l’allongement de la coque, ce qui a contribué à rétablir la marge de flottabilité nécessaire. Cette révision a également modifié les dimensions physiques du navire. Le sous-marin mis à jour a alors dû être examiné au regard des infrastructures dans lesquelles il devait opérer, et cet examen a révélé un problème pratique : il ne pouvait plus entrer dans le port.

Le problème d’infrastructure a ajouté une couche de travail supplémentaire à un programme qui avait déjà nécessité une refonte majeure. Le programme est finalement devenu plus complexe, a pris plus de temps et a coûté plus cher que prévu à l’origine.

Cette illustration rappelle que toute refonte laisse encore une question à résoudre : qu’est-ce qui doit désormais être vérifié en plus ?

Ce que les équipes hardware peuvent apprendre du cas S-80

La plupart des équipes hardware travaillent à une échelle plus réduite qu’un programme de sous-marins, mais le même schéma peut apparaître dans le développement quotidien de produits : une modification de conception peut affecter la taille, les exigences de conformité ou les contraintes d’interface au-delà du problème que l’équipe essaie actuellement de résoudre.

Connaître ces contraintes ne suffit pas. C’est là que la gestion des exigences compte : elle aide les équipes à les garder visibles, connectées et révisables à mesure que la conception évolue. Pour les équipes hardware, cela se résume à trois pratiques concrètes :

Rendre visibles les contraintes critiques

Les contraintes critiques ne devraient pas exister uniquement dans des notes de réunion, des feuilles de calcul ou dans la mémoire de quelqu’un. Elles devraient être consignées clairement et, lorsque c’est possible, formulées en termes mesurables afin que les équipes puissent les vérifier à mesure que la conception change.

Relier les exigences aux décisions de conception

Une exigence est plus utile lorsqu’elle est liée à la zone système, au bloc, à l’objet de conception ou à l’activité d’ingénierie qu’elle affecte. Cette connexion aide les ingénieurs à comprendre pourquoi une décision de conception est importante, quelles exigences elle soutient et quels autres éléments peuvent être affectés lorsque la conception change.

Utiliser la traçabilité pour examiner l’impact des changements

La traçabilité aide les équipes à répondre à une question pratique : qu’est-ce que cette modification affecte d’autre ? Lorsque les exigences restent liées aux décisions de conception, aux contraintes, aux vérifications de validation et aux preuves, les équipes peuvent voir ce qui a changé, ce qui est encore couvert et ce qui doit être revu avant que les reprises ne deviennent coûteuses.

Comment un flux de travail d’exigences connecté aide

Les équipes hardware ont besoin de plus qu’un simple endroit pour stocker le texte des exigences. Les documents et les feuilles de calcul peuvent consigner les exigences, mais ils deviennent plus difficiles à gérer à mesure que la complexité du projet augmente et que chaque exigence doit rester connectée tout au long de la chaîne d’ingénierie.

Altium Requirements Portal est conçu pour prendre en charge ce flux de travail en gérant les exigences, la traçabilité, les responsabilités et la validation dans un environnement partagé unique. Au lieu de traiter les exigences comme du texte isolé, les équipes peuvent voir ce qui a changé, ce que cela affecte, à qui appartient l’étape suivante et comment l’exigence sera vérifiée.

Quel est le « sous-marin » de votre projet ?

Chaque projet de développement hardware comporte des contraintes faciles à manquer lorsque la conception évolue rapidement. Elles peuvent être mécaniques, électriques, réglementaires, opérationnelles ou liées aux processus. Le risque n’est pas que les équipes manquent de connaissances, mais que des connaissances importantes ne soient pas toujours consignées, connectées et examinées lorsque la conception change.

C’est ce qui rend le cas S-80 utile au-delà de son échelle. Le même schéma peut apparaître dans le développement quotidien de produits lorsque l’intention d’ingénierie, les décisions de conception et les preuves ne restent pas connectées dans le temps.

Facilitez la traçabilité de l’impact des changements grâce à un outil de gestion des exigences accessible à toute votre équipe.

Commencer avec Requirements Portal →

Questions fréquentes

Quelles sont les causes des problèmes de gestion des exigences dans les projets hardware ?

Les problèmes de gestion des exigences apparaissent souvent lorsque les exigences ne sont pas reliées au travail de conception, aux contraintes et aux vérifications de validation qu’elles affectent. Une exigence peut exister, mais si l’équipe ne peut pas voir à quoi elle est connectée, des impacts importants peuvent être manqués lorsque la conception change.

Pourquoi les feuilles de calcul deviennent-elles difficiles à utiliser pour la gestion des exigences ?

Les feuilles de calcul peuvent consigner le texte des exigences, mais elles deviennent plus difficiles à gérer à mesure que la complexité du projet augmente. Les équipes ont besoin d’un moyen de garder les exigences connectées au travail de conception, à l’historique des changements, au statut de validation et aux preuves tout au long de la chaîne d’ingénierie.

Comment la traçabilité aide-t-elle à réduire les reprises tardives ?

La traçabilité aide les équipes à répondre à une question pratique : qu’est-ce que cette modification affecte d’autre ? En reliant les exigences aux décisions de conception, aux contraintes, aux vérifications de validation et aux preuves, les équipes peuvent voir ce qui doit être examiné avant que les reprises ne deviennent coûteuses.