システム エンジニアリングにおける最も重要なタスクはおそらく、ステークホルダーのニーズを理解し、それをシステム要件に変換するという 2 つのタスクです。このホワイトペーパーでは、これらのタスクを実行するためのモデリングの早期適用について説明し、単なる記述モデルから形式的な実証に至るまでの、高度化および価値向上を実現するモデリング手法を紹介します。システム要件の品質が向上するだけでも、これらの手法への投資は正当化されますが、結果として得られるモデルは、プロジェクトの後の段階でステークホルダーのニーズをより効果的に表現するためにも使用できます。要件モデルを利用して一貫性のある完全なシステム要件を実現する方法を示します。図 1 に、これらの利点を実現するために本書で従ったプロセスを示します。
図 1. ステークホルダーのニーズをシステム要件に絞り込み、詳細な要件を導き出すプロセス。
このケーススタディでは、以下に説明するステークホルダーのニーズに基づいて、マシン冷却システムの要件を派生させます。
マシンの動作温度を維持して、過熱によるマシンの損傷を回避するシステムを提供します。
- [制約] 冷却システムは動作温度を 40°C 未満に維持する必要がある。
- [制約] 事前に定められた時間内に冷却の効果を得る必要がある。
- [仮定] 環境温度は -10℃ を超え、80℃ 未満である。
これらのステークホルダーのニーズはあいまいであり、解釈を誤りやすいため、システム要件が不完全または不正確になり、最終的にはステークホルダーの期待を満たさない設計になってしまうことがあります。そのような事態を回避するには、ステークホルダーのニーズの妥当性を確認する必要があります。
ステークホルダーのニーズへの理解の妥当性を確認し、一連のシステム要件に絞り込むのに役立つモデリング手法があります。この手法では、以下を使用します。
これらの各手法については以降のセクションで説明し、最後にデジタルスレッドを使用してステークホルダーのニーズとさまざまなレベルの派生要件間のトレーサビリティを確立する方法について説明します。
ステークホルダーのニーズを探る最初のステップとして、冷却システムが満たす必要があるさまざまなシナリオを記述します。たとえば、温度が高すぎる場合、または冷却の効果が表れない場合に必要な動作などです。
記述要件モデルは、要件の構造化されたグラフィカルな表現を提供するため、従来の自然言語の要件に比べて一歩前進しています。これにより、関与するチーム間のコラボレーションが向上します。このような表現の良い例は、シーケンス図です。
記述モデルとは
記述モデルは、システムが何であるか、または何を行うかを人間が判読可能な方法で記述する、グラフィカルなシステムの仕様です。
図 2 では、次のシナリオを示しています。温度 (T) が高すぎる場合 (T>=40)、冷却が必要です。冷却の効果が得られた場合 (T<40)、冷却をオフにする必要があります。一方、冷却の効果が得られない場合 (delay>=30)、マシンをオフにする必要があります。
図 2. このシナリオを説明するシーケンス図。
シーケンス図で、冷却システムのモデル化されたコンポーネントがさまざまなシナリオでどのように連携して動作するかをグラフィカルに説明しています。これらの記述要件モデルは依然としてエンジニアリング分野にしっかりと属していますが、シミュレーション可能 (実行可能) な要件モデルによってシステム分野の観測と洞察がもたらされ、ステークホルダーが自身の分野固有のコンテキストで要件を直接理解できるようになります。ステートチャートは、これらの出力を生成できる実行可能な形式の良い例です (図 3 を参照)。
シミュレーション モデルとは
シミュレーション モデルとは、マシンによる解釈を目的としたシステムの仕様であり、解釈の出力は人間が解釈して結論を導き出す必要があります。
図 3. シミュレーション可能なアーキテクチャ コンポーネント (ステートマシン) とその出力。
これが重要なのは、シミュレーションにより、前述のシーケンス図で記述された各シナリオの明確な解釈が提供されるからです。また、この解釈をステークホルダーに伝え、さまざまなシナリオを検討し、具体的なニーズを把握して、その情報をシステム要件に記述できるようにする手段も提供されます。
シーケンス図で指定された動作をシミュレーションするモデルができたので、ステートマシンによって生成された出力を確認し、ステークホルダーと話し合うことができます。さらに、ステートマシンの動作がシーケンス図に記述されているシナリオと整合しているかどうかの妥当性を確認できます。図 4 では、シーケンス図内の緑色のチェックマークは、シミュレーション中に正しいイベントが正しい順序で発生したことを示しています。これにより、機能的なモデルの動作が正しいことが確認されます。これらの結果は、ステークホルダーとの妥当性確認にも使用できます。
図 4. シミュレーションによる妥当性確認。
シミュレーション手法は、システムの動作を十分にカバーしますが、シミュレーションは通常、共同作業をサポートするための主要なシナリオを対象とします。一方、形式的要件モデルには、モデルの品質をより体系的に評価できる形式が含まれています。
そのような形式の 1 つとして、一連の要件の一貫性と完全性を形式的に実証するために使用できる要件テーブルがあります。一貫性のある要件には矛盾がなく、完全な要件には不足する機能がありません。図 5 の 前提条件の列 (A) は、システム入力 (温度値) と、要件が有効 ("アクティブ") になる条件を示しています。事後条件の列 (B) は、指定された要件がアクティブな場合に期待される動作を示しています。
形式的モデルとは
形式的モデルとは、マシンによる解釈を目的としたシステムの仕様であり、解釈の出力をさらに処理して、人間が利用できる最終的な結論を提示します。
図 5. 要件を記述する形式的モデル。
たとえば、要件 1 には、T が 40°C を下回った場合 (T<40)、冷却システムをオフにする必要がある (Turn_off_cooling == true) と記述されています。
Simulink Design Verifier™ の形式的手法機能を使用した解析により、要件が一貫していて完全であるかどうかを判断できるようになりました。図 6 では、温度がちょうど 40°C であるシナリオが含まれていないため、この要件セットは不完全です。
図 6. 形式的解析により、不完全性の問題 (T=40 の欠落) が特定されました。
設計モデルのテスト
形式的要件モデルは、要件の品質が高い上、設計、自動テスト生成、および検証時に要件モデルの要素を再利用できるため、下流のチームにとって良い開始点となります。要件モデルをユニットテストの一部として使用することで、機能モデルが要件を満たすように開発されていることを確認できます。こうしたユニットテストは、対話的な実行と、CI/CD フレームワークの一部としての実行の両方が可能です。図 7 は、要件 1 と要件 2.2 がテストに合格し、その他の要件は満たされていないことを示しています。
図 7. 形式的要件をテストとして使用した設計モデルの妥当性確認。
デジタルスレッドとその利用
多くのアーティファクトが、製品開発ライフサイクルのさまざまな段階で作成され、生成されます。そうしたデジタル アーティファクトには、要件、アーキテクチャ、設計モデル、コードファイル、および検証と妥当性確認ファイルが含まれています。これらのアーティファクト間のトレース可能なリンクを確立して、要件が他の要件、モデル、または検証と妥当性確認アクティビティに与える影響を理解することが重要です。このリンクはデジタルスレッドとして機能します。
たとえば、要件とアーキテクチャモデルから、要件のトレーサビリティの図を自動生成できます。これは、該当する要件、モデル、および検証アーティファクトがどのように相互にグラフィカルにリンクされているかに関する洞察を得るのに役立ちます。
図 8 は、あるステークホルダーのニーズが別のステークホルダーによって満たされているデジタルスレッドを示しています。現実世界では、複数のステークホルダーが組織全体に分散していて、さまざまな抽象レベルでさまざまな機能的領域をカバーします。ここでデジタルスレッドが不可欠になります。さらに、デジタルスレッドにより、自動化されたアジャイルな反復的プロセスおよびインフラストラクチャ (DevOps) の利用が促進されます。たとえば、図 8 は、テストの検証ステータスがどのように担当エンジニアに自動的にフィードバックされるかを示しています。
図 8. 冷却システムのデジタルスレッドを示すトレーサビリティ図。
組織がデジタルトランスフォーメーションの取り組みに着手する中、デジタルスレッド、デジタルツイン、および DevOps の概念は、デジタル エンジニアリングの基盤を確立する上で補完的な役割を果たします。これらの概念を組み合わせて、従来のエンジニアリング手法からデジタル中心のエンジニアリング手法への移行をサポートするインフラストラクチャを構築できます。
本紙では、ステークホルダーのニーズに基づいて、シミュレーションと形式的手法を使用して (シミュレーション可能/実行可能な) システム要件に絞り込むプロセスについて説明しました。これを行うために、シミュレーション (ステートマシン)、評価 (シーケンス図)、そして形式的に解析 (要件テーブル) できる要件モデルを使用しました。
要件モデルを使用することで、検証と妥当性確認アクティビティの自動化が可能になり、完全で一貫性のある、妥当性を確認済みのシステム要件が結果として得られます。また、単なる記述的な要件やテキストベースの要件よりも多くの情報が提供されるため、異なるチーム間のコラボレーションも向上します。
著者: Alan Moore、Becky Petteys、Stephan van Beek
