ホーム >  要求工学 >  2006年9月号 >  第23回：非機能要求  1  2  次へ 

概要

これまでの要求仕様化手法では、情報システムの機能要求を獲得し正確に記述することに主眼が置かれてきたこともあり、信頼性や安全性などの非機能要求（Non Functional Requirements）についてはあまり留意されてこなかった[4]。

このような現状に対して、経済産業省が平成18年４月４日に発表した「情報システムの信頼性向上に関するガイドライン（案）」では、「非機能要求」を明確に定義することが情報システムの信頼性を向上する上で重要であると指摘している[1]。このガイドライン案を読まれた方も多いのではないだろうか？今回は最近注目されてきた非機能要求とソフトウェア品質特性などとの関係について紹介しよう。

非機能要求の定義

以下では代表的な要求工学やソフトウェア工学の教科書で述べられている非機能要求の定義を列挙しよう。また前述したガイドラインの定義も紹介する。

Kotonya と Sonnmerville（KS）[7]

非機能要求はシステムの機能性に明確に関係しないような要求である。非機能要求は開発対象としての製品（プロダクト）とプロセスに制限を与える。そして製品が適合すべき外部制約を特定する。非機能要求は、安全性、セキュリティ、使用性、信頼性、性能要求を含む。

Loucopoulos と Kurakostas（LK）[8]

非機能要求は、システム自体やその環境、あるいはその開発に対する制約である。非機能要求には、セキュリティ、有効性、移植性、使用性、性能などがある。

また機能要求と非機能要求の区別は必ずしも明確ではないとも述べている。この理由は、非機能要求も最終的には機能によって実現されるからである。しかし非機能要求は要求を分析する上でシステムが提供すべき関心事を明確化できるので、機能要求と区別して考慮する必要があると述べている。

Robertson と Robertson（RR）[9]

非機能要件とは、システムがもたなければならない固有の属性である。非機能要件を次の８種類に分類している。

• ルック・アンド・フィール要件
• 使用性要件
• パフォーマンス要件
• 運用・操作要件
• 保守性・可搬性要件
• セキュリティ要件
• 文化的・政治的要件
• 法的要件

パフォーマンス要件に、速さ、大きさ、精度、安全性、信頼性などを含めている。

また、Robertsonは非機能要件と制約を区別している。制約とは、システム全体に適用されるグローバル要件である。制約には以下のものがある。

• システムの目的
• 費用を負担する利害関係者
• システムのユーザー
• 要件制約
• 命名法
• 関連する外部的な事実
• 開発者が立てる仮定

要件制約では、システムの解法を設計する上での制約と、プロジェクトの時間および費用に関する制約を記述する。

Pfleeger（P）[10]

非機能要求または制約要求は、問題の解法を作成するための選択肢を制限するシステム上の制約を記述するものである。

Pfleegerは、機能要求をテストするのが機能テストであり、非機能要求をテストするのが性能テストであるとしている。したがって、性能テストは仕様化された非機能要求に基づいて実施される。性能テストで最も重要なのはシステムの信頼性、可用性、保守性を保証する品質テストであるとしている。この他のテストでは、過負荷、容量、システム構成、互換性、回帰性、セキュリティ、タイミング、環境、回復性、保守性、文書化、操作性（ヒューマンファクタ）などを確認する。

SWEBOK（SWBK）[11]

非機能要求はソリューションを制限するように作用する要求である。非機能要求は制約や品質要求としても知られている。非機能要求は、性能要求、保守要求、安全性要求、信頼性要求やそのほかの多くの種類のソフトウェア要求に分類することができる。

Wiegers（W）[12]

非機能要求は、外から見えるシステムの振る舞い以外で、ソフトウェアシステムが示さなければならない特性または特徴、あるいは遵守しなければならない制約の記述である。

システムの品質または特性を表す一種の非機能要求を品質特性という。品質特性には、使用性、移植性、保守性、完全性（integrity）、効率性、信頼性、堅牢性などがある。

経済産業省（METI）[1]

「情報システムの信頼性向上に関するガイドライン(案）」では、利用者の要求を満足するためにソフトウェアが実現しなければならない機能についての要件を機能要件とする。これに対して、機能要件以外のすべての要素（性能、容量、情報セキュリティ、拡張性等）を非機能要件とする。

Davis（D）[5]

非挙動的要求（non behavioral requirements）は、システムが仕事を遂行するときの属性を定義する。非挙動的要求には、システムに要求される効率性、信頼性、セキュリティ、保守性、移植性、可視性、容量、標準などが含まれる。

Gause and Weinberg （GW）[6]

非機能要求に相当する概念として、機能についての属性と制約を提案している。機能についての特性（修飾語）が属性である。機能が動詞に対応するように、属性は形容詞や副詞だと考える。属性（MUST属性）を実現する設計解が満足すべき必須条件を制約という。すべての必要な属性を具備した機能が実現されたことを判断するための基準が制約である。

一つの機能には複数の属性が対応する。また複数の機能に対する全体的な属性もある。たとえば、費用や安全性はシステム全体に対する属性だ。一つの属性に対して複数の制約が対応する。

また、空間にたとえると、属性は次元に相当する。属性次元上の点に相当する属性細目を属性と区別することが重要だ。たとえば、色彩は属性だが、白色や赤色は色彩の属性細目だ。属性をMUST、WANTS、IGNOREに分け、MUST属性に着目して制約を定義している。

たとえば次のようである。

機能：

情報を表示する機能

属性：

情報を選択しやすい、表示内容を理解しやすい

制約：

支援要請回数、アクセス時間、アクセス誤りなどについての具体的な指標値や境界条件

この例から分かるように、属性と制約を非機能要求として捉えることができる。この手法は、機能要求から属性、属性細目、そして制約を導いており、非機能要求の実践的な獲得手法になっていると考えることができる。

非機能要求の比較

前述した非機能要求の定義で明示的に使用された特性を用いて、それぞれの定義を比較すると表1のようになる。ただし、GWでは具体的な特性用語が述べられていないので比較していない。

機能要求については、用語が同じなのに、機能に関する特性としての非機能要求を表現しようとするとこれだけの差が生じることがわかるだろう。また用語の意味を考慮しないと正確な比較ができないことも注意しておく。たとえば、KSの信頼性の下位特性として可用性が含まれている[7]。また効率性の下位特性には時間効率性と資源効率性が含まれるので、性能要求が含まれている。

また、英文の教科書の訳語の問題もある。たとえばIntegrityは場合によって、一貫性、完全性、整合性など3種類に訳されているので、注意が必要である。また完全性はcompletenessに対応する場合もある。このように言葉の意味を特定するのはなかなか難しいものである。したがって、非機能要求を記述する上では、定性的な用語のレベルでとどめるのではなく、より具体的な内容を分析して記述することが求められる。そのための手法として、特性に対する指標を具体化して定量的に記述する方法と、NFRフレームワーク[4]などのようにゴールグラフを用いて定性的に分析する手法がある。これらについては、別の機会に紹介したい。

---

いずれにしても、非機能要求の中で、共通的に重視される特性として、性能（効率性）、信頼性、セキュリティ、使用性、保守性があることが分かる。これらについては必ず検討し、仕様化すべきであろう。また以下で述べるISO9126ソフトウェア品質特性も重要な非機能要求である。

次のページへ