Département : Génie électrique

INGENIERIE SYSTEME
COURS

2ème année Cycle ING

FILIERE : MSEI/GEM

Pr. Nadia MACHKOUR

Année Universitaire : 2019-2020

Dans le cours nous avons présenté une méthode pour mener l’ingénierie des exigences en se
basant sur le processus technique de l’IS (la définition des besoins des PPs et l’analyse des
exigences, la méthode de conception). Cette méthode est composée de trois vues : vue
opérationnelle, vue fonctionnelle et vue organique. Dans le cours nous nous sommes focalisées
sur la vue opérationnelle, (c’est-à-dire on traite le système comme une boite noire), nous nous
sommes donc intéresses spécialement aux deux sous processus définition des besoins des PPS
et Ingénierie des exigences, La méthode est composée de 8 activités :1-cadrer le système, 2-
Définir le cycle de vie, 3- Définir les contextes, 4- Définir les cas d’utilisation, 5- Décrire les
cas d’utilisation, 6- Définir les exigences non fonctionnelles, 7- Définir les exigences non
fonctionnelles, 8- Assurer la traçabilité :
Dans ce document nous allons présenter comment on peut modéliser les exigences en utilisant
SysML, Il est composé de deux parties : la première partie présente l’outil de modélisation
SysML, et la deuxième présente comment on implémente la méthode d’IE en utilisant SysML.
Il constitue un support de travaux pratiques du module IS.
Pour notre étude nous allons utiliser la version demo du logiciel Cameo Systems Modeler ™,
je vous transmets la méthode de son installation.

2
3
Table des matières
Chapitre 1: L’outil de modélisation SysML ............................................................................ 6
I. Introduction .................................................................................................................... 6
II. Éléments graphiques des diagrammes........................................................................... 9
1. Cadre du diagramme .................................................................................................. 9
2. Formes géométriques et liens ..................................................................................... 9
3. Commentaires ...........................................................................................................10
III. Modélisation SysML ...................................................................................................11
1. Diagrammes comportementaux .................................................................................11
1-1. Diagramme de cas d’utilisation ...........................................................................11
1-2. Diagramme de séquence (SysML Sequence Diagram).......................................13
1-3. Diagramme d’états / transitions (SysML State Machine Diagram).......................15
1-4. Diagrammes d’activités .......................................................................................17
2. Diagrammes structurels .............................................................................................19
2-1. Diagramme de définition de blocs (SysML Block Definition Diagram) ....................19
2-2. Diagramme de blocs internes (SysML Internal Block Diagram) ..............................19
3. Diagramme transversal ..............................................................................................21
3-1. Diagramme d'exigences (SysML Requirements Diagram). .....................................21
Chapitre 2 : Modélisation des exigences par SysML ............................................................23
I. Introduction ................................................................................................................24
II. Cadrer le système......................................................................................................24
III. Définir le cycle de vie en utilisant SYsML ....................................................................26
IV. Définir les contextes en utilisant SysML ......................................................................27
V. Définir les utilisations en utilisant SysML .....................................................................28
1. Définir les concepts système .....................................................................................28
2. Définir les cas d’utilisation ........................................................................................28
VI. Décrire les cas d’utilisation en utilisant SysML .............................................................30
1. Description textuelle ..................................................................................................30
2. Formalisation des scénarios .....................................................................................30
VII. Définir les exigences fonctionnelles en utilisant SysML .............................................33
VIII. Définir les exigences non fonctionnelles en utilisant SysML.......................................34
IX. Assurer la traçabilité en utilisant SysML ......................................................................35
1. Traçabilité des Exigences fonctionnelles/Cas d’utilisation .........................................35
2. Traçabilité des Exigences entre les processus d’ingénierie des exigences ................35
Annexe .................................................................................................................................37
I. Définition d’une exigence ..............................................................................................37
II. Exemple de typologie d’exigences ................................................................................37
III. caractéristiques des exigences (AFIS) .........................................................................37
IV. Gabarit de rédaction d’une exigence ...........................................................................38
4
 V. Identifiants et stéréotypes d’exigence ...........................................................................38
Bibliographie : ......................................................................................................................39

5
 Chapitre 1: L’outil de
modélisation SysML

I. Introduction

L’ingénierie système (IS) représente un ensemble des activités adéquates pour concevoir, faire
évoluer et vérifier un système, elle apporte une solution économique et performante aux besoins
d’un client tout en satisfaisant l’ensemble des parties prenantes. Les méthodes de l’IS s’appuient
sur des approches de modélisation et de simulation pour valider les exigences, et pour vérifier
ou évaluer le système.

Depuis longtemps, les ingénieurs système ont utilisé des techniques de modélisation. Parmi les
plus connues, on trouve SADT et SA/RT, qui datent des années 80, ainsi que de nombreuses
approches basées sur les réseaux de Pétri ou les machines à états finis. Ces techniques sont
limitées par leur portée et leur expressivité ainsi que par la difficulté de leur intégration avec
d’autres formalismes, comme avec les exigences système
UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre
et décrire des besoins, spécifier et documenter des systèmes, représenter des architectures
logicielles, concevoir des solutions et communiquer des points de vue.
UML unifie à la fois les notations et les concepts orientés objet. Il ne s’agit pas d’une simple
notation graphique, car les concepts transmis par un diagramme ont une sémantique précise et
sont porteurs de sens au même titre que les mots d’un langage.
L’essor d’UML dans le domaine du logiciel et l’effort industriel de développement d’outils qui
l’accompagne ont naturellement conduit à envisager son utilisation en ingénierie système.
Cependant, du fait de sa conception fortement guidée par les besoins du passage à la
programmation par objets, le langage était, tout au moins dans ses premières versions, peu
adapté à la modélisation des systèmes complexes et donc au support de l’ingénierie système.

SysML (Systems Modeling Language) (apparut en 2007) est basé sur UML et remplace la
modélisation de classes et d'objets par la modélisation de blocs pour un vocabulaire plus adapté

6
à l'Ingénierie Système. Un bloc englobe tout concept logiciel, matériel, données, processus, et
même la gestion des personnes.
Comme représenté sur la figure 1, SysML réutilise une partie d'UML, et apporte également ses
propres définitions (extensions SysML). SysML s’articule autour de neuf types de
diagrammes1, chacun d’eux étant dédié à la représentation des concepts particuliers d’un
système. Ces types de diagrammes sont répartis par l’OMG en trois grands groupes : 4
structurels, 4 dynamiques, et le diagramme d’exigences.

 Quatre diagrammes comportementaux :

1. diagramme de cas d’utilisation (montre les interactions fonctionnelles entre les
acteurs et le système à l’étude) ;
2. diagramme de séquence (montre la séquence verticale des messages passés entre
blocs au sein d’une interaction) ;
3. diagramme d’états (montre les différents états et transitions possibles des blocs
dynamiques) ;
4. diagramme d’activité (montre l’enchainement des actions et décisions au sein
d’une activité complexe) ;

 Un diagramme transverse : le diagramme d’exigences (montre les exigences du

système et leurs relations) ;
 Quatre diagrammes structurels :
1. diagramme de définition de blocs (montre les briques de base statiques : blocs,
compositions, associations, attributs, opérations, généralisations, etc.) ;
2. diagramme de bloc interne (montre l’organisation interne d’un élément statique
complexe) ;
3. diagramme paramétrique (représente les contraintes du système, les équations qui
le régissent) ;
4. diagramme de packages (montre l’organisation logique du modèle et les relations
entre packages).

1
Le SysML, est un ensemble de représentations graphiques. Chaque graphique est appelé
diagram en anglais, et par abus de langage, nous le nommerons diagramme en français
7
La structure du système est représentée par les diagrammes de blocs. Le diagramme de
définition de blocs (block definition diagram) décrit la hiérarchie du système et les
classifications système/composant. Le diagramme de bloc interne (internal block diagram)
décrit la structure interne du système en termes de parties, ports et connecteurs. Le diagramme
de packages est utilisé pour organiser le modèle.
Les diagrammes comportementaux incluent le diagramme de cas d’utilisation, le diagramme
d’activité, le diagramme de séquence et le diagramme de machines à états. Le diagramme de
cas d’utilisation fournit une description de haut niveau des fonctionnalités du système. Le
diagramme d’activité représente les flots de données et de contrôle entre les actions. Le
diagramme de séquence représente les interactions entre les parties du système qui collaborent.
Le diagramme de machines à états décrit les transitions entre états et les actions que le système
ou ses parties réalisent en réponse aux événements.
Le diagramme d’exigences capture les hiérarchies d’exigences, ainsi que leurs relations de
dérivation, de satisfaction, de vérification et de raffinement. Ces relations fournissent la
capacité de relier les exigences les unes aux autres, ainsi qu’aux éléments de conception et aux
cas de tests

Figure1 Les 9 types de diagrammes SysML

8
 II. Éléments graphiques des diagrammes

1. Cadre du diagramme

Chaque diagramme SysML représente un élément particulier du modèle selon un certain point
de vue : afin de le repérer, chaque diagramme comporte un « cartouche » présenté figure 2,
positionné sur la partie supérieure gauche du cadre.

Figure 2. Structure du cadre de description des diagrammes SysML .

Le type de diagramme, repéré par son identifiant (bdd, ibd, etc.), est obligatoirement indiqué
dans ce cartouche. L’ajout des autres éléments est optionnel selon la norme mais les logiciels
dédiés à la modélisation par ce langage (voir page 23) ajoutent par défaut le type d’élément
(bloc ou paquet par exemple) et proposent d’indiquer le nom du modèle mis en place et le point
de vue utilisé 5.

2. Formes géométriques et liens

Les neuf diagrammes du langage SysML sont composés des mêmes types de formes
géométriques : des rectangles à coins droits ou arrondis, des ellipses et des lignes. Selon les
diagrammes, tout ou partie de ces formes géométriques seront utilisées.
Plusieurs types de relations peuvent être rencontrées entre les formes géométriques dans les
diagrammes SysML : le tableau de la figure 3 regroupe les liens les plus classiques.

9
 Figure 3. Les principaux liens graphiques du langage SysML.

3. Commentaires

Dans tous les diagrammes du langage SysML, il est possible d’utiliser des notes graphiques
sous la forme de « Post-it» avec éventuellement les deux mots clés problem (problème) pour
indiquer les problèmes encore à résoudre et rationale (raison) pour justifier certains choix. Ces
notes permettent de commenter n’importe quel élément d’un diagramme (forme graphique ou
lien) et elles seront donc utilisées pour expliciter un point qui pourrait être difficile à
comprendre ou modéliser par le lecteur.

10
III. Modélisation SysML

1. Diagrammes comportementaux

1-1. Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation est un schéma qui montre les cas d’utilisation (ovales)
reliés par des associations (lignes) à leurs acteurs (icône d'un stick man). Chaque association
signifie simplement «participe à». Ce diagramme permet de représenter les besoins attendus
par un système.
On utilise un diagramme pour chaque phase de vie où le système rend des services (besoins
attendus)
– Exploitation [maintenance, …]
– La mission devrait être le cas d’utilisation principal !

Les principaux concepts d’un modèle de cas d’utilisation sont présentés sur la figure 4 :

 Les acteurs et systèmes externes présents dans ces diagrammes sont les parties prenantes
et systèmes externes impliqués
 Une relation d’extension est formalisée par le mot « extend » et une flèche en pointillée,
un cas B est une extension d’un cas B lorsque le cas B peut être appelé au cours de
l’exécution de A
 Une relation d’inclusion est formalisée par le mot-clé « include » et une flèche en
pointillée : Un cas inclut le cas B lorsque A est sollicité B l’est obligatoirement

Méthode de construction d’un diagramme de CU (figure 4)

1. Définir le périmètre du système : frontière du système

2. Mettre les parties prenantes impliquées : acteurs
3. Mettre les systèmes externes : acteurs « système »
• Mettre les acteurs et acteurs « système » externes principaux à gauche et les secondaires
à droite.
11
4. Définir les services attendus : principaux cas d’utilisation
• Les nommer par un verbe d’action à l’infinitif
• Les décomposer si nécessaire : lien « include »
• Les prolonger ou compléter : lien « extend » : en cas d’événement particulier ou d’option
• Éviter les liens de généralisation
5. Associer les acteurs et les systèmes externes aux cas d’utilisation (échanges,
communication) : lien d’association : Chaque association signifie simplement «participe
à».

Figure 4. MODÈLE DE CAS D’UTILISATION : PRINCIPAUX CONCEPTS

12
 Figure 5. MODÈLE DE CAS D’UTILISATION : EXEMPLE DE BASE

Spécification textuelle d’un cas d’utilisation

 Utiliser systématiquement un patron
 Identifiant unique, nom, auteurs, priorité, criticité/risque, source,
responsable, description, évènement, acteurs, préconditions,
postconditions, résultat, scénario principal, scénarios alternatifs,
scénarios exceptionnels, exigences qualités
 Préciser dans la description des scénarios
 Le contexte (opérationnel)
 Les actions et interactions, leurs enchaînements et conditions éventuelles
 Les acteurs qui font l’action, les données en entrée et en sortie
 Les options éventuelles

1-2. Diagramme de séquence (SysML Sequence Diagram)

.
Le diagramme de séquence permet de décrire les scénarios correspondant aux cas d'utilisation,
un cas d'utilisation est décrit par au moins un diagramme de séquence, répondre à la question :

13
"Comment est réalisé ce cas d'utilisation ? " et montrer les interactions entre différents éléments
d'un point de vue séquentiel, enchaînement et nature des échanges
Il est utilisé pour documenter la transformation des données d’entrée reçues de l’environnement
en données de sortie vers l’environnement, (Données : informations, matériels voire énergie).
Méthode de construction d’un diagramme de séquences (Figure 6)
1. Identifier le comportement à décrire : Cas d’utilisation
2. Mettre le « système » au centre : instance bloc « système »
3. Mettre les acteurs à gauche : instances d’acteur
4. Mettre les entités externes à droite : instances de bloc
5. Définir les interactions : messages entre les lignes de vie
• Favoriser le type de message asynchrone (asyncSignal)
– NB : d’autres types seront utilisés lors de la conception de l’architecture
6. Définir les périodes d’activité système : périodes d’activation
• Structurer ces périodes en les regroupant par situation
7. Structurer pour clarifier : référence à une autre séquence

Figure 6. Diagramme de séquences : principaux concepts

14
 Figure 7. Diagramme de séquences : Exemple

1-3. Diagramme d’états / transitions (SysML State Machine Diagram)

Le diagramme d’état permet de décrire le comportement d'un programme sous forme de

machine d'états, de montrer les différents états pris par le système (ou un sous-système) en

15
fonction des interactions et de répondre à la question : "Comment représenter les différents états
du système ?". Il est basé sur la théorie des automates à états finis.

Ce diagramme servira avant tout à décrire le fonctionnement d'un programme. Ce diagramme

trouve toute sa place en lien avec les logiciels de simulation comportementale (Matlab,
LabView, Modelica,…) .

Méthode de construction d’un diagramme d’états (figure 8)

1. Identifier le comportement à décrire : le bloc « système »
2. Définir les états stables
• Créer l’état initial et les éventuels états finaux
• Utiliser des états « composites » pour hiérarchiser
– Préciser éventuellement les points d’entrée et de sortie
• Utiliser des états « concurrents » pour représenter du parallélisme
3. Relier les différents états par des transitions
• Identifier les évènements associés
– Mettre des conditions de garde si nécessaire (condition booléenne ou «sinon»
– Associer les éventuelles activités (actions)

Figure 8. Diagramme d’états : principaux concepts

16
 Figure 9. Diagramme d’états : exemple de base

1-4. Diagrammes d’activités

Le diagramme d’activités permet de documenter la transformation des données d’entrée

reçues de l’environnement en données de sortie vers l’environnement (Données : informations
et matériels)
Méthode de construction d’un diagramme d’activités (figure 10)
1. Identifier le comportement à décrire : Cas d’utilisation
• Éventuellement un autre objet de modélisation : classe, bloc, …
2. Mettre les noeuds de début et de fin
3. Définir les actions, les objets et leurs séquences via les flux de contrôle, d’objets, de
synchronisation et de divergence
4. Définir les conditions éventuelles
5. Éventuellement, il est aussi possible de faire apparaître des sous systèmes ;

17
Figure 10. Diagramme d’activités : principaux concepts

Figure 11. Diagramme d’activités : Exemple de base

18
2. Diagrammes structurels

2-1. Diagramme de définition de blocs (SysML Block Definition

Diagram)

Diagramme de définition de blocs permet de montrer le système d'un point de vue

composé/composant, de répondre à la question "qui contient quoi ?", de montrer les
caractéristiques principales de chaque bloc en faisant apparaitre les opérations (rôles) et les
propriétés (caractéristiques). Permettre de représenter les liens entre les blocs de même niveau
par une association (simple trait entre 2 blocs).
On peut l’utiliser pour la spécification du contexte d’un système :
– Parties prenantes et/ou autres systèmes concernés

Figure 12. Exemple : diagramme de définition de bloc

2-2. Diagramme de blocs internes (SysML Internal Block Diagram)

Diagramme de blocs internes Permet de représenter les échanges de

matière/information/énergie entre blocs de même niveau grâce aux ports de flux (petit carré
avec une flèche), de représenter les services invoqués par un autre bloc grâce aux ports
standards (petit carré sans flèche), et par extension toute entrée/sortie de contrôle/commande,
et de représenter les liens entre les blocs de même niveau.
Il décrit la vue interne d’un bloc, et se base sur le BDD pour représenter l’assemblage des blocs.

19
Un bloc peut avoir plusieurs ports qui spécifient des points d’interaction différents. Les ports
peuvent être de deux natures :
Port standard : désigne une interface permettant d'invoquer un service / une opération
Port de flux : canal d'Entrée / Sortie par lequel transite de la matière, de l'énergie ou de
l'information (MEI).

Figure 13. Diagramme de blocs internes : principaux concepts

Figure 14. Exemple : diagramme interne de bloc

20
 Figure 15. Exemple : diagramme interne de bloc

3. Diagramme transversal
3-1. Diagramme d'exigences (SysML Requirements Diagram).

Une exigence permet de spécifier une capacité ou une contrainte qui doit être satisfaite par un
système. Elle peut spécifier une fonction que le système devra réaliser ou une condition de
performance, de fiabilité, de sécurité, etc.
Les exigences servent à établir un contrat entre le client et les réalisateurs du futur système

Un Diagramme d'exigences permet de documenter les exigences en lien avec les autres modèles
réalisés
– Permet de relier les exigences entre elles et avec d’autres éléments de modélisation
– Permet de mettre en évidence comment vont être satisfaites les exigences (lien de
satisfaction) … par un composant, par une fonction, …

21
Méthode de construction d’un diagramme d’exigences (figure 16)
1. Identifier la fonctionnalité à spécifier : Cas d’utilisation
• Service attendu du système ou fonction principale
2. Définir l’exigence fonctionnelle à associer : Exigence
3. Relier l’exigence au cas d’utilisation : Lien
• « refine » si le cas d’utilisation est décrit par d’autres modèles
• « trace » sinon
4. Définir les exigences dérivées : Exigence et lien « derive »
• En se posant des questions systématiquement par rapport aux stéréotypes d’exigences
qualité (performance, interface, …)
5. Justifier si nécessaire exigences et liens : Raisonnement
6. Si nécessaire ajouter les modalités des tests : Cas de test et lien « verify »

Figure 16. Diagramme d’exigences : principaux concepts

22
Figure 17. Diagramme d’exigences : principaux attributs

Figure 18. Diagramme d’exigences : Exemple de base

Chapitre 2 : Modélisation des

exigences par SysML

23
 I. Introduction

L’activité d’Ingénierie des Exigences du Système System élicite et analyse les exigences de
l’Acquéreur et des Parties Prenantes y compris les exigences juridiques et/ou réglementaires.
Elle établit les exigences du système convenu. En parallèle avec les activités de conception de
l’architecture, elle établit les exigences sur les Constituants du Système.
La méthode que nous allons utiliser est basée sur le processus technique de l’I, elle est composée
de 8 activités :1-cadrer le système, 2- Définir le cycle de vie, 3- Définir les contextes, 4- Définir
les cas d’utilisation, 5- Décrire les cas d’utilisation, 6- Définir les exigences non fonctionnelles,
7- Définir les exigences non fonctionnelles, 8- Assurer la traçabilité.

II. Cadrer le système

On réalise un diagramme d’exigences (RD SysML)

 Définir une exigence pour spécifier la mission et lui donner un identifiant, on peut lui
associer un stéréotype comme « missions pour clarifier
 Définir un bloc pour représenter le système, on peut lui associer un stéréotype comme
« système » pour clarifier
 Relier le système et la mission par un lien de satisfaction
 Définir une exigence pour spécifier la finalité et lui donner un identifiant, on peut lui
associer un stéréotype comme « finalité » pour clarifier
 Relier la mission et la finalité par un lien de dérivation ou d’association

24
 Figure 1. Mission principale du système (PFMS)
Si nécessaire la mission peut être raffinée
 Définir des exigences pour spécifier des sous missions et leur donner un identifiant, on
peut leur associer un stéréotype comme « mission » pour clarifier
 Relier les sous missions à la mission par des liens de dérivation
 Définir des exigences pour spécifier des performances, contraintes, et leur donner un
identifiant, on peut leur associer des stéréotypes pour clarifier
 Relier ses exigences aux missions par des liens de dérivation

25
 Figure 2. Mission et sous missions du systèmes

III. Définir le cycle de vie en utilisant SYsML

Pour formaliser le cycle de vie du système, on réalise un diagramme d’état (STDM SYsML),
on peut l’associer au bloc système :
 Définir un état initial ;
 Définir un état pour chaque phase de vie à considérer ;
 Définir éventuellement un état final ;
 Relier ces états par des transitions et spécifier les évènements (trigger) qui permettent
ces transitions pour définir le cycle de vie du système

26
 Figure 3. Cycle de vie du système

IV. Définir les contextes en utilisant SysML

Pour formaliser les contextes, on réalise un diagramme de définition de bloc (BDD SYsML)
pour chaque phase de vie considérée :
 Mettre le bloc système au centre du diagramme ;
 Définir des acteurs pour spécifier les PPS impliquées dans la phase de vie ;
 Définir des blocs pour spécifier les autres systèmes externes impliqués dans la phase de
vie, on peut leur associer un stéréotype comme « Système externe » pour clarifier ;
 Relier ces acteurs et ces blocs au bloc système par des associations orientées ou non,
leur donner un nom caractérisant la relation principale ;
 Si cela peut avoir une réelle valeur ajoutée, définir les cardinalités ou les multiplicités
de ses associations. Ce sont des nombres que l’on peut voir sur les liens entre blocs qui
représentent le nombre minimum et maximum de possibilités ;

Figure 4. Diagramme de contexte du système

27
V. Définir les utilisations en utilisant SysML

1. Définir les concepts système

Sur la base des expertises et de la compréhension du problème, on peut introduire d’éventuels
concepts système qu’ils soient opérationnels ou d’architecture. Pour les formaliser, on réalise
un diagramme de définition de bloc (BDD SysML) :
 Mettre le bloc système à gauche dans le diagramme ;
 Définir des notes « comment » pour spécifier les concepts ;
 Relier ces notes au bloc système (lien d’ancrage « anchor ») ;
 Définir pour chaque concept au moins une note « rational » pour justifier le choix du
concept

Figure 4. Exemple de concepts d’un système

2. Définir les cas d’utilisation

Pour formaliser les différentes utilisations du systèmes on réalise un diagramme de cas
d’utilisation (UCD SysML) pour chacune des phases de vie où des fonctionnalités sont
attendues du système :
 Définir le périmètre du système dans la phase de vie (System boundary), lui donner un
nom caractérisant la phase de vie ;

28
 Mettre les acteurs représentant PPS impliquées (dans un rôle) dans les utilisations du
système dans la phase de vie ;
 Mettre les blocs représentant les systèmes externes concernés (dans une interaction)
dans les utilisations du système dans la phase de vie ;
 Définir les cas d’utilisation principaux correspondant aux services ou fonctionnalités
attendus du système, ils peuvent être :
 Nommés en utilisant de préférence un verbe d’action à l’infinitif ;
 Décomposer si nécessaire (lien « include ») ;
 Prolongés, étendus ou complétés en cas d’événement particulier ou
d’option(lien « extend ») ;
 Associer les acteurs et les systèmes externes aux cas d’utilisation (lien d’association).

Remarques
 Il faut pas trop décomposer pour ne pas faire l’analyse fonctionnelle trop tôt ;
 IL est recommandé de mettre les acteurs et les systèmes externes principaux à
gauche et les secondaires à droite ;
 Les acteurs et les systèmes externes présents dans ces diagrammes sont
forcément dans les diagrammes de contexte. La réciproque n’est pas vrai, tous
les acteurs présents dans les diagrammes de contexte ne sont pas dans le
diagramme de cas d’utilisation (PPS on utilisatrices) ;
 La mission principale du système se retrouve généralement dans le cas
d’utilisation de la phase exploitation

Figure 6. Diagramme d’utilisation du système

29
VI. Décrire les cas d’utilisation en utilisant SysML

1. Description textuelle
Pour Décrire Textuellement les cas d’utilisation, on réalise un nouveau diagramme de cas
d’utilisation (UCD SysML) en cohérence avec les précédents :
 Mettre les cas d’utilisations définis précédemment ;
 Définir une note pour décrire le scénario ;
 Attacher la note au cas d’utilisation

Figure 7. Description textuelle d’un scénario d’utilisation

2. Formalisation des scénarios

Pour formaliser les cas d’utilisation, on peut réaliser des diagrammes d’état (STMD SysML)
des diagrammes de séquence (SD SysML) et des diagrammes d’activités (AD SysML).
A ce niveau, le système devrait rester en vision boite noire. Pour autant di une partie de sa
structure est déjà connue, on peut la faire apparaitre.

a. Spécification des états du système

Afin d’avoir une vision d’ensemble du système, on peut réaliser un diagramme d’état du
système (STMD SysML), sur la base de tous les cas d’utilisation identifiés et des modes
opératoires associés, pour définir les principaux états du système et les conditions de passage
de l’un à l’autre :
30
  Définir les états stables représentant les différentes situations de vie et cas d’utilisation
associés :
 Utiliser des états « composites » , préciser éventuellement les points d’entrée et
de sortie, pour représenter les cas d’utilisation inclus ;
 Utiliser des états « concurrents » pour représenter du parallélisme ;
 Définir un état initial et les éventuels états finaux ;
 Relier les différents états par des transistions pour identifier les chemins possibles
suivant les scénarios opérationnels (modes de marche,…) :
 Définir les évènements qui permettent le passage d’un état à l’autre et
éventuellement des conditions de garde en fonction des situations (condition
booléenne ou [sinon]([else]) ;
 Des états supplémentaires comme « en veille » ou « en attente » peuvent être
nécessaires.

Figure 8. Spécification des états d’un système

b. Spécification des interactions du système

Pour formaliser les interactions du système avec son environnement, on peut réaliser pour
chaque cas d’utilisation au moins un diagramme de séquence (SD SysML) basé sur les
scénarios décrits textuellement s’ils existent et en tenant compte des concepts système
éventuellement définis :
 Mettre le bloc système au centre du diagramme ;
 Mettre les acteurs identifiés précédemment (opérateur, mainteneur,..) à gauche du
système ;

31
 Mettre les blocs représentant les entités externes identifiées précédemment (autres
acteurs : systèmes, matériels ) à droite du système ;
 Définir les messages entre les lignes de vie :
 A cette étape, seul le type de message asynchrone (asyncSignal ) peut
être utilisé, car il s’agit d’identifier les interactions ;
 Les autres types de messages seront utilisés lors de la conception de
l’architecture ;
 Les messages peuvent supporter indifféremment les flux d’information,
de matière ou d’énergie ;

 Définir les périodes d’activités du système :

 Structurer les périodes d’activation (ou d’exécution) du système en
regroupant les situations d’exécution des opérations et en les séparant
lors de changements de situation ou lors de périodes d’activité ;
 Représenter ses périodes d’activation par des bandes verticales le long
des lignes de vie ;
 Définir si nécessaire la référence à une autre séquence d’intéraction, cela permet de
donner plus de clarté aux diagrammes et donc d’améliorer la communication :
 Utiliser un cadre « Ref » et lui associer un autre diagramme de séquence.

Figure 9. Spécification d’interactions du système

32
c. Spécification des activités du système
Pour formaliser les activités du système, on peut réaliser pour chaque cas d’utilisation au moins
un diagramme d’activité (AD SysML) basé sur les scénarios décrits textuellement en tenant
compte des concepts système éventuellement définis :
Définir les activités (actions) du système ;
Définir les objets échangés ;
Relier les actions par des flux de contrôle, d’objets, de synchronisation ou de divergence
pour identifier les chemins possibles suivant les scénarios ;
Définir les conditions éventuelles et les associer aux flux ;

Figure 10. Spécification des activités du système

VII. Définir les exigences fonctionnelles en utilisant SysML

Pour spécifier les exigences fonctionnelles, on utilise le concept SysML d’exigence

(Requirement SysML). On réalise, en fonction de la complexité, au moins un diagramme
d’exigence (RD SysML) :
 Mettre les cas d’utilisation définie précédemment ;
 Définir une exigence pour chaque cas d’utilisation :
 Fixer son nom en accord avec le cas d’utilisation (voire une simple
recopie). Il est recommandé d’exprimer le nom en commençant par un
verbe à l’infinitif ou par une formulation du type « le système doit …) :
 Fixer son identifiant en fonction des conventions prédéfinies (numérique
ou alphanumérique porteur de sens, avec ou sans arborescence) ;
 Si nécessaire rédiger sa description textuelle (voir annexe) ;

33
  Relier chaque exigence au cas d’utilisation correspondant :
 Utiliser un lien « trace » si le cas d’utilisation est décrit uniquement
textuellement
 Utiliser un lien « refine » si le cas d’utilisation est décrit par au moins un
diagramme SysML (état, séquence ou activité) ;
 Associer les stéréotypes adaptés, s’ils ont été définis préalablement (exemple « Besoin
– service attendu », « Exigence-Fonctionnelle »,…) ;
 Relier les exigences entre elles :
Utiliser des liens de dérivation « derivReqt » en cohérence avec les liens
« include » et « extend » des cas d’utilisation.
Remarque :
L’exigence correspondant à la mission principale du système devrait se retrouver avec le cas
d’utilisation principale de la phase d’exploitation.
Dans SysML d’autres propriétés non normatives sont proposées : source (origine du besoin)
risque (si non satisfaite), methode de vérification. Dans le cas où l’outil ne supporte pas ces
extensions, il est possible d’utiliser l’attributs description. Par exemple (Source) du besoin
(partie prenante, besoin initial, CdC initial, courriel, norme ,…) peut être précisée.

VIII. Définir les exigences non fonctionnelles en utilisant SysML

Pour spécifier les exigneces non fonctionnelles, on utilise le concept SysML d’exigence
(Requirement SysML). On peut utiliser les diagrammes d’exigence (RD SysML),
(appliquer les mêmes règles que précédemment :
 Définir chaque exigence (performance, interface, contrainte,…) ;
 Fixer son nom. Il est recommandé d’exprimer le nom en
commençant par un verbe à l’infinitif ou par une formulation du
type « le système doit.. » :
 Fixer son identifiant en fonction des conventions prédéfinies
(numérique ou alphanumérique, porteur de sens, avec ou sans
arborescence) ;
 Si nécessaire, rédiger sa description textuelle
 Si nécessaire rédiger une description textuelle
 Associer les stéréotypes adaptés, s’ils ont été définis préalablement

34
  Relier chaque exigence à l’exigence fonctionnelle correspondante : Utiliser des
liens de dérivation « deriveReqt » ;

Si nécessaire, il est possible de compléter ces exigences :

 Pour préciser certaines exigences, définir de nouvelles exigences système :
 Utiliser des liens de dérivation « derivReqt » ou de raffinement
« refine » pour les relier entre elles ;
 Pour justifier un élément (exigence, lien ..) on peut utiliser les notes de
justification :
 Utiliser les notes stéréotypées « Rationale » et les relier aux éléments à
justifier.
 Pour indiquer comment on peut vérifier une exigence en en spécifiant un cas
de test :
 Utiliser « testCAse » pour définir des diagrammes de séquence
ou d’état décrivant les scénarios de test ;
 Utiliser des liens de vérification « verify » pour les relier aux
exigences.

IX. Assurer la traçabilité en utilisant SysML

Pour assurer la traçabilité des exigences, on utilise les liens entre les exigences SysML
(Requirement SysML). On peut utiliser les matrices pour les visualiser.

1. Traçabilité des Exigences fonctionnelles/Cas d’utilisation

 Définir une matrice Exigences fonctionnelles/cas d’utilisation qui met en
évidence les liens « trace » et « refine » :
 Chaque cas d’utilisation doit être lié à une exigence fonctionelle.

2. Traçabilité des Exigences entre les processus d’ingénierie des

exigences
Une traçabilité doit exister entre les différentes phases d’ingénierie (définition des besoins,
analyse des exigences, exigences des constituants).
 Définir une matrice Exigences/Exigences qui met en évidence les liens « trace » entre
les exigences de 2 phases d’ingénierie ;

35
  Définir une matrice Exigences/Exigences qui met en évidence les liens « derivReqt »
entre les exigences d’une même phase d’ingénierie :
 Chaque exigence d’un niveau doit être liée soit à une exigence d’un niveau supérieur
d’ingénierie, soit à une exigence du même niveau ;
 Exemple : lors de l’analyse des exigences par le MOE (Maitre
d’œuvre), toute exigence définie doit être liée à un besoin ou à
une autre exigence.
 Chaque exigence d’un niveau doit être liée soit à une exigence d’un niveau inférieur
d’ingénierie, soit être satisfaite par un élément du système.

La traçabilité des exigences permet de vérifier que toutes les exigences d’un niveau sont prises
en compte et qu’aucune exigence n’est orpheline (superflue).

36
Annexe

I. Définition d’une exigence

 Une exigence prescrit une propriété jugée nécessaire
 Son énoncé peut être :
 Un service ou yne fonction (transporter ..)
 Une caractéristique
 Une aptitude (Supporter une température de …)
 Une limitation (utiliser uniquement ..)
à la quelle doit satisfaire un système, un produit ou un processus.

II. Exemple de typologie d’exigences

III. caractéristiques des exigences (AFIS)

 Caractéristiques de qualité (niveau élémentaire) :
– Unicité : une exigence ne traite que d’un sujet
– Précision : rigueur dans l’expression

37
 – Non ambiguïté : ne permet qu’une seule interprétation
– Pure prescription : porte que le Quoi? Et non sur le Comment?
– Vérifiabilité, testabilité : à toute exigence peut être associée une méthode permettant
la vérification de son obtention
– Faisabilité : peut être satisfaite avec l’état de l’art technologique
– Réalisme : peut être satisfaite dans les contraintes du projet
 Caractéristiques (niveau global) :
– Cohérence : pas d’exigences contradictoires
– Complétude : pas de manques

IV. Gabarit de rédaction d’une exigence

Exemple du gabarit de rédaction de l’IREB (International Requirements Engineering Board ) :
à utiliser lors d’une reformulation

V. Identifiants et stéréotypes d’exigence

Par exemple et pour en faciliter la lecture, on peut ajouter les identifiants et les
stéréotypes suivants : BSi – « Besoin ‐ Service attendu », BOj ‐ « Besoin ‐ Opérationnel »,
BPk ‐ « Besoin ‐ Performance », BIx ‐ « Besoin ‐ Interface », BCy ‐ « Besoin ‐ Contrainte ».

38
Bibliographie :

o Pascal Roques « SysML par l’exemple », ISBN : 978-2-212-85006-2 © Eyrolles 2009

o Guillaume Finance « Modélisation SysML »,

https://uml.developpez.com/cours/Modelisation-SysML/, Publié le 27 décembre 2010 ;

o Khalid Kouiss « Cours IS » Master exécutif UM6P

o Jean-Yves BRON, "System Requirements Engineering - A SysML Supported

Requirements Engineering Method", ISTE Press - Elsevier, 2020,

o Caignot, V. Crespel, M. Dérumaux, C. Garreau, P. Kaszynski, B. Martin & S. Roux,

« Sciences industrielles de l’ingenieur, MPSI•PCSI•PTSI » , ISBN : 978-2-311-01305-4 ©
Vuibert – août 2013.

o AFIS – « Découvrir et comprendre l’Ingénierie Système » - 2012 – ISBN

9782364930056

o AFIS – Association Française d’Ingénierie Système – www.afis.fr

o INCOSE – International Council on Systems Engineering – www.incose.org

39