SysML要件図のためのVPasCode（図としてのコード）—包括的なガイド

1. 要件図とは何か？

「要件図」は、単一の目的として「要件をファーストクラスのモデル要素として捉え、それらの関係を明確かつ追跡可能にすること」であるSysML図の一種です。。要件ドキュメント（単なるリストに過ぎない）とは異なり、要件図は「グラフ」です。要件はノードであり、それらの間の関係（包含、導出、充足、検証、追跡可能性）はエッジとなります。

核となる概念は「追跡可能性」です。ITシステムにおいて、要件は孤立して存在するものではありません。ステークホルダーのニーズがシステム要件を駆動し、その要件はアーキテクチャブロックによって充足され、テストケースによって検証され、さらにサブ要件に細分化されることもあります。要件図は、それらすべてのリンクを可視化し監査可能にします。これこそが、単なるフラットなスプレッドシートをモデルへと変える要因です。

なぜITシステムでこれを使用するのか？

ITプロジェクトは「要件のズレ」で有名です。— スコープの蔓延、管理されていない変更、そして「作ったが誰も求めていなかった」という問題。要件図は、以下ができるようになるため役立ちます：

• 遡って追跡 — 「なぜこのコンポーネントが存在するのか？」→「充足」リンクを追跡して要件に至り、導出」リンクを追跡してビジネスニーズに至る。

• 先へ追跡 — 「この要件は検証されたか？」→「検証」リンクを追跡してテストケースに至る。

• 変更影響を評価 — 「この要件が変更された場合、他に何に影響するか？」→ 入ってくるすべてのエッジと出ていくすべてのエッジを追跡する。

• 網羅性を証明 — すべての要件は「何か および「何か。孤立要件は直ちに視認可能です。

2. 主要概念と記法

2.1 要件要素

要件は、名称、一意のID（通常は階層的で、1.2.3）、および要件テキストです。ステレオタイプは«requirement».

要件にはプロパティ（形式化された属性、例えばソース, リスク, 優先度, ステータス、または検証方法が含まれます。これらは要件を測定可能あいまいであるのではなく。

2.2 関係（図の核心）

重要なルール：関係は要件のID 文字列 — 要素のエイリアスに描かれます。要件 A が要件 B を含む場合、の両方向に「派生」関係を描いてはいけません。包含と派生は、同じペアに対して排他的です。

2.3 ブロック、テストケース、および詳細化ソース

• ブロック («block»）：要件を満たす設計要素です。IT の文脈では、これはアーキテクチャコンポーネント（サービス、モジュール、または API）です。

• テストケース («testCase»）：検証単位です。

• 詳細化ソース：要件を詳細化するユースケース、アクティビティ、または任意のモデル要素。

表記に関する注記：関係矢印には特定の矢頭があります（例えば、«satisfy»矢印は、満たされる要件の方向に開きます）。文章でこれらについて記述する際は、常にステレオタイプを引用してください — `«satisfy»`と記述してください。そうしないと、読者の Markdown パーサーに埋もれてしまうためです。

3. ダイアグラムの例

例 1 — 基盤となる要件階層

この例は、すべての要件図の骨格となる包含と派生を示しています。上位レベルのパフォーマンス要件は、測定可能なサブ要件に分解されます。

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

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

title 車両パフォーマンス要件階層

$requirement("車両パフォーマンス", ReqVehiclePerf, "1", "車両は、定格運転条件下で指定されたパフォーマンス目標を満たさなければならない。")
$requirement("加速", ReqAccel, "1.1", "車両は、0から100 km/hまで6秒未満で加速しなければならない。")
$requirement("最高速度", ReqTopSpeed, "1.2", "車両は、少なくとも220 km/hの最高速度に達しなければならない。")
$requirement("制動", ReqBraking, "1.3", "車両は、乾燥した舗装路で100 km/hから38メートル未満で停止しなければならない。")
$requirement("燃費", ReqFuel, "1.4", "車両は、複合サイクルで少なくとも15 km/lの燃費を達成しなければならない。")

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

読み取ると： 加速, 最高速度, 制動、および燃費はすべての一部である上位の車両パフォーマンス要件（包含）である。制動はまた派生しており、つまり具体的な測定可能な目標として分解されたことを意味する。

例2 — 充足と検証（設計が要件を満たす）

これにより設計側が追加される。アーキテクチャコンポーネントは要件を充足し、テストケースは検証するそれらです。これは設計レビューで提示する図です。

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

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

title 決済システム — 充足と検証

$requirement("PCI-DSS 準拠", ReqPci, "3", "システムはカード検証値を保存してはならず、保存中のカード保有者データを暗号化しなければならない。")
$requirement("決済処理", ReqPay, "3.1", "システムは顧客の決済を 3 秒以内に承認しなければならない。")
$requirement("冪等課金", ReqIdem, "3.2", "システムは再試行時に顧客に二重課金してはならない。")

$block("決済サービス", PaymentService)
$block("Vault サービス", VaultService)

$testCase("PCI 監査", TAudit)
$testCase("レイテンシテスト", TLatency)
$testCase("冪等性テスト", TIdem)

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

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

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

読み解くと： 決済サービス 充足する決済処理要件を満たしますが、一方でVault サービス 充足するより広範な PCI-DSS 要件を満たします。各要件は検証されますテストケースによって行われます。矢印の方向に注意してください：`«satisfy»`は、ブロックからその要件を満たす方向へ指します；`«verify»`は、テストケースからその要件を検証する方向へ指します。

例 3 — 完全な IT システムトレーサビリティチェーン

これは、ビジネス上の要求から検証に至るまでを追跡するために使用する図です— これは古典的な「なぜこのコードが存在するのか？」という問いに対応するものです。

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

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

title E コマースシステム — 要件トレーサビリティ

$requirement("ビジネス：カート放棄の削減", ReqBiz, "B1", "ビジネスは 2 四半期以内にカート放棄を 15% 削減しなければならない。")
$requirement("チェックアウト UX", ReqUx, "S1", "システムはゲストが 5 ステップ未満でチェックアウトを完了できるようにしなければならない。")
$requirement("ワンクリック再注文", ReqReorder, "S2", "システムはリピート顧客が過去の購入をワンアクションで再注文できるようにしなければならない。")
$requirement("データ所在地", ReqResidency, "S3", "システムは EU 顧客データを EU 地域内に保存しなければならない。")

$block("チェックアウト UI", CheckoutUI)
$block("再注文サービス", ReorderService)
$block("地域データストア", RegionalDatastore)

$testCase("チェックアウトフローテスト", TCheckout)
$testCase("再注文テスト", TReorder)
$testCase("所在地監査", 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

それを読むと： ビジネス要件 B1 がすべての基礎となります。システム要件 S1 および S2 は 導出される それ（「なぜ」）から導出されるが、一方で S3データ所在地）はトレーサブルな 制約であり、`«trace»` で結ばれている。各システム要件は コンポーネントによって満たされ、テストによって検証される。もし B1 が変更された場合、この図は即座にどのコンポーネントとテストが対象範囲に含まれるかを示す。

4. 1 つの構築方法（実践的なワークフロー）

1. 最上位の必要性から始める。 通常はビジネス要件またはステークホルダー要件である。明確な ID 空間を与える（例： B* をビジネス用として、S*システムのため）。

2. 包含関係を用いて下位へ分解する。大きな要件をより小さな、測定可能なものに分ける。良い要件記述には数値が含まれている（「3 秒未満」、「15%」、「EU 地域内」など）。

3. 子が具体的な再述である場合に導出リンクを追加する単なる一部ではなく。覚えておこう：ペアは包含関係で結合されるまたは導出関係で結合されるが、両方同時に結合されることはない。

4. 設計を要件に「満たす」でマッピングする満たす.各アーキテクチャブロックは少なくとも一つの要件を満たす必要がある。何も満たさないブロックは削除候補であり、何も満たしていない要件はカバレッジの欠落である。

5. テストを「検証」でマッピングする検証.すべての要件には検証経路が必要である。何も検証していない要件は検証不可能であり、これは危険信号である。

6. 「追跡」を追跡は、他に適切な方法がない場合のみ使用すること。これは緩い関連付けのための脱出口である；使いすぎると価値が薄れる。

7. 要素数は約24個未満に抑えること。大きな図は読みづらくなる。サブシステム別、または要件カテゴリ別（セキュリティ、パフォーマンス、機能別）に分割すること。

3 つのカバレッジ質問

すべての要件図に対してこのチェックリストを実行すること：

• すべての要件が満たされているか？（システム要件の場合、それを実現する何かが存在する必要がある）

• すべての要件が検証されているか？（それを証明する何かが存在する必要がある）

• すべての要件がニーズまで遡れるか？（ビジネス上の正当化がないまま浮遊する孤児要件がないこと）

「いいえ」はすべて不適合事項となります。

5. IT システムへの適用 — パターンと落とし穴

ベストプラクティス

• 要件を分離するタイプ視覚的に。要件にステレオタイプを付与できます（«機能的», «性能», «セキュリティ», «ユーザビリティ»）非機能要件が機能要件と区別されるようにします。

• ID の階層構造は意味のあるものに保ちます。 2.3.4これは、この要件がモジュール 2、機能 3、サブ機能 4 の下に位置することを読者に伝えるべきです。図面間および ALM ツール全体での一貫性が重要です。

• ソースをモデル化します。「ソース」プロパティ（規制、利害関係者名、市場要件ドキュメント）を追加します。トレーサビリティは「起源」へのトレーサビリティの方が、設計へのトレーサビリティよりも重要であることが多いです。

• 1 つの図、1 つの関心事。満足度図（設計レビュー）と検証図（テストレビュー）は異なる対象者向けです。両方と階層全体を1つの画像に詰め込まないでください。

一般的な落とし穴

• 導出と包含の混同。見た目は似ていますが、意味は異なります。包含とは「構造的分解; 導出は 論理的進化の意図です。これらを混在させる（またはペア間に両方を描画する）と、モデルが無効になります。

• エイリアスではなく ID で参照すること。ツールでは、関係は要素にバインドされますが、エイリアスではなく、人間が読みやすい ID 文字列ではありません。エイリアスを正しく設定しないと、関係は静かに何も対象としなくなります。

• 「トレーサビリティ」を「満足.トレーサビリティリンクは、対象が何かを満たすと主張するものではありません。「このコンポーネントはこの要件を実装する」と言いたい場合は、「`«satisfy»`.

• 番号のない要件。「システムは高速でなければならない」とは検証できません。測定可能な閾値のない要件は、願望であり、要件ではありません。

• 図面を仕様として扱うこと。図は「関係」を示しますが、要件「テキストとプロパティ」に詳細が含まれます。テキストは正確に保ち、プロパティ（ステータス、優先度、リスク）を付与して、モデルを検索可能にしてください。

6. ツール

上記の PlantUML ソースから、VPasCodeを使用して、これらの図を直接レンダリングできます。コードを貼り付けるだけで、図が即座にレンダリングされます。そこからエクスポートしたり、さらに洗練することもできます。

クイックリファレンス：要素および関係のマクロ

$requirement("Name", alias, "id", "Requirement text")
$block("BlockName", alias)
$testCase("TestCaseName", alias)

$containment(parentAlias, childAlias)
$deriveReqt(childAlias, parentAlias)
$satisfy(blockAlias, requirementAlias)
$verify(testCaseAlias, requirementAlias)
$refine(modelAlias, requirementAlias)
$trace(fromAlias, toAlias)
$copy(fromAlias, toAlias)

概要

要件図は、トレーサビリティの骨格モデルの基盤です。IT システムにおいて、これはすべての監査、設計レビュー、変更要求が問う 3 つの質問に答えます：なぜこれが存在するのか？何を以て実装されているのか？何を以て証明されるのか？適切に使用されれば（測定可能な要件テキスト、正しい関係セマンティクス、規律あるカバレッジチェックを伴って）、要件を静的な文書から、設計、コード、テストをビジネスの意図と一致させる、生きたクエリ可能なモデルへと変換します。

参照

1. VPasCode: PlantUML、Mermaid、Graphviz を活用した AI 支援型 Diagram-as-Code: AI 支援による図の生成、変更ワークフロー、PlantUML、Mermaid、Graphviz を含むマルチ DSL サポートを網羅した公式ガイド。
2. Visual Paradigm VPasCode: 包括的ガイド: VPasCode の機能、対象ユーザー（開発者、アーキテクト、アナリスト）、アジャイルドキュメンテーションワークフローにおける役割の詳細な概要。
3. Visual Paradigm VPasCode へようこそ：Diagram-as-Code (DaC) への転換: 統合プラットフォームの紹介。テキストから図への変換ワークフローと自動レイアウトエンジニアリングの利点を解説。
4. 60 秒クイックスタートガイド | VPasCode テキストから図への変換ガイド: ライブプレビュー機能を備えたブラウザベースのエディタを使用して、図の作成、カスタマイズ、エクスポートを行うためのステップバイステップのチュートリアル。
5. VPasCode の新機能：AI 搭載 UML プロファイル図生成器: 自然な英語のプロンプトを使用して AI 搭載で UML プロファイル図を生成する機能を導入した製品アップデート。医療データのプライバシーコンプライアンスに関する例付き。
6. Visual Paradigm VPasCode におけるネイティブ AI 図生成: エディタ内で自然言語プロンプトを通じて図の生成、変更、修正を行うための組み込み AI 機能の発表。
7. AI 搭載図生成器と生産性ツール | VPasCode: AI チャットボット、Visual Paradigm Desktop、OpenDocs との VPasCode 統合の概要。これによりドキュメンテーションパイプラインが効率化されます。
8. PlantUML の代替ツールと無料の Diagram-as-Code エディタ: PlantUML の代替ツール比較マトリックス。VPasCode のマルチ DSL サポート、AI 機能、ブラウザベースのゼロ設定アプローチを強調。
9. Diagram-as-Code エディタ：テキストを瞬時に図に変換: 自動フォーマット検出、リアルタイムレンダリング、マルチフォーマットエクスポートオプション（SVG、PNG、PDF）を網羅した機能概要。
10. Visual Paradigm エコシステムガイド: VPasCode と VP Desktop の使い分けを解説。バージョン管理された図の保守や、生きたドキュメンテーションとの統合に関するガイダンスを提供。