(前NTTデータ フェロー システム科学研究所長)山本 修一郎
本稿では、アーキテクチャに影響を与える要求について紹介する。要求に対するアーキテクチャの妥当性を議論することは、アーキテクチャに影響を与える要求と、影響しない要求を区別することでもある。また、要求に基づいてアーキテクチャを評価する手法についても解説する。
アーキテクチャ有意要求の必要性
システム開発が失敗する理由の最初の2つが、要求とアーキテクチャの欠陥である。アーキテクチャに影響する非機能要求のことをアーキテクチャ有意要求(Architecturally Significant Requirements, ASR)という。ASRを正しく定義するのは困難である。この理由は、機能要求はアーキテクチャの要素としてのコンポーネントに割り当てることが容易にできるのに対して、システム全体の振舞いに影響を与えるASRは、特定のコンポーネントに対応しないためである。大規模システム開発では、アーキテクチャが決まらないと、プロジェクトの組織体制を決めることができない。したがって下流工程の設計、実装、統合、テスト、展開にも影響する。
典型的なアーキテクチャ有意要求には以下の要素が含まれる。
(1)指定された品質特性を満足すべき程度としての品質要求
(2)アーキテクチャ制約
(3)アーキテクチャが実現する機能要求
このようなアーキテクチャ有意要求の必要性を、品質モデルの観点から見れば、次のように考えることができる。
システム品質は、システムアーキテクチャ品質によって決定される。
システムアーキテクチャ品質は、アーキテクチャ有意要求によって決定される。
したがって、アーキテクチャがシステムにとって必要であると同時に、アーキテクチャ有意要求も必要になる。換言すれば、ASRとそれに基づくアーキテクチャ判断が、システム全体の品質、開発計画、開発維持経費、保守性、拡張性、受容性、使用性に影響することになる。したがって、ASRとアーキテクチャの妥当性とともに、それらのリスクを分析することが重要になる。要求リスクとアーキテクチャリスクを分析するためには、要求とアーキテクチャを可視化することが重要になる。これによって、発注者の要求に対する、要求とアーキテクチャの準拠性ならびに、アーキテクチャに対するシステムとコンポーネント要求の準拠性を確認することができる。
品質とは
【定義】
必要とされる特性に対して、開発生産物が示す程度のことを品質という。
したがって、品質を測定するためには品質特性を定義するとともに、測定尺度を定義する必要がある。このため、次のような品質モデルが必要になる。
◆品質モデル
開発生産物の品質は、品質特性(Quality Characteristics)、品質属性(Quality Attributes)、品質計測単位(Quality Measurement Scales)からなる品質モデルで定義される。品質モデルの構成要素の例を表1に示す。
品質特性には、開発時に測定される開発指向の品質特性と、システム運用時に測定される運用指向の品質特性がある。開発指向品質特性の代表的な例は、バグ数に基づくソフトウェア品質である。運用指向品質特性には、ディペンダビリティ、効率性、相互接続性、持続可能性、使用性、性能、容量、構成可能性などがある。ディペンダビリティは、健全性と防御性(defensibility)がある。防御性は、耐故障性、安全性、セキュリティ、回復性がある。健全性には、可用性、正当性、予測可能性、信頼性などがある。なお、このような品質特性の階層分類の仕方には多様なものがあるので、ここで示したのはQUASAR[1]に基づく分類例である。
表1 品質モデルの構成要素例
◆品質要求の記述例
【記述形式】
条件Xの下で、システムが指定された品質基準Yに対する閾値Zに一致するか越えている。
この記述形式に従うと、「システムは高信頼で、耐故障性があり、安全でセキュアである必要がある」というような品質要求の記述は、定量的ではないので、よくないことが分かる。
これに対して、以下のような記述はよい品質要求の例である。
「通常運用条件の下で、基幹系機能に対して、システムの平均故障時間間隔が少なくとも5000時間である必要がある。」
品質ケース
開発生産物が十分な品質を持つことを示すために、主張(Claim)、議論(Argument)、証拠(Evidence)を用いた一貫性のある説明を品質ケース(Quality Case)という。
ここで「ケース」というのは、もともと、法廷用語で、有罪か無罪かを立証するために法廷での弁論のやり取りをToulmin[2]が定式化した論証手法に由来する。システム安全性やディペンダビリティを確認するための手法として、安全性ケース、ディペンダビリティケース、アシュアランスケースなどが考案されている。安全性ケースやディペンダビリティケースは、それぞれ、安全性やディペンダビリティについてのアシュアランスケースである。アシュアランスケースは保証ケースともいう。
Firesmithは、品質ケースによって品質の評価とシステムが要求品質を持つことの認証を容易化できるとしている。この意味では、アシュアランスケースを適用して品質ケースが開発されているのだから、アシュアランスケースを用いてアーキテクチャ要求品質を保証できるともいえる。
◆Toulmin構造
これらの基礎になったToulimin構造を図1の例で説明しておく。まず、「あること」が成立するというためには、それを「主張」として記述する必要がある。その上で、主張の根拠となる事実を「データ」として提示する必要がある。さらに、主張をデータが立証するというためには、この因果関係が妥当であることを「保証」する必要がある。このような保証に対する根拠としてのデータや証拠となる事実を「支援」という。
図1 Toulminの論証構造
続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(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:保証ケース作成支援ツールの概要