Deux des tâches les plus importantes de l'ingénierie système consistent sans doute à comprendre les besoins des parties prenantes et à les traduire en exigences du système. Ce livre blanc traite de l’application précoce de la modélisation pour réaliser ces tâches, en démontrant des techniques de modélisation de plus en plus sophistiquées et utiles, allant de modèles purement descriptifs à des preuves formelles. L'amélioration de la qualité des exigences des systèmes justifie à elle seule l'investissement dans ces techniques, mais les modèles qui en résultent peuvent également être utilisés à des stades ultérieurs du projet pour représenter plus efficacement les besoins des parties prenantes. Nous montrons comment les modèles d'exigences peuvent être utilisés pour obtenir des exigences de système cohérentes et complètes. La figure 1 illustre le processus suivi dans ce document pour obtenir ces avantages.
Pour cette étude de cas, les exigences seront déduites, pour un système de refroidissement de machine, sur la base des besoins des parties prenantes décrits ci-dessous :
Fournir un système qui maintient la température de fonctionnement d'une machine, évitant ainsi qu’elle soit endommagée par une surchauffe.
- [contrainte] Le système de refroidissement doit maintenir une température de fonctionnement inférieure à 40 ˚C.
- [contrainte] Le refroidissement doit être efficace dans un intervalle de temps prédéterminé.
- [postulat] La température ambiante est supérieure à -10˚ C et inférieure à 80˚ C.

Les besoins des parties prenantes sont ambigus et peuvent facilement être mal interprétés, ce qui peut entraîner des exigences système incomplètes et/ou incorrectes, et éventuellement aboutir à un design qui ne répond pas aux attentes des parties prenantes. Pour éviter cela, il est nécessaire de valider les besoins des parties prenantes.
Il existe des techniques de modélisation qui peuvent aider à valider notre compréhension des besoins des parties prenantes et à converger vers un ensemble d'exigences système. Ces méthodes comprennent l'utilisation de :
Nous allons décrire chacune de ces méthodes dans les sections suivantes et terminer par une réflexion sur l'utilisation d'un lien numérique pour établir la traçabilité entre les besoins des parties prenantes et les différents niveaux d'exigences dérivées.
Une première étape dans l'exploration des besoins des parties prenantes consiste à décrire les différents scénarios auxquels le système de refroidissement doit répondre. Par exemple, que doit-il se passer si la température est trop élevée ou si le refroidissement ne semble pas efficace ?
Les modèles d'exigences descriptifs constituent un progrès par rapport aux exigences traditionnelles en langage naturel, car ils fournissent une représentation graphique structurée des exigences, ce qui améliore la coopération entre les équipes impliquées. Un bon exemple d'une telle représentation serait un diagramme de séquence.
Qu'est-ce qu'un modèle descriptif ?
Un modèle descriptif est une spécification graphique d'un système qui décrit ce qu’est ou fait le système d'une manière lisible par l'homme.
La figure 2 décrit le scénario suivant : Si la température (T) est trop élevée (T>=40), un refroidissement est nécessaire ; si le refroidissement est efficace (T<40), le refroidissement doit être arrêté ; mais si le refroidissement n'est pas efficace (délai>=30), la machine doit être arrêtée.
Des diagrammes de séquence fournissent des descriptions graphiques de la manière dont les composants modélisés du système de refroidissement fonctionnent ensemble dans différents scénarios. Cependant, ces modèles d'exigences descriptifs sont plus spécifiquement utilisés dans le domaine de l'ingénierie, alors que les modèles d'exigences simulables (ou exécutables) peuvent produire des observations et des informations dans le domaine du système, permettant aux parties prenantes d'obtenir une compréhension directe des exigences dans le contexte propre à leur domaine. Un bon exemple de formalisme exécutable capable de produire ces résultats est un statechart (voir figure 3).
Qu'est-ce qu'un modèle de simulation ?
Un modèle de simulation est la spécification d'un système destiné à être interprété par une machine, les résultats de l'interprétation étant laissés à l'interprétation humaine pour en tirer des conclusions.
Ceci est important car la simulation fournit une interprétation sans ambiguïté de chaque scénario décrit dans les diagrammes de séquences précédents. Cela permet également de communiquer cette interprétation aux parties prenantes, d'explorer différents scénarios et de comprendre quels sont leurs besoins spécifiques, pour pouvoir décrire ces informations dans les exigences du système.
Maintenant que nous disposons d'un modèle qui simule les comportements spécifiés dans les diagrammes de séquence, nous pouvons observer les sorties générées par la machine à états et en discuter avec les parties prenantes. De plus, nous pouvons vérifier si le comportement de la machine à états est cohérent avec les scénarios décrits dans le diagramme de séquence. Dans la figure 4, les coches vertes dans le diagramme de séquence indiquent que les événements voulus se sont produits dans le bon ordre au cours de la simulation. Cela confirme que le comportement du modèle fonctionnel est correct. Ces résultats peuvent aussi être utilisés pour la validation avec les parties prenantes.
Bien que les techniques de simulation offrent une bonne représentation du comportement des systèmes, la simulation est généralement ciblée sur des scénarios clés pour supporter le travail collaboratif. Les modèles d’exigences formels, quant à eux, contiennent des formalismes qui permettent une évaluation plus systématique de la qualité du modèle.
L'un de ces formalismes est un tableau d’exigences qui peut être utilisé pour prouver formellement la cohérence et l'exhaustivité d'un ensemble d'exigences. Les exigences cohérentes n'entrent pas en conflit, tandis que les exigences complètes ne comportent aucune fonctionnalité manquante. Les colonnes de préconditions (A) de la figure 5 décrivent les entrées du système (valeurs de température) et le moment où une exigence est valide ou « active ». Les colonnes de postconditions (B) décrivent le comportement attendu lorsque l'exigence spécifiée est active.
Qu'est-ce qu'un modèle formel ?
Un modèle formel est la spécification d'un système destiné à être interprété par une machine, dont les résultats sont ensuite traités pour présenter des conclusions définitives destinées à l’utilisation humaine.
Par exemple, l'exigence n° 1 stipule que lorsque T est inférieure à 40˚ C (T<40), le système de refroidissement doit être arrêté (Turn_off_cooling == true
).
Une analyse utilisant les capacités de méthodes formelles de Simulink Design Verifier™ peut maintenant déterminer si les exigences sont cohérentes et complètes. Dans la figure 6, le scénario où la température est exactement de 40˚ C n'a pas été inclus et cet ensemble d'exigences est donc incomplet.
Test des modèles de design
Les modèles d'exigences formels constituent un bon point de départ pour les équipes en aval, à la fois parce que la qualité des exigences est plus élevée et parce que les éléments du modèle d'exigences peuvent être réutilisés lors du design, de la génération automatique de tests et de la vérification. Les modèles d'exigences peuvent être utilisés dans le cadre de tests unitaires pour s'assurer que les modèles fonctionnels sont développés pour répondre aux exigences. Ces tests unitaires peuvent être exécutés à la fois de manière interactive et dans le cadre d'un framework CI/CD. La figure 7 montre que les exigences 1 et 2.2 passent le test et que les autres exigences n'ont pas été exercées.
Le lien numérique et au-delà
De nombreux artefacts sont créés et/ou générés au cours des différentes étapes du cycle de développement d'un produit. Ces artefacts numériques comprennent les exigences, l'architecture, les modèles de design, les fichiers de code, et les fichiers de vérification et de validation. Il est fondamental d'établir un lien traçable entre ces artefacts pour comprendre l'impact des exigences sur d'autres exigences, modèles ou activités de vérification et de validation. Ce lien sert de lien numérique.
Par exemple, des diagrammes de traçabilité des exigences peuvent être générés automatiquement à partir des modèles d'exigences et d'architecture, ce qui permet de comprendre comment ces exigences, modèles et artefacts de vérification sont graphiquement liés les uns aux autres.
La figure 8 montre le lien numérique dans lequel le besoin d'une partie prenante est satisfait par une autre partie prenante. En réalité, plusieurs parties prenantes seront réparties dans l'organisation et couvriront différents domaines fonctionnels à divers niveaux d'abstraction. C'est là qu'un lien numérique devient indispensable. En outre, un lien numérique facilite l'utilisation de processus et d'infrastructures automatisés, agiles et itératifs (DevOps). Par exemple, la figure 8 montre comment l'état de vérification d'un test est automatiquement transmis à l'ingénieur responsable.
Alors que les organisations s'engagent sur la voie de la transformation digitale, les concepts de liens numériques, de jumeaux numériques et de DevOps jouent des rôles complémentaires dans les fondements de l'ingénierie numérique. Ces concepts fonctionnent de concert pour créer une infrastructure qui supporte la transition des pratiques d'ingénierie traditionnelles vers des pratiques centrées sur le numérique.
Nous avons décrit dans ce document un processus au cours duquel, sur la base des besoins des parties prenantes, nous avons convenu des exigences du système (simulables/exécutables) à l'aide de méthodes de simulation et de méthodes formelles. Pour ce faire, nous avons utilisé des modèles d'exigences qui pouvaient simuler (machines à états), évaluer (diagrammes de séquence) et être analysés formellement (tableau d’exigences).
L'utilisation de modèles d'exigences permet d'automatiser les activités de vérification et de validation, ce qui permet d'obtenir des exigences système complètes, cohérentes et validées. Elle permet également d’améliorer la collaboration entre différentes équipes car ces exigences fournissent plus d’informations que des exigences purement descriptives ou textuelles.
Par Alan Moore, Becky Petteys et Stephan van Beek
- System Composer (1:44) - Vidéo
- Utiliser le Model-Based System Engineering pour se conformer à l'ARP4754A (1:01:22) - Vidéo
- L’ingénierie numérique pour système de systèmes (32:33) - Vidéo
- Exemple de workflow pour la gestion des exigences et les vérifications avancées des modèles (0:58) - Vidéo
- Identifier en cours d'édition les erreurs relatives aux directives de modélisation d'architecture logicielle et système (3:32) - Vidéo
- Concevoir, analyser et tester des architectures système et logicielles - Présentation
- MATLAB et Simulink pour la transformation digitale - Présentation
Sélectionner un site web
Choisissez un site web pour accéder au contenu traduit dans votre langue (lorsqu'il est disponible) et voir les événements et les offres locales. D’après votre position, nous vous recommandons de sélectionner la région suivante : United States.
Vous pouvez également sélectionner un site web dans la liste suivante :
Comment optimiser les performances du site
Pour optimiser les performances du site, sélectionnez la région Chine (en chinois ou en anglais). Les sites de MathWorks pour les autres pays ne sont pas optimisés pour les visites provenant de votre région.
Amériques
- América Latina (Español)
- Canada (English)
- United States (English)
Europe
- Belgium (English)
- Denmark (English)
- Deutschland (Deutsch)
- España (Español)
- Finland (English)
- France (Français)
- Ireland (English)
- Italia (Italiano)
- Luxembourg (English)
- Netherlands (English)
- Norway (English)
- Österreich (Deutsch)
- Portugal (English)
- Sweden (English)
- Switzerland
- United Kingdom (English)