要求記述と形式化

テスト・検証における要求記述の重要性

テスト・検証の最も重要なリファレンスはシステム要求及びソフトウェア要求です。機能安全規格ISO26262においてテスト・検証とは次のように定義されています。

テスト
あるアイテムまたは要素が明記された要求を満たすことを検証するための計画、準備、オペレーション、実行プロセス。...

検証
検査されるオブジェクトがその要求に対して合致するか否かの確定。...

すなわち、(一部の例外を除き) 多くのテスト・検証の自動化のためには、要求をコンピュータに理解させることは欠かせません。コンピュータが理解できる表現で記述された要求、すなわち形式化された要求が必要です。「形式化」という言葉は多くの方に漠然と難解な印象を与えるかも知れません。しかしテスト・検証の自動化を利用するユーザの観点では、「コンピュータの理解できる言葉で書くこと」程度に解釈していただければ十分です。 

BTC EmbeddedPlatformでは、形式化された要求を様々な自動化に用います。

 

開発に関わる様々な文書の中での要求

要求、要件、要求仕様書、仕様書、設計書、インタフェース仕様書、等々...実際の開発の現場では様々な文書が作成され、活用されています。ここでいう要求とはISO/IEC/IEEE 29148及びISO26262におけるRequirementsを意味し、要求記述とはRequirements Specification(要求を詳細に記述し特定すること)を意味しています。

※ 一般的にはRequirements Specificationは要求仕様と訳されますが、設計における文書(Architectural Design Specification, Software Unit Design Specificationなど)も仕様と訳され広く認知されており、しばしば混同されることがあるため、当社のウェブサイトでは要求に対し仕様という訳を用いておりません。

一般に、近年のモデルベース開発の浸透に伴って"実行可能な仕様書"としてのモデルに置き換えられた対象は設計の文書です。要求の位置づけは設計の文書及びモデルとは全く異なります。要求が開発対象のシステム/ソフトウェアが「何を」するべきか(機能要求)、及びそれをどの程度良く行うか(非機能要求/サービス品質)を定義するのに対し、設計はそれらを「どのように」実現するかを定義するものです。

要求とは

要求とは、開発対象のシステム/ソフトウェアが「何を」するべきか(機能要求)、及びそれをどの程度良く行うか(非機能要求/サービス品質)を定義するものです。

システム要求はステークホルダの要求を基に作成されます。ステークホルダの要求には、開発対象のシステムに求められる能力と条件が詳述されています。これらはAdaptive Cruise Control (ACC) システムを例に取ると、下記のように表現されます。

開発されるシステムは、このようなシステム要求を全て満たすことでステークホルダの要求を満たさなければなりません。システムがそれぞれの要求を満たすことは、各開発フェーズのテスト・検証を以て確認されます。 システム要求群はさらに個別のソフトウェアまたはハードウェアコンポーネントに向けた要求群にブレークダウンされます。(個々のソフトウェアコンポーネントは、このブレークダウンされたソフトウェア要求を満たすよう設計される必要があります。)

具体的な要求がイメージしづらいですか?

ご安心ください。要求として明文化されておらずとも、多くのお客様は要求に相当する情報をお持ちです。BTC Japanのサポートチームが検証に必要な要求の抽出をお手伝い致します。

 

要求の形式化とは?

要求の形式化とは、厳密には要求を「シンタックスとセマンティクスが完全に定義された記述手法」を用いて記述することと定義されています。難解に聞こえますが、これをテスト・検証の自動化に利用する上では「コンピュータの理解できる言葉で書くこと」程度に解釈していただければ十分です。

要求を形式化するためには形式言語という専用の言語が用いられます。それらの言語は従来、専門的で難解なものでした。BTC Embedded Systems AGはテスト・検証の高度な自動化を実用化するために、要求の形式化を日々のエンジニアリングで誰もが使えるほど容易で身近なものにしたいと考え、組み込みシステムの要求の記述に特化することで直感的かつ可読性の高い形式言語を開発し発展させて参りました。当社設立初期に開発され形式検証の実用化に貢献したPattern、そしてこれを発展させたSimplified Universal Patternを経て、2020年末にはUniversal Patternのリリースを控えています。これらの言語は、難解な形式手法の専門知識を持たずとも読み書きが可能です。

  

要求の形式化は難しい?

いいえ、ほとんどの場合において要求の形式化は難しくはありません。BTC Embedded Systemsが提供する形式言語は直感的かつ可読性の高いものです。そしてそもそも、個々の要求は一般的に端的な記述であるためです。要求エンジニアリングに関する国際標準規格ISO/IEC/IEEE 29148においても、要求は文書の対象読者が十分理解できるようにシステムの記述を十分単純・明瞭にすることが重要であるとされています。

そして一般的にシステムが複雑化すると要求の数は増えますが、それに比例して個々の要求が複雑化するわけではありません。これは設計と大きく異なる点です。

もし形式化の仕方が分からない要求がございましたら、BTC Japanのサポートチームへお送りください。形式化の例をお返し致します。

形式化した要求のサンプルや、トレーニングコースも準備しております。

要求を形式化してまで自動化するよりも従来通りのテストを行った方が早い?

いいえ、要求の形式化を伴って自動化されたテスト・検証はテストケースを書くテストよりもずっと短時間で行えます。

例えば、

「車速が30km/hより遅い、または180km/hより速いときには、ACCシステムは非アクティブ化しなければならない」

という要求に対してテストを行う際に用いるテストケースは、システムの状態、境界値、要求に直接言及されていないものの関連する信号の振る舞いなどを考慮すると、多くの場合一つでは足りません。そしてそれぞれのテストケースに対して時系列の入力値と出力値(期待値)のセットを定義していく作業は一般的に大変大きな労力を要します。そして完成したテストケースが元の要求のテストとして本当に適切であったかをレビューする作業は、場合によっては作成する作業に匹敵するほどに工数を要します。

一方で、要求の形式化はそれぞれの要求に対して一回の作業です。Universal Patternを用いれば私たちの普段の用語に近い表現となり、情報量も絞られますので、数字の羅列のテストケースよりも容易にレビューできます。

そしてフォーマルテストを利用するとすれば、判定は全て形式化された要求に任せられるようになるためテストケースに期待値を記入する必要はありません。テストケースに必要なのは入力値のみです。様々なソースから自動でテストケースを作成することもできます。自動で作成したテストケース、手動で作成したテストケース問わず、シミュレーションした結果は全て判定の対象になります。この要求に対して直接関係の無いつもりで作成したテストケースも、判定の対象になります。一つのテストケースが複数の要求を網羅することもあるかも知れません。テストをしたつもりの要求がテストできていないこと(テスト漏れ)もあるかも知れません。それらは全て自動で検出されます。

もしモデルチェックによる形式検証が適用可能な対象であればさらに有利です。モデルチェックによる形式検証では、テストケースの作成自体が全く不要になります。カバレッジの測定さえ必要ありません。検証対象ソフトウェア内に生じうるありとあらゆる実行が評価の対象になるためです。

同じ質のテスト・検証を行うのであれば、記述する量、判定に要する工数、レビューに要する工数、再利用の観点で要求の形式化は従来の手動のテスト・検証手法に比べて非常に有利です。