Syntax du diagramme de requêtes Mermaid.js & Guide de traçabilité

Un diagramme de requêtes est un outil de visualisation spécialisé utilisé par les architectes système, les gestionnaires de produits et les ingénieurs logiciels pour représenter les spécifications techniques, les contraintes système et les tests de vérification. Conçu selon la norme SysML (langage de modélisation des systèmes), le moteur natifrequirementDiagram permet de relier directement les exigences de conception abstraites aux composants physiques du système et aux cas de test à l’aide de déclarations textuelles.

Comprendre les éléments du diagramme de requêtes

Un diagramme de requêtes se compose principalement de deux blocs structurels distincts :Blocs de requêtes (qui définissent les règles) etBlocs d’éléments (qui modélisent le code, le matériel ou les scripts de test). Des relations sont ensuite établies entre ces blocs afin de créer une matrice de traçabilité claire.

Structure de syntaxe de base

Chaque diagramme commence par l’en-têterequirementDiagram déclaration. Cela est suivi par la définition des blocs de requêtes avec des propriétés imbriquées, des blocs d’éléments et des lignes de relation directionnelles.

requirementDiagram
  requirement test_req {
    id: 1
    text: "Le système doit traiter les paiements de manière sécurisée."
    risk: élevé
    verifymethod: test
  }

La taxonomie complète des types de requêtes

Toutes les exigences d’ingénierie ne sont pas équivalentes. Le moteur fournit six mots-clés distincts de blocs pour classer vos spécifications de manière visuelle et sémantique. Chaque type modifie l’étiquette d’en-tête affichée à l’intérieur de la boîte du diagramme rendu :

• requirement: Une spécification système standard ou générale.
• functionalRequirement: Spécifie une action ou une capacité comportementale que le système doit exécuter.
• interfaceRequirement: Définit les points de connexion, les échanges de données ou les protocoles de communication entre les composants.
• performanceRequirement: Fixe des métriques d’exécution mesurables, telles que la vitesse, la scalabilité, le débit ou la capacité.
• physicalRequirement: Détermine les contraintes matérielles, les dimensions, le poids ou les limitations matériels.
• contrainte de conception: Restreint les choix logiciels, les styles architecturaux, les cadres ou les normes de conformité.

diagrammeDeRequis
  contrainteDeConception contrainteLegacy {
    id: "CON-04"
    text: "Le backend doit maintenir la compatibilité descendante avec les pipelines PHP 8.2."
    risk: low
    verifymethod: inspection
  }

Référence de syntaxe : Éléments et modificateurs de requête

Le tableau ci-dessous détaille les mots-clés sémantiques principaux, les attributs requis et les structures de classification reconnues nativement par l’interpréteur de requêtes.

Relations avancées et liens de traçabilité

La puissance principale d’un diagramme de besoins réside dans le rattachement des besoins aux systèmes réels. Les liens sont tracés à l’aide de connecteurs fléchés spécialisés et typés (par exemple, - satisfait ->) qui établissent une intention structurelle claire.

Opérateurs de relation pris en charge

Éléments définis par l’utilisateur et attributs étendus

En plus des exigences standards, la élémentmot-clé vous permet de mapper des scripts d’application spécifiques, des composants matériels ou des packages tiers dans vos chemins de traçage. Chaque bloc élément peut stocker des propriétés métadonnées personnalisées clé-valeur en utilisant le schéma type : à l’intérieur de ses accolades.

diagrammeDeRequisitions
  élément passerelle_paiement_api {
    type : "Module Microservice Stripe"
  }
  
  élément journal_conformité_audit {
    type : "Tableau de Base de Données Immuable"
  }

Maquette du Monde Réel : Infrastructure de Sécurité Complexes pour E-Commerce

Cette maquette complète suit un écosystème de conformité de production complet. Elle démontre la décomposition via contient, cartographie les contraintes de performance, connecte les modules logiciels via satisfait, et cartographie les cas de test d’intégration à l’aide de vérifie boucles.

diagrammeDeRequisitions
  
  %% Couche de Hiérarchie des Exigences
  exigence sécurité_master_req {
    id : "SEC-001"
    texte : "La plateforme d'application doit maintenir une conformité stricte avec la norme PCI-DSS."
    risque : élevé
    méthodeVérification : test
  }

  exigencePerformance checkout_speed_req {
    id : "PERF-22"
    texte : "Les échanges d'authentification cryptographique MFA doivent être compilés en moins de 200ms."
    risque : moyen
    méthodeVérification : analyse
  }

  exigenceInterface secure_token_req {
    id : "INT-09"
    texte : "Les transmissions de données API doivent utiliser des Jetons Web JSON (JWT) chiffrés."
    risque : élevé
    méthodeVérification : test
  }

  %% Couche des Éléments du Système
  élément auth_service_code {
    type : "Microservice Backend Go"
  }

  élément load_tester_script {
    type : "Script de Performance K6"
  }

  élément jwt_validator_test {
    type : "Suite d'Unités d'Intégration Jest"
  }

  %% Chemins de Relations Architecturales
  sécurité_master_req - contient -> checkout_speed_req
  sécurité_master_req - contient -> secure_token_req
  
  auth_service_code - satisfait -> secure_token_req
  load_tester_script - vérifie -> checkout_speed_req
  jwt_validator_test - vérifie -> secure_token_req

Péchés de Syntaxe Courants et Contraintes du Système

Lors de la compilation de cartes d’ingénierie précises, gardez ces paramètres de validation à l’esprit pour éviter les erreurs de parsing :

• Guillemets Doubles Obligatoires pour les Chaînes : Blocs de texte et types (par exemple, texte : "Description", type : "Composant") *doivent* être entourés de guillemets doubles. Utiliser des guillemets simples ou laisser les chaînes non entourées provoquera une erreur du compilateur.
• Syntaxe Stricte des Attributs : Les attributs entre accolades doivent utiliser des deux-points suivis directement de valeurs (par exemple, id: 1). Oublier le deux-points ou les écrire sur la même ligne sans espacement d’indentation approprié peut provoquer des erreurs.
• Choix de valeurs limités : Le risk et verifymethod les paramètres n’acceptent que des jetons système explicites (par exemple, low, medium, high pour risk ; analysis, demonstration, inspection, test pour verifymethod). Taper des valeurs personnalisées comme risk: extreme empêchera le constructeur de mise en page.
• Intégrité de l’espacement des flèches : Les lignes directionnelles doivent être tapées avec un espacement d’espace autour des opérateurs (par exemple, A - satisfies -> B). En compactant la chaîne en A-satisfies->B supprimera les exceptions de traitement système.