Mermaid.js 要件図の構文とトレーサビリティガイド

要件図は、システムアーキテクト、プロダクトマネージャ、ソフトウェアエンジニアが技術仕様、システム制約、検証テストを可視化するために使用する専門的な工学可視化ツールです。SysML（システムモデリング言語）標準に基づいており、ネイティブなrequirementDiagramエンジンを使用すると、テキストベースの宣言を使って、抽象的な設計要件を物理的なシステムコンポーネントやテストケースに直接リンクできます。

要件図の要素を理解する

要件図は主に2つの異なる構造的構成要素で構成されています：要件ブロック（ルールを指定するもの）と要素ブロック（コード、ハードウェア、またはテストスクリプトをモデル化するもの）。これらのブロックの間に関係性を描くことで、明確なトレーサビリティマトリクスを作成できます。

基本的な構文構造

すべての図はrequirementDiagram宣言ヘッダーから始まります。その後、ネストされたプロパティ、要素ブロック、方向性のある関係線を使って要件ブロックを定義します。

requirementDiagram
  requirement test_req {
    id: 1
    text: "システムは支払いを安全に処理しなければならない。"
    risk: high
    verifymethod: test
  }

完全な要件タイプ分類

すべての工学的要件が同等というわけではありません。エンジンは、仕様を視覚的かつ意味的に分類するために6つの異なるブロックキーワードを提供します。各タイプは、レンダリングされた図のボックス内で表示されるヘッダーラベルを変更します：

• requirement：標準的または一般的なシステム仕様。
• functionalRequirement：システムが実行しなければならない動作または行動機能を指定する。
• interfaceRequirement：コンポーネント間の接続ポイント、データ交換、または通信プロトコルを定義する。
• performanceRequirement：速度、スケーラビリティ、スループット、または容量などの測定可能な実行メトリクスを設定する。
• physicalRequirement：材料の制約、寸法、重量、またはハードウェアの制限を規定する。
• 設計制約: ソフトウェアの選択、アーキテクチャスタイル、フレームワーク、またはコンプライアンス基準を制限する。

要件図
  設計制約 レガシ制約 {
    id: "CON-04"
    text: "バックエンドはPHP 8.2パイプラインとの後方互換性を維持しなければならない。"
    risk: low
    verifymethod: 検査
  }

構文リファレンス：要件要素および修飾子

以下の表は、要件インタプリタがネイティブに認識する主な意味的キーワード、必須属性、分類構造を分解している。

高度な関係性とトレーサビリティリンク

要件図の主な力は、要件を実際のシステムに接続することにあります。リンクは専用の型付き矢印接続子（例：- 満たす ->）を使用して描かれ、明確な構造的意図を確立します。

サポートされている関係演算子

ユーザー定義要素および拡張属性

標準的な要件に加えて、elementキーワードを使用すると、特定のアプリケーションスクリプト、ハードウェアアイテム、またはサードパーティ製パッケージをトレースパスにマッピングできます。各elementブロックは、波かっこ内に「type:」スキーマを活用することで、カスタムのキー値メタデータプロパティを格納できます。type:スキーマを波かっこ内に配置します。

requirementDiagram
  element payment_gateway_api {
    type: "Stripe Microservice Module"
  }
  
  element compliance_audit_log {
    type: "Immutable Database Table"
  }

実世界のブループリント：複雑なECセキュリティインフラ

この包括的なブループリントは、完全な本番コンプライアンスエコシステムを追跡します。これは「contains」を介した分解を示しています。contains、パフォーマンス制約をマッピングし、satisfiesを通じてソフトウェアモジュールを接続し、verifiesループを使用して統合テストケースをマッピングします。

requirementDiagram
  
  %% 要件階層レイヤー
  requirement security_master_req {
    id: "SEC-001"
    text: "アプリケーションプラットフォームは厳格なPCI-DSS基準のコンプライアンスを維持しなければならない。"
    risk: high
    verifymethod: test
  }

  performanceRequirement checkout_speed_req {
    id: "PERF-22"
    text: "MFA暗号化認証ハンドシェイクは200ms未満でコンパイルされなければならない。"
    risk: medium
    verifymethod: analysis
  }

  interfaceRequirement secure_token_req {
    id: "INT-09"
    text: "APIデータ送信は暗号化されたJSON Web Tokens (JWT)を使用しなければならない。"
    risk: high
    verifymethod: test
  }

  %% システム要素レイヤー
  element auth_service_code {
    type: "Goバックエンドマイクロサービス"
  }

  element load_tester_script {
    type: "K6パフォーマンススクリプト"
  }

  element jwt_validator_test {
    type: "Jest統合ユニットスイート"
  }

  %% アーキテクチャ関係パス
  security_master_req - contains -> checkout_speed_req
  security_master_req - contains -> secure_token_req
  
  auth_service_code - satisfies -> secure_token_req
  load_tester_script - verifies -> checkout_speed_req
  jwt_validator_test - verifies -> secure_token_req

一般的な構文の落とし穴とシステム制約

正確なエンジニアリングマップをコンパイルする際には、パースエラーを防ぐために以下の検証パラメータを念頭に置いてください：

• 文字列には必須の二重引用符： テキストブロックとタイプ（例：text: "説明", type: "コンポーネント"）は必須で二重引用符で囲まれなければなりません。単一引用符を使用するか、文字列を引用符なしで記述するとコンパイラがクラッシュします。
• 厳格な属性構文： 中かっこ内の属性はコロンの後に直接値を使用しなければなりません（例：id: 1）。コロンを忘れたり、適切なインデントスペースなしに同じ行に記述するとエラーが発生する可能性があります。
• 値の選択は限定的です： の risk および verifymethod パラメータは明示的なシステムトークンのみを受け入れます（例：low, medium, high risk には；analysis, demonstration, inspection, test verifymethod には。カスタム値を入力すると、例としてrisk: extreme レイアウトビルダーが正常に動作しなくなります。
• 矢印のスペース整合性： 方向性の線は、演算子の周囲にスペースを空けて入力しなければなりません（例：A - satisfies -> B）。文字列を A-satisfies->B システム処理の例外を無視します。