システムズエンジニアリング

システムズエンジニアリング専門家によるSysML v2徹底解説

第四回:SysML v2の新しい構成要素やその使い道を知る ― Requirement

株式会社オージス総研モデルベースシステムエンジニアリング部片山敬介

2025年8月27日

この連載では、2025年内にはリリースされる見込みのシステムモデリング言語SysML v2を取り上げ、業界での利活用に乗り遅れないために基本的な情報や新しい構成要素の紹介、今まで使っていたSysML v1とv2の変換などを紹介していきます。第四回の今回はv2で大きく変わった「Requirement」を紹介します。

SysML v2の新しい構成要素やその使い道を知る: Requirement

要求をモデリングする要素はSysML v1にもありましたが、SysML v2ではより厳密な定義や、要求と設計の意味的に厳密な割り当てが可能になりました。今回は、要求に関してモデリングできることの数々をご紹介します。

※本稿はSysML v2 beta4の仕様を参照して記述しています。
※本文中の図は（株）チェンジビジョンのastah* SysML v2 Editorで作図しています。

基本的な書き方

要求も他の要素と同様にDefinitionとUsageがあります。Definitionで要求の内容を定義し、Usageでバリエーション毎の具体的な値を持たせるような使い分けが可能です。下記の例では、「故障通知インジケーター仕様」が仕向地によって異なるさまをモデリングしています。以下のモデル例では、自動車の故障通知インジケーターに関する要求がRequirement Definitionで定義され、仕向ごとの具体的な仕様がRequirement Usageで記述されています。

package RequiremnetDefandUsageSample{
    //要求のDefinition
    requirement def malfunctionIndicatorRequirement{
        doc /* 故障通知インジケーター仕様 */
        attribute indicatorType;
    }
    //要求のUsage
    requirement USMalfunctionIndicatorRequirement : malfunctionIndicatorRequirement{
        doc /* US向け仕様 */
        attribute redefines indicatorType = "US Type";
    }
    requirement JPMalfunctionIndicatorRequirement : malfunctionIndicatorRequirement{
        doc /* 国内向け仕様 */
        attribute redefines indicatorType = "JP Type";
    }
}

要求のDefinitionとUsage

図 1: 要求のDefinitionとUsage

また要求同士の繋がりを書くことができます。下記の例では要求同士の依存関係dependencyをモデリングしています。

package RequirementRelationSaample1{
    requirement screwHoleNeeds{
        doc /* ねじを挿入する穴が欲しい */
        attribute holeDiameterMilliMeter = 5;
    }
    requirement drillNeeds{
        doc /* 穴をあけるドリルを用意する */
        attribute drillSizeMilliMeter = 5;

    }

    //要求間の関係の定義
    dependency from drillNeeds to screwHoleNeeds;
}

要求間の関係（Dependency）

図 2: 要求間の関係（Dependency）

要求に書ける項目

SysML v2では要求に書ける項目が増えています。これらは文法で定義されたものですから（独自定義でない）、各種ツールの対応・連携や各種自動化が期待できます。

shortname：Requirementに限らず要素名には短縮名をつけることができます。Requirement要素ではこのshortnameはIDとして扱われます。
doc：要求を説明する文章が書けます。
attribute：要求の持つ定量的な値などです。ツール連携、シミュレーションや検証に活用できそうです。
subject：要求の掛かる対象要素です。次項でも説明します。
Assume constraint：制約のうち前提になるもの（原理原則、物理法則など）を表します。
Require constraint：制約のうち要求されるものを表します。「制約」を要求に数式で記述できるようになったことで、モデルが要求から逸脱していないことを自動で監視する（CI/CDの利用）ことが容易になりそうです。
Actor：要求に関係する外部システム、外部環境などを表します。
Stakeholder：要求に関係する関心事（concern）を持つ利害関係者を書くことができます。concernと併せて使うことでステークホルダーの関心とそれに応えるRequirementやViewの関係をモデリングできます（これは別の機会にご紹介します）
Requirement：要求は他の要求を包含して持つことができます。

以下のモデル例では、警察官は自動車に速度の遵守を求めていること、また道路には法定速度と制限速度があることをモデリングしています。

package RequirementCompartmentsSample{
    part def Vehicle{
        attribute speed;
    }
    part def Road{
        attribute speedLimit;
    }
    part def PoliceMan;
    requirement <'RQ_0001'> vehicleSpeedRangeRequirement {   //ショートネーム<>で要求IDを記述
        doc /* 警察官は車両が速度制限を守ることを求める */
        attribute statutorySpeedLimit = 60;     //要求の属性
        subject roadVehicle : Vehicle;  //要求が掛かる対象(ここではpart usageを定義)
        stakeholder policeMan : PoliceMan;  //要求のステークホルダー
        actor road : Road{ attribute redefines speedLimit := 30; }  //要求に関係する外部環境など
        assume constraint { roadVehicle.speed >= 0 }    //前提、物理的な制約など
        require constraint{ roadVehicle.speed <= road.speedLimit }  //要求される制約
        require constraint{ roadVehicle.speed <= statutorySpeedLimit }  //要求される制約
    }
}

要求に書ける項目例

図 3: 要求に書ける項目例

要求間の関連

要求間の関連について、SysML v1ではステレオタイプによって関係の特性を描き分けられましたが、SysML v2にはステレオタイプによる描き分けはありません。SysML v2では要求に持たせられる情報が増えたため、それらを使い分けて要求自身や他の要求・要素との関係性をモデリングしていくことを企図していると考えられます。ただしModel librariesには以下の関係定義があり利用可能です。

Derivation

「導出」の関係です。Requirement Usage同士の導出の関係を定義することができます。筆者としては「依存（dependency）」でも似たような意味になるのでわざわざ使い分ける必要性は疑問です。後でツール等でDerivationだけ抽出する使い方を想定するなら、使い分ける価値があると思います。

package RequirementRelationExample{
    private import RequirementDerivation::*;    //ライブラリを使うのでimportが必要

    requirement boilWaterRequirement{
        doc /* お湯を沸かしたい */
    }
    requirement coffeeRequiremnet{
        doc /* コーヒーを淹れたい */
    }

    //derivation(導出)関係の定義
    //ライブラリに定義されたキーワードを使うには#をつける
    #derivation connection {
         end #original  ::> coffeeRequiremnet;  //導出元の要求
         end #derive ::> boilWaterRequirement;  //導出された要求
    }
}

Derivation （Model Libraryより）の使用例

図 4: Derivation （Model Libraryより）の使用例

要求とそれ以外のモデル要素の関連

SysML v1では要求とそれ以外の要素を関係づける方法は多くありませんでした。v2ではいくつかの手段が用意され、それぞれ具体的な意味づけがなされたことによって記述の正確性が向上しました。このことは機械的に要求を処理する際にも役立つはずで、ツールの連携・支援による活用が期待できます。

Subject

要求の対象要素を記述します。その要素が実際に要求を満たすかどうかは言及しません。SysML v1では要求からブロックなどの要素に割り当て《allocate》することで「この要素（機能、部品等）に対する要求である」ことを表現することがありましたがこれがv2ではSubjectで明示的に表現可能です。

package RequirementAndPartSample{
    part citizen;

    requirement taxRequirement{
        doc /* 所得税、住民税を納めること */
        subject = citizen;
    }   
}

Subjectの使用例

図 5: Subjectの使用例。ダイアグラム上でRequirementとPart（Subject）は線で接続されない。

Satisfy

要求をある要素が満たしていることを記述します。Subjectと異なり、実際に「満たしている」あるいは「満たさなければならない」ことを表します。

package RequirementAndPartSample2{
    requirement def taxRequirement{
        doc /* 所得税、住民税を納めること */       
    }   
    part goodCitizen;
    satisfy requirement req1 : taxRequirement by goodCitizen;
}

satisfyの使用例

図 6: satisfyの使用例

Allocate

割り当て（allocate）はSysML v1にもあった関係で、様々な要素同士を割り当てすることができます。

package RequirementAndPartSample4{  
    part citizen;
    requirement taxRequirement{
        doc /* 所得税、住民税を納めること */
    }

    allocate taxRequirement to citizen; //割り当て
}

Allocateの使用例

図 7 Allocateの使用例。見た目はDependencyと同じ。

Verify

VerificationCaseにおいて、どの要求が検証されるのかを記述することができます。詳しいモデリング方法は次回ご説明します。

次回予告

検証に関する様々なことを記述できるVerificationCaseを紹介する予定です。

« 第三回