NTTグループのソリューションガイド

ICTソリューション総合誌 月刊ビジネスコミュニケーション

ビジネスコミュニケーション
第23回:非機能要求
NTTデータ 技術開発本部 副本部長 山本修一郎
NTTデータ 
技術開発本部
副本部長 
山本修一郎

非機能要求に関する標準

ソフトウェア品質特性を定めたISO9126とソフトウェア要求仕様を定めたIEEE830を機能要求と非機能要求の観点から比較した結果を図1に示す。この比較では、非機能要求が何を対象とするかにより、プロセス、プロダクト、外部環境に分類して内容を比較している。この図からわかるようにソフトウェア品質特性は、IEEE830のソフトウェア属性と性能要求を含んでいると考えれる。

図1 機能要求と非機能要求
図1 機能要求と非機能要求

ISO9126[10]

ソフトウェア品質を測定するための世界標準として定められた。6項目の品質属性とその副特性から構成される(表2)。このため、外部環境やプロセスに関する記述はない。

表2 ISO/IEC9126(JIS X 0129)ソフトウェア品質特性
品質特性 説明 特性 基準適合性
機能性
明示的及び暗示的必要性に合致する機能を提供する ■合目的性■正確性
■相互運用性■セキュリティ
機能性基準
適合性
信頼性
指定された達成水準を維持する特性 ■成熟性■障害許容性
■回復性
信頼性基準
適合性
使用性
理解、習得、利用でき、利用者にとって魅力ある特性 ■理解性■習得性■運用性
■魅力性
使用性基準
適合性
効率性
使用する資源の量に対して適切な性能を提供する特性 ■時間効率性■資源効率性 効率性基準
適合性
保守性
保守(変更)作業のし易さに関する特性 ■分析容易性■変更容易性
■安定性■試験容易性
保守性基準
適合性
移植性
別環境へ移した際、そのまま動作する特性 ■環境適応性■設置性
■共存性 ■置換製
移植性基準
適合性

【機能性】

明示的及び暗示的必要性に合致する機能を提供する特性

【信頼性】

指定された達成水準を維持する特性

【使用性】

理解、習得、利用でき、利用者にとって魅力的である特性

【効率性】

使用する資源の量に対比して適切な性能を提供する特性

【保守性】

修正のしやすさに関する特性

【移植性】

ある環境から他の環境に移すための特性

また適合性(compliance)がすべての特性に共通する副特性となっている。

IEEE830 [2] [3]

要求仕様の標準的な構成を定めることで、非機能要求に相当する次のような内容を記述することを推奨している。

「はじめに」ではシステムの目的や範囲を記述する。

「要求仕様の一般的な説明」では、ユーザー特性や制約、仮定を記述する。

「要求仕様の具体的な説明」では、外部インタフェース、性能要求、設計の制約、ソフトウェアの属性、要求仕様の段落構成を記述する。要求仕様の段落構成は、文書化のテンプレートを示しているので、文書化のあり方に対する要求の例と考えることができるだろう。

発注仕様への機能要件及び非機能要件の取込[1]

「情報システムの信頼性向上に関するガイドライン(案)」では、企画段階における留意事項として、次の2項目が求められている(図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)
前へ  1  2 
第59回以前は要求工学目次をご覧下さい。


会社概要 NTT ソリューション 広告募集 ページ先頭へ
Copyright:(C) 2000-2017 BUSINESS COMMUNICATION All Rights Reserved. ※本サイトの掲載記事、コンテンツ等の無断転載を禁じます。