NTTデータ
技術開発本部
副本部長
山本修一郎
非機能要求に関する標準
ソフトウェア品質特性を定めたISO9126とソフトウェア要求仕様を定めたIEEE830を機能要求と非機能要求の観点から比較した結果を図1に示す。この比較では、非機能要求が何を対象とするかにより、プロセス、プロダクト、外部環境に分類して内容を比較している。この図からわかるようにソフトウェア品質特性は、IEEE830のソフトウェア属性と性能要求を含んでいると考えれる。
図1 機能要求と非機能要求
ISO9126[10]
ソフトウェア品質を測定するための世界標準として定められた。6項目の品質属性とその副特性から構成される(表2)。このため、外部環境やプロセスに関する記述はない。
品質特性 | 説明 | 特性 | 基準適合性 |
---|---|---|---|
機能性 |
明示的及び暗示的必要性に合致する機能を提供する | ■合目的性■正確性 ■相互運用性■セキュリティ |
機能性基準 適合性 |
信頼性 |
指定された達成水準を維持する特性 | ■成熟性■障害許容性 ■回復性 |
信頼性基準 適合性 |
使用性 |
理解、習得、利用でき、利用者にとって魅力ある特性 | ■理解性■習得性■運用性 ■魅力性 |
使用性基準 適合性 |
効率性 |
使用する資源の量に対して適切な性能を提供する特性 | ■時間効率性■資源効率性 | 効率性基準 適合性 |
保守性 |
保守(変更)作業のし易さに関する特性 | ■分析容易性■変更容易性 ■安定性■試験容易性 |
保守性基準 適合性 |
移植性 |
別環境へ移した際、そのまま動作する特性 | ■環境適応性■設置性 ■共存性 ■置換製 |
移植性基準 適合性 |
【機能性】
明示的及び暗示的必要性に合致する機能を提供する特性
【信頼性】
指定された達成水準を維持する特性
【使用性】
理解、習得、利用でき、利用者にとって魅力的である特性
【効率性】
使用する資源の量に対比して適切な性能を提供する特性
【保守性】
修正のしやすさに関する特性
【移植性】
ある環境から他の環境に移すための特性
また適合性(compliance)がすべての特性に共通する副特性となっている。
IEEE830 [2] [3]
要求仕様の標準的な構成を定めることで、非機能要求に相当する次のような内容を記述することを推奨している。
「はじめに」ではシステムの目的や範囲を記述する。
「要求仕様の一般的な説明」では、ユーザー特性や制約、仮定を記述する。
「要求仕様の具体的な説明」では、外部インタフェース、性能要求、設計の制約、ソフトウェアの属性、要求仕様の段落構成を記述する。要求仕様の段落構成は、文書化のテンプレートを示しているので、文書化のあり方に対する要求の例と考えることができるだろう。
発注仕様への機能要件及び非機能要件の取込[1]
「情報システムの信頼性向上に関するガイドライン(案)」では、企画段階における留意事項として、次の2項目が求められている(図2)。
図2 発注仕様への機能要件及び非機能要件の取込〔1〕
(1)情報システムが具備すべき信頼性・安全性の水準について定め、両者で合意すること
(2)発注仕様への機能要件及び非機能要件の取り込み
情報システムの信頼性と安全性を実現するためには、機能要件と非機能要件を整理、確認、決定する必要がある。非機能要件については見落としがちであることから、経営層を含めて十分に検討を行うことがとくに求められている。
ガイドライン案によれば、与えられた状況下で定められた期間中に当該システムが提供する機能やサービスが期待通りに動作し、正しい結果を出す性質が「信頼性」である。主として人命、経済活動及び国民生活を脅かすことを未然に防ぐ性質が「安全性」である。
また開発段階では、ソフトウェアの品質に関する特性に基づいて具体的な非機能要件を情報システムの供給者が検討することが求められている。ここで、ソフトウェアの品質特性とは、信頼性、保守性、移植性、効率性、機能性、使用性である(JISX0129)。この品質特性はISO9126に従っている。
なお、ガイドライン案には、開発段階における留意事項という記述があり、その中で文書化への言及がある。また、技術に関する事項の中では、形式手法・ツールを適用することなどが述べられている。これらはプロセスに関する非機能要求の例である。
今回は非機能要求の定義・分類と情報システム開発における位置づけを紹介した。非機能要求は情報システム開発における重要な概念であり、ITガバナンスやアーキテクチャ設計とも関連が深い。今後この方面での非機能要求の研究開発が進むことを期待したい。
参考文献
- [1] 経済産業省「情報システムの信頼性向上に関するガイドライン(案)」平成18年4月4日,http://www.meti.go.jp/press/20060404002/20060404002.html
- [2] 大西淳,郷健太郎,要求工学,共立出版,2002
- [3] 山本修一郎,要求定義・要求仕様書の作り方,ソフト・リサーチ・センター, 2006
- [4] Lawrence Chung, Brian Nixon,Eric Yu, John Mylopoulos, Non-Functional Requirements In Software Engineering, Kluwer Academic Publishers, 2000.
- [5]Alan Davis, Software Requirements analysis&Specification, Prentice Hall, 1990.
- [6]Donald Gause and Gerald Weinberg, Exploring Requirements: Quality Before Design, Dorset House Publishing, 1989 (黒川純一郎監訳,要求仕様の探検学 設計に先立つ品質の作り込み,共立出版,1993)
- [7]Gerald Kotonya and Ian Sonnmerville, Requirements Engineering, John Wiley & Sons, 2002
- [8]Pericles Loucopoulos and Vassilios Kurakostas, Sytem Requirements Engineering, MacGraw-Hill, 1995(富野壽監訳,要求定義工学入門,共立出版,1997)
- [9]Suzanne Robertson and James Robertson, Mastering the Requirements Process, ACM Press, 1999(苅部英司訳,要件プロセス完全修得法,三元社,2002)
- [10]Shari Lawrence Pfleeger, Software Engineering Theory and Practice, Prentice Hall, 1998(堀内泰輔訳,ソフトウェア工学 理論と実践,ピアソン・エデュケーション,2001)
- [11]Guide to the Engineering Body of Knowledge,http://www.swebok.org/ironman/pdf/SWEBOK_Guide_2004.pdf(stoneman版:松本吉弘監訳,ソフトウェアエンジニアリング基礎知識体系-SWEBOK-,オーム社,2003)
- [12]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:保証ケース作成支援ツールの概要