SysML : le diagramme d'exigence (requirement diagram)

sysml-exemple-diagramme-d-exigence-requirement-diagram-example-59.png

Une exigence spécifie un besoin ou une règle qui doit être satisfaite.

Une exigence peut spécifier une fonction qu'un système doit exécuter ou des critères de performance à atteindre.

SysML fournit des éléments pour représenter des exigences textuelles et les relier à d'autres éléments de modélisation.

Le diagramme d'exigences décrit les exigences de manière graphique, tabulaire, ou arborescente.

Une exigence peut aussi figurer sur d'autres diagrammes pour montrer sa relation à d'autres éléments de modélisation.

La modélisation des exigences est destinée à fournir une passerelle entre des outils de gestion d'exigences traditionnels et les autres modèles SysML.

Une exigence est définie comme un stéréotype <<requirement>> de classe UML soumise à un ensemble de contraintes.

Une exigence standard inclut les propriétés pour spécifier son identifiant unique (id) et sa description textuelle (text).

Les propriétés supplémentaires comme le statut de vérification, peuvent être spécifiées par l'utilisateur.

Plusieurs relations d'exigences sont spécifiées qui permet au modélisateur de relier des exigences à d'autres exigences aussi bien qu'à d'autres éléments de modèles.

On trouve des relations pour définir une hiérarchie d'exigences, des exigences dérivées (<<deriveReqt>>), des exigences satisfaites par d'autres éléments du modèle (<<satisfy>>), des scénarios de tests vérifiant des exigences (<<verify>>) et des exigences affinées (<<refine>>).

Une exigence composite (relation de composition UML) peut contenir des sous-exigences dans une hiérarchie d'exigences, on utilise alors la syntaxe des "namespace" UML.

Cette relation permet à une exigence complexe d'être décomposée avec des exigences enfants.

Une spécification entière peut être décomposée en sous exigences, qui peuvent être elles mêmes décomposées et ainsi de suite pour définir la hiérarchie d'exigences.

On pourra ainsi réutiliser des exigence dans d'autres produits ou projets.

Les scénarios typiques sont des exigences réglementaires, statutaires, ou contractuelles applicables à des produits et à des projets.

On doit pouvoir faire référence à une exigence qui peut donc se trouver dans des contextes multiples ou bien mettre à jour l'exigence d'origine et propager les modification aux exigence réutilisées.

Puisque le concept de réutilisation d'exigences est très important dans beaucoup d'applications, SysML présente le concept d'une exigence esclave. Une exigence esclave est une exigence dont la propriété de description textuelle est une copie (stéréotype <<copy>>) en lecture seule de la même propriété d'une exigence maître. La description textuelle de l'exigence esclave est contrainte pour être le même que la description textuelle de l'exigence maître liée. La relation maître/esclave est indiquée par l'utilisation de la relation de copie (stéréotype <<copy>>).

La relation <<deriveReqt>> exprime un relation logique entre une exigence de haut niveau et des sous exigences.

A partir d'une exigence source, l'analyse détermine des exigences dérivées.

Les exigences dérivées correspondent généralement aux exigences de niveau inférieur de la hiérarchie de système.

Par exemple, une exigence d'accélération de véhicule peut impliquer des exigences sur la puissance du moteur, le poids du véhicule et le coefficient de traînée.

La relation <<satisfy>> décrit comment une conception ou un modèle de mise en œuvre satisfait une ou plusieurs exigences.

Un modélisateur de système spécifie les éléments de conception du système qui sont destinés pour satisfaire l'exigence.

Dans l'exemple ci-dessus, la conception du moteur satisfait l'exigence de puissance du moteur.

La relation <<verify>> définit comment un scénario de test ou d'autres éléments de modèle vérifient une exigence.

Dans SysML, un scénario de test ou d'autres éléments de modélisation peuvent être utilisés comme un mécanisme général pour représenter n'importe laquelle des méthodes de vérification ou de simulation.

Des sous-classes supplémentaires peuvent être définies par l'utilisateur si nécessaire pour représenter des méthodes de vérification différentes.

Une propriété (verdict) peut être utilisée pour représenter le résultat de vérification d'un scénario de test.

La relation d'exigence <<refine>> peut être utilisée pour décrire comment un élément de modèle peut être utilisé pour affiner une exigence.

Par exemple, un cas d'utilisation ou un diagramme d'activité peuvent être utilisés pour affiner une exigence fonctionnelle textuelle.

Cette relation <<refine>> peut aussi être utilisé pour montrer comment une exigence textuelle détaille un élément de modèle.

Dans ce cas, une description textuelle détaillée pourrait être utilisé pour expliquer un élément modèle possédant une granularité moins fine.

Une relation d'exigence de trace générique (<<trace>>) fournit une relation universelle entre une exigence et un autre élément de modèle.

La sémantique de trace laisse de la souplesse au modélisateur car elle n'inclut aucune contrainte réelle.

En conséquence, il est recommandé que la relation de trace ne soit pas utilisée en même temps que les autres relations d'exigences décrites ci-dessus.

Un commentaire stéréotypé <<rationale>> peut représenter un algorithme, une expression de besoin, un processus ou un ensemble de règles rattachées à une relation <<satisfy>> pour justifier les exigences et servir de référence à la conception.

De la même manière on pourrait relier le commentaire stéréotypé <<rationale>> à d'autres relations comme la relation <<deriveReqt>>.

Il fournit aussi un mécanisme alternatif pour capturer la relation <<verify>> en attachant un besoin ou une règle à une relation <<satisfy>> qui fait référence à un scénario de test.

Les modélisateurs peuvent personnaliser des taxonomies d'exigences en définissant des sous-classes supplémentaires du stéréotype d'exigence.

Par exemple, un modélisateur peut vouloir définir des catégories d'exigences comme des exigences opérationnelles, fonctionnelles, non fonctionnelles, d'interface, de performance, physique, de stockage, d'activation/désactivation, de contraintes de conception et d'autres exigences spécialisées comme la fiabilité et la maintenabilité, ou encore représenter un besoin de partie prenante (sponsor) de haut niveau.

Le stéréotype permet au modélisateur d'ajouter des contraintes qui limitent les types des éléments de modèles qui peuvent être liés à la relation d'exigence <<satisfy>>.

Par exemple, une exigence fonctionnelle peut être contrainte pour qu'elle puisse seulement être satisfaite par un comportement SysML comme une activité, une machine d'état, ou une interaction.

Les éléments graphiques du diagramme de "requirement"