NTTデータ
技術開発本部
副本部長
山本修一郎
信頼性要求の基本特性
前述した信頼性要求の諸定義や留意点で使用された特性を整理すると信頼性を次のように考えることができる。まずシステムの状態には、開発中、可用中、故障中の3状態があることが暗黙に仮定されている。そこで信頼性要求がシステムのどの状態について述べているかを考慮することにより、信頼性要求を次の8個の基本特性により定義できる(図1)。
図1 信頼性要求の8つの基本特性
・開発条件
システムがどのように開発されるのかを工程ごとに生産物の規模と品質や要員、コスト、期間など、信頼性に影響を与える項目に関する条件を具体的に記述する。
・開発時の故障率
システムの障害件数などを規模、試験項目数などに基づいて正規化して指定する。
・利用条件
システムがどのように利用されるかを機能ごとの利用頻度や稼働率で記述する。たとえば、いつ(時間帯)どこで(場所)どんな条件(発生トランザクション量、ネットワーク環境など)でシステムを利用する可能性があるのかを具体的に列挙する。
・耐故障性
予期しない異常に起因する故障に対して、システムがどのように対応できるかを具体的に記述する。
・運用時の故障率
システムの障害件数などを規模、試験項目数などに基づいて正規化して指定する。
・回復性(故障寿命)
平均故障時間間隔や故障回復までの最低保証時間などを具体的に記述する。
・影響度
故障に対する被害の大きさを分類し、システムがとるべき対策を具体的に記述する。
・適合性
開発時、可用時、故障時ごとに遵守すべき適切な標準、規約、法規、プロトコルを具体的に記述する。
ここで、開発条件については前述したどの定義でも触れられていないが、利用条件によってシステムの信頼性が影響を受けるのと同じように、どのようにシステムが開発されるかによっても信頼性が影響を受けると考えるのが自然であろう。たとえば、仕様書や設計書が完全なのか、設計レビューが十分なのか、熟練した設計者が開発に参加するのかどうか、開発期間は十分なのかなどがシステム信頼性に大きな影響を与えるはずである。
信頼性要求の比較
前述した信頼性要求の基本特性を用いて、それぞれの定義を比較すると表2のようになる。システムの特徴に応じてどのような信頼性要求の特性を記述すべきかを考慮することで、より効果的に信頼性要求を定義することができるといえよう。
D | G | ISO | KS | P | RR | W | |
---|---|---|---|---|---|---|---|
開発条件 | |||||||
開発時の故障率 | ○ | ○ | ○ | ||||
利用条件 | ○ | ○ | ○ | ○ | ○ | ||
耐故障性 | ○ | ||||||
運用時の故障率 (成熟性) |
○ | ○ | ○ | ○ | ○ | ||
回復性 (故障寿命) |
○ | ○ | ○ | ○ | ○ | ○ | |
影響度 | ○ | ||||||
適合性 | ○ |
今回は非機能要求の中でも重要な信頼性要求に対して定義・分類を紹介した。これに基づいて、信頼性要求に関する8つの基本特性を抽出した。これらの特性は要求工学の教科書やISO標準を参考にして系統的に整理したものである。実際のシステム開発では、ぜひこれらの基本特性を参考にして信頼性要求を明確に定義することで、信頼性の高いシステムの実現につなげていただきたい。
参考文献
- [1]Alan Davis, Software Requirements analysis&Specification, Prentice Hall, 1990.
- [2]Tom Gilb, Competitive Engineering A Handbook for Systems Engineering Requirements Engineering, and Software Engineering Using Planguage, Elsevier, 2005
- [3]Guide to the Engineering Body of Knowledge, http://www.swebok.org/ironman/pdf/SWEBOK_Guide_2004.pdf( stoneman版:松本吉弘監訳、ソフトウェアエンジニアリング基礎知識体系-SWEBOK-,オーム社,2003)
- [4] Gerald Kotonya and Ian Sonnmerville, Requirements Engineering, John Wiley & Sons, 2002
- [5] Shari Lawrence Pfleeger, Software Engineering Theory and Practice, Prentice Hall, 1998(堀内泰輔訳,ソフトウェア工学 理論と実践,ピアソン・エデュケーション,2001)
- [6]Suzanne Robertson and James Robertson, Mastering the Requirements Process, ACM Press, 1999 (苅部英司訳,要件プロセス完全修得法,三元社,2002)
- [7]Karl Wiegers, Software Requirements, Microsoft, 2003(渡部洋子監訳,ソフトウェア要求,2003)
- 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:保証ケース作成支援ツールの概要