(前NTTデータ フェロー システム科学研究所長)山本 修一郎
今回は、セーフウェア[1]に基づいて要求の完全性について紹介しよう。セーフウェアでは、ソフトウェア要求が完全であるためには、ソフトウェアが安全であることを確認できる必要があると考える。このため、ソフトウェアが安全であると判断できるだけの情報が要求として明確になっていなければ、要求が完全ではないことになる。
ソフトウェア安全要求プロセス
ソフトウェア安全要求プロセスでは、まずソフトウェアのハザードを分析する。次に、この分析結果に基づいて、ソフトウェアがハザードによって危険な状態に陥ることがないように、ソフトウェアハザードに対処するためのソフトウェア安全要求を抽出する。また、他のソフトウェア要求と安全要求との一貫性を確認する。さらに、ユーザインタフェースについてもソフトウェア要求の安全性を確認する。ソフトウェア要求安全性プロセスを表1にまとめる。
表1 ソフトウェア要求安全プロセス(クリックで拡大)
要求仕様の構成要素
要求仕様を基本機能、制約条件、品質目標から構成することができる(表2)。基本機能ではシステムの目標を実現するために、入力に基づいて出力を生成する機能を定義する。制約条件では、システムが目標状態を達成するために必要となる動作条件の範囲を品質条件、装置限界、性能特性などによって定義する。品質目標では、基本機能が満たすべき安全性などの品質目標を、優先順位をつけて定義することにより、複数の目標と制約条件間のトレードオフを解決する。
表2 要求仕様の構成要素(クリックで拡大)
要求仕様の完全性
セーフウェアでは、要求仕様に含まれている情報が、ソフトウェアの望ましい挙動と望ましくない挙動を設計者が判断する上で不十分であるとき、要求仕様があいまいであるとしている。あいまいでない要求仕様が完全であることになる。すなわち、ソフトウェアの安全な挙動を規定するためには、要求仕様が完全である必要がある。
要求の完全性条件には、表3に示すようにユーザインタフェース完全性、状態完全性、状態遷移完全性、入出力完全性、トリガ事象完全性、応答事象完全性がある。以下では、この6条件について説明する。
表3 要求の完全性条件(クリックで拡大)
ユーザインタフェースの完全性
ユーザインタフェース完全性の観点には、インタフェース・キュー、トランザクション、情報表示がある。
◆インタフェース・キューの要求仕様
ユーザインタフェースで、ユーザー要求とシステムによる応答処理の整合性を保証するために、ユーザーによる処理要求を待ち行列で管理する必要がある。この待ち行列がインタフェース・キューである。インタフェース・キューでは、キュー項目となる事象、キューの種類(警報、定常)と個数、キュー項目の優先順位、キュー項目のオペレータへの通知手段、キュー項目の点検、消去などを定義する必要がある。
◆トランザクション処理の基準
トランザクション処理に対して、優先実行基準を定義しておく必要がある。そうでないと、安全性に対して優先度の高いトランザクションとそうでないトランザクションを区別できないために、安全性を保証できなくなる可能性がある。
◆情報表示基準
情報表示基準として、表示内容と事象の対応関係、表示内容の更新基準ならびに消去基準を明確に定義しておく必要がある。この基準が定義されていなかったり、不明確だと、システムが安全な状態であるかどうかを、運用担当者が誤判断する可能性がある。
状態の完全性
状態が完全であるためには、すべての状態が識別されていて抜けがないことが必要である。重要な状態として、初期状態、起動処理および停止処理に対応する状態がある。
・初期状態では、システムが安全な状態であることが必要である。
・起動処理、停止処理が安全であることが必要である。このためには、起動時に全ての変数を適切に初期化・再同期する必要がある。
・起動、停止時に、ソフトウェアの状態と外部プロセス状態が対応している必要がある。
・起動前、停止後、オフライン時に、受理した入力に対するソフトウェアの挙動を定義しておく必要がある。そうしないと、外部プロセス状態をソフトウェアで管理する状態との整合性がくずれてしまう可能性がある。
たとえば、図1ではソフトウェアによって、自動操作しているとき(①)、システムを一時停止して(②)、ユーザーが手動で操作した(③)後で、再度システムを起動する(④)状況を示している。このとき、ソフトウェア側で、手動操作によって変化した状態情報を入手できないと、システムの状態について誤った情報に基づく処理を実行してしまう危険がある。
図1 外部プロセス状態との整合性
続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要