VPasCode (Diagram en code) pour le diagramme de exigences SysML — Un guide complet

1. Qu’est-ce qu’un diagramme d’exigences ?

Un diagramme d’exigences est un type de diagramme SysML dont le seul objectif est de capturer les exigences comme des éléments de modèle de première classe et rendre leurs relations explicites et traçables. Contrairement à un document d’exigences (qui n’est qu’une liste), un diagramme d’exigences est un graphe: les exigences sont des nœuds, et les relations entre elles — containment, dérivation, satisfaction, vérification et traçabilité — sont des arêtes.

L’idée fondamentale est la traçabilité. Dans un système informatique, une exigence ne vit pas en isolation. Un besoin d’un acteur clé pousse une exigence du système ; cette exigence est satisfaite par un bloc architectural ; un cas de test la vérifie ; et elle peut être affinée en sous-exigences. Le diagramme d’exigences rend chaque lien visible et vérifiable. C’est ce qui transforme un tableau plat en un modèle.

Pourquoi l’utiliser pour les systèmes informatiques ?

Les projets informatiques sont notoirement connus pour dérive des exigences — dérive de portée, changements non maîtrisés, et le problème « nous l’avons construit mais personne ne l’avait demandé ». Un diagramme d’exigences aide car il vous permet de :

• Remonter la traçabilité — « Pourquoi ce composant existe-t-il ? » → suivre les liens satisfairejusqu’à l’exigence, et dérivé se connecte au besoin métier.
• Traçabilité vers l’avant — « Ce besoin est-il vérifié ? » → suivrevérifier se connecte aux cas de test.
• Évaluer l’impact des modifications — « Si ce besoin change, qu’est-ce qui est affecté ? » → suivre chaque arête entrante et sortante.
• Prouver la couverture — chaque besoin doit être satisfait parquelque chose et vérifié parquelque chose. Les besoins orphelins sont immédiatement visibles.

2. Concepts clés et notation

2.1 L’élément de besoin

Un besoin est représenté par un rectangle avec unnom, unID unique(typiquement hiérarchique, comme 1.2.3), et texte de exigence. Le stéréotype est «exigence».

Les exigences peuvent contenir propriétés — attributs formellement modélisés tels que source, risque, priorité, état, ou méthode de vérification. Cela rend une exigence mesurable plutôt que vague.

2.2 Les relations (le cœur du schéma)

La règle essentielle : Une relation n’est jamais tracée vers le besoin dont elle dérive Chaîne d’identification — elle est tracée vers l’élément dont elle dérive alias. Et si le besoin A contient le besoin B, vous devez ne pas également tracer une «dériver» entre eux dans n’importe quel sens ; la contenance et la dérivation sont mutuellement exclusives pour la même paire.

2.3 Blocs, cas de test et sources de raffinement

• Bloc («bloc»): l’élément de conception qui satisfait les exigences. Dans un contexte informatique, il s’agit de votre composant architectural — un service, un module ou une API.
• Cas de test («casDeTest»): l’unité de vérification.
• Sources de raffinement: cas d’utilisation, activités ou tout élément de modèle qui précise une exigence.

Note de notation : les flèches de relation ont des têtes spécifiques (la «satisfait» flèche, par exemple, s’ouvre vers l’exigence à satisfaire). Lorsqu’on écrit à leur sujet dans un texte, il faut toujours citer le stéréotype — écrire `«satisfait»` — afin qu’elle ne soit pas interprétée par le parseur Markdown du lecteur.

3. Exemples de diagrammes

Exemple 1 — Une hiérarchie fondamentale des exigences

Cet exemple montre la containment et la dérivation, le squelette avec lequel commence tout diagramme d’exigences. Une exigence de performance de niveau supérieur se décompose en sous-exigences mesurables.

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType DiagrammeExigences
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title Hiérarchie des exigences de performance du véhicule

$requirement("Performance du véhicule", ReqVehiclePerf, "1", "Le véhicule doit atteindre les objectifs de performance spécifiés dans des conditions d'exploitation normales.")
$requirement("Accélération", ReqAccel, "1.1", "Le véhicule doit passer de 0 à 100 km/h en moins de 6 secondes.")
$requirement("Vitesse maximale", ReqTopSpeed, "1.2", "Le véhicule doit atteindre une vitesse maximale d'au moins 220 km/h.")
$requirement("Freinage", ReqBraking, "1.3", "Le véhicule doit s'arrêter à partir de 100 km/h en moins de 38 mètres sur une chaussée sèche.")
$requirement("Efficacité énergétique", ReqFuel, "1.4", "Le véhicule doit atteindre au moins 15 km/l sur le cycle combiné.")

$containment(ReqVehiclePerf, ReqAccel)
$containment(ReqVehiclePerf, ReqTopSpeed)
$containment(ReqVehiclePerf, ReqBraking)
$containment(ReqVehiclePerf, ReqFuel)
$deriveReqt(ReqBraking, ReqVehiclePerf)
@enduml

Lecture : Accélération, Vitesse maximale, Freinage, et Efficacité du carburant sont tous des parties de la exigence globale Performance du véhicule exigence (contenement). Freinage est également dérivé de lui, ce qui signifie qu’il a été décomposé en un objectif concret et mesurable.

Exemple 2 — Satisfaction et vérification (le design répond aux exigences)

Cela ajoute le côté conception. Les composants architecturaux satisfontles exigences, et les cas de test vérifientcelles-ci. C’est le diagramme que vous montrez lors d’une revue de conception.

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType DiagrammeDeRequisits
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title Système de paiement — Satisfaction et vérification

$requirement("Conformité PCI-DSS", ReqPci, "3", "Le système ne doit pas stocker les valeurs de vérification de carte et doit chiffrer les données du titulaire de carte au repos.")
$requirement("Traiter le paiement", ReqPay, "3.1", "Le système doit autoriser un paiement client dans un délai de 3 secondes.")
$requirement("Charge idempotente", ReqIdem, "3.2", "Le système ne doit pas facturer deux fois un client en cas de réessai.")

$block("PaymentService", PaymentService)
$block("VaultService", VaultService)

$testCase("Audit PCI", TAudit)
$testCase("Test de latence", TLatency)
$testCase("Test d'idempotence", TIdem)

$containment(ReqPci, ReqPay)
$containment(ReqPci, ReqIdem)

$satisfy(PaymentService, ReqPay)
$satisfy(VaultService, ReqPci)

$verify(TAudit, ReqPci)
$verify(TLatency, ReqPay)
$verify(TIdem, ReqIdem)
@enduml

En le lisant : PaymentService satisfait la exigence de traitement des paiements, tandis que VaultService satisfait l’exigence plus large PCI-DSS. Chaque exigence est vérifiée par un cas de test. Remarquez les directions des flèches :`«satisfait»` pointe du bloc vers l’exigence qu’il remplit ;`«vérifie»` pointe du cas de test vers l’exigence qu’il prouve.

Exemple 3 — Chaîne complète de traçabilité du système informatique

C’est le diagramme que vous utiliseriez pour suivre une nécessité métier jusqu’à la vérification — la question classique « pourquoi ce code existe-t-il ? ».

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType DiagrammeDeRequisits
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title Système E-Commerce — Traçabilité des exigences

$requirement("Affaire : Réduire les paniers abandonnés", ReqBiz, "B1", "L'entreprise doit réduire les paniers abandonnés de 15 % dans les deux prochains trimestres.")
$requirement("Expérience utilisateur du paiement", ReqUx, "S1", "Le système doit permettre à un invité de finaliser le paiement en moins de 5 étapes.")
$requirement("Réapprovisionnement en un clic", ReqReorder, "S2", "Le système doit permettre à un client récurrent de réacheter un achat antérieur en une seule action.")
$requirement("Résidence des données", ReqResidency, "S3", "Le système doit stocker les données des clients européens au sein des régions européennes.")

$block("InterfacePaiement", CheckoutUI)
$block("ServiceRéapprovisionnement", ReorderService)
$block("BaseDeDonnéesRégionale", RegionalDatastore)

$testCase("Test du flux de paiement", TCheckout)
$testCase("Test de réapprovisionnement", TReorder)
$testCase("Audit de résidence", TResidency)

$containment(ReqBiz, ReqUx)
$containment(ReqBiz, ReqReorder)
$deriveReqt(ReqUx, ReqBiz)
$deriveReqt(ReqReorder, ReqBiz)

$satisfy(CheckoutUI, ReqUx)
$satisfy(ReorderService, ReqReorder)
$satisfy(RegionalDatastore, ReqResidency)

$verify(TCheckout, ReqUx)
$verify(TReorder, ReqReorder)
$verify(TResidency, ReqResidency)

$trace(ReqResidency, ReqBiz)
@enduml

En le lisant : L’exigence métier B1 ancre tout le reste. Les exigences système S1 et S2 sont dérivées de elle (le « pourquoi »), tandis que S3 (résidence des données) est une traçable contrainte liée uniquement par `«trace»`. Chaque exigence système est satisfaite par un composant et vérifié par un test. Si B1change, ce diagramme vous indique instantanément quels composants et tests sont concernés.

4. Comment en construire un (flux de travail pratique)

1. Commencez par le besoin de niveau supérieur. Normalement une exigence métier ou d’un intervenant. Donnez-lui un espace d’identification clair (par exemple B* pour les affaires, S* pour le système).
2. Décomposez vers le bas avec une containment. Divisez les grandes exigences en exigences plus petites, mesurablesdes exigences. Un bon texte d’exigence contient un nombre (« en moins de 3 secondes », « 15 % », « dans les régions de l’UE »).
3. Ajoutez des liens de dérivation là où un enfant est une reformulation concrète, et non pas simplement une partie. Souvenez-vous : une paire peut être reliée par une containment ouou par dérivation, jamais les deux à la fois.
4. Mapper la conception aux exigences avec satisfaire. Chaque bloc architectural doit satisfaire au moins une exigence. Les blocs qui ne satisfont rien sont des candidats à la suppression ; les exigences satisfaites par rien sont des lacunes de couverture.
5. Mapper les tests avec vérifier. Chaque exigence nécessite un chemin de vérification. Les exigences vérifiées par rien sont non testables — un signal d’alerte rouge.
6. Utilisez traçage uniquement lorsque rien d’autre ne convient. C’est la porte de sortie pour les associations floues ; son usage excessif réduit sa valeur.
7. Gardez-le sous environ 24 éléments. Les grands diagrammes deviennent illisibles. Divisez-les par sous-système ou par catégorie d’exigence (sécurité, performance, fonctionnelle).

Les trois questions de couverture

Appliquez cette liste de vérification à chaque diagramme d’exigence :

• Chaque exigence est-elle satisfaite ? (si c’est une exigence système, quelque chose doit la réaliser)
• Chaque exigence est-elle vérifiée ? (quelque chose doit la prouver)
• Chaque exigence remonte jusqu’à un besoin ? (pas d’exigences orphelines flottant sans justification métier)

Tout « non » est une constatation.

5. Application aux systèmes informatiques — Modèles et pièges

Bonnes pratiques

• Exigence distincte types visuellement. Vous pouvez stéréotyper les exigences («fonctionnel», «performance», «sécurité», «ergonomie») afin que les exigences non fonctionnelles se distinguent des exigences fonctionnelles.
• Gardez la hiérarchie des identifiants significative. 2.3.4 doit indiquer à un lecteur que cette exigence se trouve sous le module 2, la fonctionnalité 3, la sous-fonctionnalité 4. La cohérence entre les diagrammes et votre outil ALM est importante.
• Modélisez la source. Ajoutez une source propriété (réglementaire, nom du partie prenante, document des exigences du marché). Traçabilité vers origine est souvent plus important que la traçabilité vers la conception.
• Un diagramme, une préoccupation. Un diagramme de satisfaction (revue de conception) et un diagramme de vérification (revue de test) ont des publics différents. N’essayez pas de tout regrouper dans une seule image, y compris les deux et toute la hiérarchie.

Péchés courants

• Confusion entre dérivation et containment. Ils ont l’air similaires mais signifient des choses différentes. Le containment est décomposition structurelle; la dérivation est évolution logique de l’intention. Les mélanger (ou les dessiner tous deux entre une paire) rend le modèle invalide.
• Référence par ID au lieu de l’alias. Dans l’outil, les relations sont liées à l’élément alias, et non aux chaînes d’ID lisibles par l’humain. Obtenez l’alias correct, sinon la relation cible silencieusement rien.
• Traiter traçage comme satisfaire. Un lien de traçage ne prétend pas que la cible remplisse quoi que ce soit. Si vous voulez dire « ce composant implémente cette exigence », utilisez `«satisfaire»`.
• Exigences sans numéro. « Le système doit être rapide » ne peut pas être vérifié. Une exigence sans seuil mesurable est un souhait, pas une exigence.
• Laisser le diagramme devenir la spécification. Le diagramme montre relations; l’exigence texte et propriétés portent les détails. Gardez le texte précis et attachez des propriétés (état, priorité, risque) afin que le modèle soit interrogeable.

6. Outils

Vous pouvez rendre ces diagrammes directement à partir de la source PlantUML indiquée ci-dessus en utilisant VPasCode — collez le code, et le diagramme s’affiche immédiatement. À partir de là, vous pouvez également l’exporter ou le modifier.

Référence rapide : macros d’éléments et de relations

$requirement("Nom", alias, "id", "Texte de la exigence")
$block("NomBloc", alias)
$testCase("NomCasTest", alias)

$containment(aliasParent, aliasEnfant)
$deriveReqt(aliasEnfant, aliasParent)
$satisfy(aliasBloc, aliasExigence)
$verify(aliasCasTest, aliasExigence)
$refine(aliasModèle, aliasExigence)
$trace(aliasSource, aliasCible)
$copy(aliasSource, aliasCible)

Résumé

Un diagramme d’exigences est le cœur de traçabilité d’un modèle. Pour les systèmes informatiques, il répond aux trois questions posées à chaque audit, revue de conception ou demande de modification : Pourquoi cela existe-t-il ? Qu’est-ce qui l’implémente ? Qu’est-ce qui le prouve ? Utilisé correctement — avec des textes d’exigences mesurables, des sémantiques de relations correctes et des vérifications rigoureuses de couverture — il transforme les exigences d’un document statique en un modèle vivant et interrogeable, qui maintient la conception, le code et les tests alignés sur l’intention métier.

Référence

1. VPasCode : Génération de diagrammes assistée par IA au format Diagramme-en-Code avec PlantUML, Mermaid et Graphviz: Guide officiel couvrant la génération de diagrammes assistée par IA, les flux de modification et le support multi-DSL incluant PlantUML, Mermaid et Graphviz.
2. Visual Paradigm VPasCode : Guide complet: Aperçu détaillé des fonctionnalités de VPasCode, des utilisateurs ciblés (développeurs, architectes, analystes) et de son rôle dans les flux de documentation Agile.
3. Bienvenue sur Visual Paradigm VPasCode : Le passage au Diagramme-en-Code (DaC): Introduction à la plateforme unifiée, expliquant les avantages des flux de travail texte-vers-diagramme et de l’ingénierie automatique des mises en page.
4. Guide de démarrage rapide en 60 secondes | Guide VPasCode : Texte vers diagramme: Parcours étape par étape pour créer, personnaliser et exporter des diagrammes à l’aide de l’éditeur basé sur navigateur avec aperçu en temps réel.
5. Nouveau dans VPasCode : Générateur de diagrammes de profil UML par IA: Mise à jour produit présentant la génération de diagrammes de profil UML par IA à l’aide de prompts en anglais courant, avec un exemple pour la conformité à la confidentialité des données de santé.
6. Génération native de diagrammes par IA dans Visual Paradigm VPasCode: Annonce des capacités intégrées d’IA pour générer, modifier et corriger des diagrammes via des prompts en langage naturel directement dans l’éditeur.
7. Générateur de diagrammes et outils de productivité alimentés par l’IA | VPasCode: Aperçu des intégrations de VPasCode avec les chatbots IA, Visual Paradigm Desktop et OpenDocs pour des pipelines de documentation optimisés.
8. Meilleurs alternatives à PlantUML et éditeurs gratuits de diagrammes en code: Matrice de comparaison des alternatives à PlantUML, mettant en évidence le support multi-DSL de VPasCode, ses fonctionnalités IA et son approche sans configuration basée sur navigateur.
9. Éditeur de diagrammes en code : transformez du texte en diagramme instantanément: Aperçu des fonctionnalités couvrant la détection automatique du format, le rendu en temps réel et les options d’exportation multi-format (SVG, PNG, PDF).
10. Guide de l’écosystème Visual Paradigm: Explique quand utiliser VPasCode plutôt que VP Desktop, avec des conseils sur la maintenance des diagrammes sous contrôle de version et l’intégration avec la documentation vivante.

Cette publication est également disponible en Deutsch, English, Español, فارسی, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 : liste des langues séparées par une virgule, 繁體中文 : dernière langue.