RAMS[25] IEC62279

久々のRAMSカテゴリの投稿です。最近、IEC62279の問い合わせが多いので整理する意味で投稿してみます。

IEC62279の要求事項は7.2.4 Requirementsに記載されています。ただ、ずらずら文章を読むよりも、Annex A　「Criteria for the selection of techniques and measures」を見たほうが楽で速いです。ここに記載されている表をよく見てこれらをすべてプランに記載し、実行すれば問題ありません。ただ、要求は高いので自分たちのレベルにテーラリングすることは可能です。

「ソフトウエア要求仕様書は要求管理者（Requirement Manager）の責任管理のもと書かれなければいけません」と最初に書いてあります。で、彼はインプットドキュメントをベースにしなさいとも記載されています。ちなみに、インプットドキュメントとは、

１．システム要求仕様書

２．システム安全要求仕様書

３．システムアーキテクチャー説明書

４．外部インターフェース仕様書

５．ソフトウエア品質計画

６．ソフトウエアバリデーションプラン

となっていますが、実際に影響するのは１～４になると思います。

その後に、ソフト要求仕様書を参照しながら規格の7.2.4.2 to 7.2.4.15の要求を満足しろと書いてあります。では、具体的に規格が要求する項目を見ていきましょう。

7.2.4.2　ソフトウエア仕様書に描かなければいけないこと

ソフトウエア仕様書は下記の項目について記載しなければなりません。また、これらの項目はISO/IEC 25010に定義されているということです。では、一つずつ見ていきましょう。

a) functionality (including capacity and response time performance),

　これは一番重要な機能についてです。機能はソフトウエアが担う仕事ですが、ともすると曖昧さが出てしまいます。機能には容量と反応機関を含めなさいと書いています。つまり、その機能はどれくらいの規模でその処理時間はどれくらいに納めるのかを明確にするということです。機能要求仕様書を書くにあたって個々にこれらを書く必要はありません。このソフトウエアはこの容量（規模、処理台数とか）を何ミリ秒で完了しなければならないということを書いても、容量は大きなくくりでもいいですが、機能の場合は積み上げが想定される場合は、それぞれの機能毎に反応時間を決める必要があります。これは、そのソフトがどのような構造になっているかに起因するとは思います。最終的な性能を満足するためには、それぞれに機能の反応時間は決める必要があるでしょう。ただ、これも機能の大きさで変わるので、規格準拠という意味ではある程度大きな機能で制約を掛けるほうが仕様書を書くときには楽だとは思います。

b) robustness and maintainability,

頑健性と保守性という意味です。これらはどちらかというと、機能毎というよりはそのソフトを作るうえでの考え方です。この頑健性というのがソフトウエアでは何だろうと思いますが、いわゆる、「コンピュータシステムで実行中のエラーや、誤った入力に対処できる能力のこと」なので、機能毎に記載するというよりも、全体的に「こう作る」という指針を示せばいいと思います。当然、最後にそうなっているかという検証（妥当性確認）は必要になることは言うまでもありません。

c) safety (including safety functions and their associated software safety integrity levels),

RAMS規格なので、safetyは重要です。ここで言いたいのは、安全機能とそのSILを明確にするということです。これらは各機能につくものになります。なので、機能のそれぞれに記載してあげるといいでしょう。トレーサビリティーをとっているなら、トレーサビリティーのタグにこの機能は安全関連なのか、安全関連ならSILはいくつなのかがわかるタグのつけ方をしてしまえばそれで済むと思います。

d) efficiency　効率性

ソフトウエアの効率性とは何でしょうか？　効率にはいくつかの視点がありますが、まずは、時間効率性と資源効率性でしょうか。時間効率性はいかに早く処理を終わらせるかで、資源効率性とはメモリをあまり食わないということです。これも各機能毎につくものかといえばそうでもなく、ソフトを作る上の指針といってよいと思います。

e) usability 使いやすさ

使いやすはも視点で変わります。MMIFのような場合は操作者に対する使いやすさを表します。また、ソフトを作るうえでのモジュールの使い勝手がいいというのも使いやすさでしょう。本規格では、どちらかというと後者が主だと思います。当然、使用者に対する使いやすさも重要ですが。

f) portability 携帯性

和訳すればこうなりますが、ソフトウエアで言えば作成したソフトモジュールの再利用性ということになります。個々のの機能というよりは指針で書くべき事柄です。指針が具体的に方式まで示せれば言うことありません。このようなことはソフトウエア設計基準のようなものを作成、設計者のスキルに依存することがないようにするべきだと思います。

7.2.4.3　SSILのトレース

これは、7.2.4.2の c)と同じことです。リスク分析をして対策機能を決めたときに、その対策機能に要求されるSILをソフトの要求仕様書までデリバーしろという意味です。

7.2.4.4 SSILの範囲の明確化

わかりにくいですが、簡単に言ってしまえば、ソフトウエア要求仕様書の中で、この範囲を明確にしろということです。その方法として、complete, clear, precise, unequivocal, verifiable, testable, maintainable and feasible,を上げています。

それとは別に、要求インプットドキュメントにバックトレースすることが要求されています。これは、トレサービリティーをやっていれば悩むことはないでしょう。

7.2.4.5　ソフトウエア要求仕様書は説明にモデルを使用したりして、今後ソフトをメンテナンスする人にわかりやすいように書く

まあ、これはいうまでもないですが、要求仕様書を書いた人がいなくなっても、ちゃんとわかるように書いておけということです。そのためにはモデルなどを使用しなさいということですね。

7.2.4.6　外部インターフェイス仕様書の明確化

ソフトウエア仕様書は自ソフトだけではなく、外部機器のインターフェイスを明確にする必要があります。将来想定できるからそのようなインターフェイスも記載しなさいと書いてあります。まあ、これはインターフェース仕様書を呼べばいいと思いますが。

7.2.4.7　関係する運用モードの明確化

これはここの機能要求に起因する場合とそもそも、このソフトウエアが使用される前提条件と二つあります。前者は個々の機能に記載されるべきですが、後者はシステム要求仕様書にバックトレースしてもいいでしょう。ただし、システム要求仕様書にその旨が書かれていればですが。

7.2.4.8　すべての関係する運用モードは記載される必要がある。

運用モードがいくつかある場合は、まず、前段に運用モードを明確に定義しなければなりません。そのうえで要求仕様書を書くということになります。なので、要求仕様書には運用モードを明確に書くことになります。普通は、上位ドキュメントで作成されているはずなので引用すればいいと思います。

また、要求機能が運用モードによって異なる場合は、各機能の中で明確にする必要があります。

7.2.4.9　ハードウエアとソフトウエア間の制約条件を明記する。

これも個々の機能に書くべきことではないと思います。いま、話題にしているのはソフトウエアなので、ソフトを作成することに関して、ハードウエアの制約条件と読むほうがわかりやすいかもしれません。例えば、CPUのエンディアンとか、浮動小数点コプロが使えないとかの制約条件を書けばいいでしょう。

7.2.4.10　チェック機能の範囲

ソフトウエア要求仕様書には、ソフトウエア自身のセルフチェッキング機能、ソフトウエアによるハードウエアのチェッキング機能があります。これらを考慮して書きなさいということです。システムを作る場合は、本ソフトウエア以外の機能に頼っている場合もあります。その時は、このソフトの責任範囲を明確にしなければなりません。アーキテクチャにもよりますが、機能記述のところに記載される場合もあるでしょうが、ひとくくりでまとめて説明の項を書いてもいいかと思います。要は、ソフト設計者がわかることが重要です。

7.2.4.11　周期的な機能テスト

機能が正しく機能しているかの周期的なチェックも考慮しなさいということです。ソフトウエアはシステマチックエラーですが、ハードウエアはランダムエラーを起こします。先ほど動かした機能が動いていたかもしれませんが、今回は正しく動かないかもしれません。その原因はハードウエアのランダム故障によります。したがって。ハードウエアのランダム故障が起因としする機能不全が想定できる場合は、必要な周期的な機能テストを入れます。

7.2.4.12　安全機能は運用中に試験できなければいけない。

例えば、重要な安全機能が正しく機能していないのに気が付かずにいざ使おうとしたら失敗したとか。知らず知らずのうちに重要な値が変わっていたとかなど運用中に変化して困る値などがある場合はその機能や値を運用中に試験できるような作りにしておかなければなりません。有名なのはメモリチェックでしょう。システムが動作中にもメモリチェックは行う必要があります。

7.2.4.13　SSILの明確化

「7.2.4.4 SSILの範囲の明確化」は範囲を明確にするという要求事項です。ここでは、それぞれの機能に対してSSILを明確に記述しておきなさいということになります。すべての機能にトレサービリティータグが振られており、それを見ればSSILがわかる仕組みになっていればいいでしょう。

7.2.4.14　非安全機能の明確化

これは、「7.2.4.13　SSILの明確化」の逆に当たります。各非安全機能には、この機能が非安全機能であるということを明確にしておけばいいでしょう。方法は、やはりトレーサビリティータグを利用すればいいと思います。

7.2.4.15　ソフトエア技術の使用

ソフトウエア要求仕様書は技術の使用と表A.2の対策をでサポートされなければならないと記載されています。また、複数のコンビネーションで使用する場合は、4.8と4.9を満足していることをJustifyしなくてはならないと書いてあります。これはどういう意味でしょうか？

表A.2には４つのテクニックが書かれ、それぞれにHRやRと振られています。しかし、例えば、すべてをFMを行うかということは現実ではないので、ここはFMではやらないが、モデルを使うというようにこのテクニックの中から何を使うかという意味に結局はなると思います。4.8章にはHRを要求されているが、それをやらない場合は、代替テクニックを使うと Software Quality Plan か他のドキュメントに書かれなければなりません。このコンビネーションが既に承認されているものなら特に記載必要はありません。どちらにしても、Justifyと記録は必要です。

7.2.4.16　An Overall Software Test Specification

ソフトウエア要求仕様書に基づいて、Overall Software Test Specificationを書く要求です。これも同じように表A.4に使用されるテクニックが記載されています。これは、前項と異なり、ここでMまたはHRとなっているものは、すべて行いなさいと読むのが正しい読み方でしょう。それぞれのテクニックにリファレンスの表があるので、それらを満足できるような試験計画をされるとよいと思います。

7.2.4.17 The Overall Software Test Specification

Overall Software Test Specification　は完全なソフトウエアのパフォーマンスをテストするための試験仕様です。この視点で試験仕様を作る必要があります。普通は、システムの要求仕様を確認することになるので、システム要求仕様書は細かい作りを記載するのではなく、このソフトがどのように動くべきであるかを記載するようにしましょう。この時、はっきりと判断基準（クライテリア）を書くようにするとOverall Software Test Specification が作りやすくなります。

7.2.4.18　Overall Software Test テクニックと方法

表A.7にテクニックと方法が記載されています。それには、Performance TestingとFunctional and Black-box Test要求されています。これは普通に皆さんされるのではないでしょうか。

7.2.4.19　テストケース

Overall Test Case には、下記の項目が含まれていなければなりません。

a) 入力信号とそのシーケンスと値（結果）
b) 予想される出力とそのシーケンスと値（結果）
c) 試験が成功したという判断基準。性能と品質の視点も加えること。

これは素直に理解できることだと思います。これをちゃんとドキュメントにする必要があるということです。