Extension proposée de SysML

Les différentes relations présentées dans les paragraphes précédents (composition,

derivation, copy, satisfy, verify, refine et allocate) sont essentielles pour la définition de

notre modèle d’information et également pour satisfaire la gestion des exigences de l’EIA- 632. Cependant, nous souhaitons ajouter au langage quelques autres éléments.

Nous définissons de nouvelles exigences, qui contiennent plus d’information que les exigences de base de SysML. Ces informations sont utiles pour une meilleure conception, en

110

fournissant plus de détails et en rendant possible un meilleur suivi du travail. A cela nous ajoutons aussi un nouveau lien, ainsi que de nouveau « type » d’exigences (plus précisément, il s’agit de stéréotype). Nous définissons entre autres un « sous-type » d’exigence technique du système qui sont des exigences de sûreté de fonctionnement. De plus, nous ajoutons un nouveau type de block à SysML : il s’agit d’un block « risk » qui représente les risques qui menacent le système.

3.2.1. Exigences enrichies

Le concept d’exigence est fondamental en conception système. C’est également un des intérêts et une des nouveautés qu’apporte SysML, de considérer les exigences et les lier à des éléments du modèle. L’objectif est de rapprocher et lier les besoins des parties prenantes à la solution de conception, pour guider le développement, aider la vérification et la validation, ou encore faciliter le suivi des changements d’exigences ou les évolutions.

SysML définit une exigence comme le montre l’élément requirement à gauche dans la Figure IV.22, avec 3 attributs :

 Heading : le nom de l’exigence, qui correspond au nom donné à l’élément

requirement.

 Text : sa description sous forme textuelle.

 Id : son identifiant.

Nous enrichissons cette définition en préconisant de nouveaux attributs, dont une partie est inspirée du profil RPM (Requirement Profil for MeMVaTEx), des recommandations de l’AFIS ou de la Snow Card Volere. Ces attributs, visibles à droite dans la Figure IV.22, sont les suivants :

 Catégorie : indique si l’exigence est fonctionnelle, de fiabilité, de performance, de sécurité, de coût, de disponibilité, de maintenabilité, de sûreté, … (Une liste possible est donnée par Volere [Roberston, 2010]).

 Justification : justifie l’existence de l’exigence.

 Source : enregistre la provenance de l’exigence (acquéreur, partie prenante, conception, lois, règlementation, base technologique, standards, spécifications, capacités et tendances des produits concurrents, interfaces avec d’autres systèmes ou plateformes, analyse de risques, …).

 Cible : indique la cible concernée par l’exigence qui peut être le système ou des produits contributeurs (produits de développement, de production, de test, de déploiement/installation, d’entrainement, d’opération, de support/maintenance ou de retrait de service).

 Maturité (origine, définie, validée, vérifiée) : renseigne sur la vie de l’exigence qui passe à travers différents stades.

 Criticité (faible…forte) : caractérise l’importance de l’exigence en termes de risque.

 Flexibilité (faible…forte) : caractérise une certaine tolérance envers la satisfaction de l’exigence.

 Priorité (faible…forte) : ordonne les exigences pour leur prise en compte dans la conception.

Chapitre 4 Vers une méthodologie ISDM

111

Figure IV.22 : Exigences SysML enrichies

Concernant le champ maturité qui renseigne sur la vie de l’exigence, la Figure IV.23 illustre les différents stades en les détaillant. En fait, l’exigence doit atteindre l’état « validée » pour pouvoir être alloué à un élément de modèle. Quant à l’état « vérifiée », il est obtenu après avoir suivi le TestCase associé à l’exigence, qui procède à une vérification sur le modèle ou le système réalisé.

Figure IV.23 : Champ maturité d’une exigence

3.2.2. Nouveaux stéréotypes d’exigences

Les stéréotypes permettent d’étendre la sémantique des éléments de modélisation : il s’agit du mécanisme d’extension du méta-modèle d’UML (base de SysML). Ils permettent de définir de nouveaux types de block, en plus du noyau prédéfini par UML (ou SysML par extension). Comme exemples de stéréotypes, nous avons déjà vu <<requirement>> ou <<testcase>>.

Pour catégoriser les exigences en respectant la classification de la norme EIA-632, nous avons défini de nouveaux stéréotypes pour les exigences, comme le montre la Figure IV.24.

112

Figure IV.24 : Nouveaux stéréotypes pour les exigences

Ainsi, pour mieux distinguer les exigences entre-elles, il sera possible de créer des exigences de différents stéréotypes :

 <<acquirerReqt>> pour les exigences d’acquéreurs,

 <<otherStakeholderReqt>> pour les exigences des autres parties prenantes,

 <<systemTechnicalReqt>> pour les exigences techniques du système,

 <<safetyReqt>> pour les exigences techniques du système de sûreté de fonctionnement,

 <<specifiedReqt>> pour les exigences spécifiées.

Sur la même Figure IV.24, apparait aussi la définition d’un nouveau lien de traçabilité : le lien « specify ». Il permet de lier les exigences spécifiées et la solution de conception. Pour rappel, les exigences spécifiées, telles que définies dans l’EIA-632, servent à décrire et détailler la solution de conception finale.

Note : sur la Figure IV.24, les éléments de SysML sont les rectangles à contour épais. Le reste correspond à l’extension du langage que nous proposons.

3.2.3. Stéréotype « risk »

Les analyses de risques sont, comme nous l’avons déjà vu, à la base de la conception de système sûr de fonctionnement. C’est souvent le point de départ de réflexions concernant la fiabilité du système ou la sécurité du système et de ses utilisateurs.

Les risques, suite à leurs analyses par le processus de traitement des risques, peuvent être à la source d’exigences de sûreté de fonctionnement, voire de modification d’exigences déjà existantes. Les nouvelles exigences ainsi définies vont agir sur le risque en essayant soit de réduire l’impact de l’occurrence du risque (sa gravité), soit de réduire la fréquence d’occurrence du risque, ou les deux. Le but final étant de rendre le risque acceptable selon sa criticité, qui est une combinaison de sa gravité et de sa fréquence (voir Figure IV.25).

Chapitre 4 Vers une méthodologie ISDM

113

Figure IV.25 : Matrice de criticité

De par l’existence de cette relation entre les risques et les exigences de sûreté et de par l’importance que cela représente au niveau de la traçabilité et de la compréhension du modèle, nous introduisons un nouveau stéréotype de bloc « risk », visible en Figure IV.26. Les attributs que nous définissons pour ce bloc « risk » sont les suivants :

 ID : identifiant,

 Statment : description du risque,

 Assumptions : éventuelles hypothèses faites pour la définition de ce risque,

 Severity : sévérité (ou gravité) du risque (sans gravité, mineur, majeur, hasardeux,

catastrophique).

Figure IV.26 : Le bloc « risk »

Ce bloc apporte en fait une justification à la présence des exigences, tout en aidant à la gestion des risques. Les analyses d’impacts tirent aussi un bénéfice de cette traçabilité entre risques et exigences. Il est possible, par exemple, d’avoir directement accès aux risques remis en cause par la modification d’une exigence.

La Figure IV.27 présente la définition du bloc « risk » comme extension de SysML. Sur cette même figure apparaît la définition d’un nouveau lien de traçabilité « treat », qui permet de lier les exigences de sûreté de fonctionnement aux risques.

114

Figure IV.27 : Nouveau bloc « risk » lié aux exigences de sûreté de fonctionnement

Note : dans la Figure IV.27, de même que pour la Figure IV.24, les éléments de SysML sont les rectangles à contour épais. Le reste correspond à l’extension du langage que nous proposons.