REQ
Notation d'une exigence et informations associées
Une exigence "spécifie une capacité ou une condition qui doit (ou devrait) être satisfaite" [SysML].
Elle peut spécifier une fonction à réaliser ou des critères de performance à satisfaire.
Cet exemple de notation illustre les attributs de base d'une exigence.
ID : Un identifiant unique pour l'exigence
Text : Une description textuelle de ce qui est requis.
Les utilisateurs peuvent créer des stéréotypes et des balises pour ajouter des propriétés spécifiques, par exemple :
type d'exigence (performance, sécurité, fonctionnel, etc.)
la priorité (par exemple : haute, moyenne, basse)
la source ou l'origine (par exemple : client, marketing, technique, législation, etc.)
le risque associé à cette exigence (par exemple : haut, moyen, bas) - concept souvent lié à la criticité
le statut (par exemple : proposée, validée, implémentée, testée, livrée, etc.) - ce dernier est souvent précisé en cours de projet
la méthode de vérification (par exemple : analyse, démonstration, test, etc.)
Relations entre exigences
Dans l'exemple ci-dessus, deux types de relation importants sont à noter :
Une relation « dérivée » (
derive) est une dépendance entre deux exigences (une exigence dérivée et une exigence source), où l'exigence dérivée est générée ou déduite de l'exigence source.Une relation « de raffinement » (
refine) est une dépendance qui décrit comment un élément de modèle ou un ensemble d'éléments raffine une exigence. Par exemple, ici, le cas d'utilisation « moudre la café » vient raffiner l'exigence fonctionnelle de café fraichement moulu.
Un dernier type de lien entre exigences est également utilisé. Il s'agit du lien de contenance et est représentée par une ligne terminée par un cercle contenant une croix du côté du conteneur 
. Ce lien permet de décomposer une exigence composite en plusieurs exigences unitaires.
Exploitation des exigences
L'exploitation des exigences peut ensuite se faire sous une forme arborescente ou sous la forme d'un tableau.
Imbrication des exigences entre elles et niveau de détails attendus
L'exemple ci-dessus illustre les différents niveaux de détails qu'il est parfois nécessaire de préciser pour aller du plus général (attentes des différentes parties prenantes) aux exigences liées aux sous-systèmes, en passant par les exigences liées au système à concevoir.
Il est courant de définir d’autres propriétés pour les exigences, par exemple :
la priorité (par exemple : haute, moyenne, basse)
la source ou l'origine (par exemple : client, marketing, technique, législation, etc.)
le risque associé à cette exigence (par exemple : haut, moyen, bas)
le statut (par exemple : proposée, validée, implémentée, testée, livrée, etc.) - ce dernier est souvent précisé en cours de projet
la méthode de vérification (par exemple : analyse, démonstration, test, etc.)
Navigation :
Compléments :