IEEEソフトウェア誌の2008年March/April号では、ソフトウェア品質要求が特集されている。今回は、ISO/IEC 25030として2007年に改訂されたソフトウェア品質要求の新しい動きを紹介しよう。
ソフトウェア品質要求の標準化
表1に示すように、ソフトウェア品質モデルが1991年にISO/IEC9126として策定され、2001年に改訂されている。ソフトウェア品質モデルと対をなす、ソフトウェア製品評価プロセスについてはISO/IEC14598によって標準化されている。ソフトウェア製品品質要求評価のための新たなSQuaRE(Software Product Quality Requirements and Evaluation)シリーズでは、表2に示すように品質管理(2500n)、品質モデル(2501n)、品質測定(2502n)、品質要求(25030)、品質評価(2504n)を総合的にまとめている。ソフトウェア品質要求では、品質要求を識別し仕様化することを支援する。開発者はソフトウェア製品に対する品質要求を抽出定義し、評価プロセスの入力として用いることができる。
標準 | 説明 |
---|---|
ISO/IEC 9126 |
ソフトウェア品質モデル 1991年に策定され、2001年に改訂 |
ISO/IEC 14598 |
ソフトウェア製品評価 |
ISO/IEC 25000 |
ソフトウェア製品品質要求評価のための新たなSQuaREシリーズ25030がソフトウェア品質要求の標準 |
分類 | 説明 | SQuaRE標準 |
---|---|---|
品質管理 |
SQuaREにおける共通モデル、用語、定義を記述する。 アプリケーションに応じて適切な標準を利用できるように上位レベルの実践的な示唆を提供している。 ソフトウェア製品要求仕様を管理・評価するための支援機能に対する要求とガイダンスも提供する。 |
ISO/IEC2500n |
品質モデル |
内部品質、外部品質、利用品質に対する品質属性および副属性からなりISO/IEC9126に基づく詳細な品質モデルを提供する。 データ品質モデルも提供している。 |
ISO/IEC2501n |
品質測定 |
ソフトウェア製品に関する品質測定参照モデル、品質尺度の数学的定義、適用上の実践的ガイドラインを提供する。 内部品質、外部品質、利用品質に対する尺度がある。 |
ISO/IEC2502n |
品質要求 |
品質要求を識別し仕様化することを支援する。 開発者はソフトウェア製品に対する品質要求を抽出定義し、評価プロセスの入力として用いることができる。 |
ISO/IEC25030 |
品質測定 |
ソフトウェア製品評価について要求、推奨、ガイドラインを提供して.いる。評価尺度の文書化についても記述している。 | ISO/IEC2504n |
ソフトウェア品質要求の基本要素は何か
以下では、ISO/IEC25030の基礎となったISO/IEC9126とISO/IEC14598の概要を説明する。
ソフトウェア品質を測定するための世界標準として定められたISO9126では、表3に示すように内部特性と外部特性について、次の6項目の品質属性とその副特性を定めている。内部特性には、ソフトウェア製品の構成要素に対する設計や、コードについての構造や複雑さなどの静的な性質がある。外部特性には、完成したソフトウェアがハードウェアと実際のデータに対して実行されるときの、平均故障時間などの動的な特性がある。利用特性は、指定されたユーザが指定されたタスクを実環境でソフトウェアによって、実行するときの業務遂行に関する生産性や有効性などの外部活動としての特性がある。
分類 | 説明 | 副特性 | ||
---|---|---|---|---|
内部特性 外部特性 |
機能性 |
明示的及び暗示的必要性に合致する機能を提供する特性 | 適切性 正確性 相互接続性 セキュリティ |
適合性 |
信頼性 |
指定された達成水準を維持する特性 | 成熟性 耐故障性 回復性 |
||
使用性 |
理解、習得、利用でき、利用者にとって魅力的である特性� | 理解性 習得性 操作性 魅力性 |
||
効率性 |
使用する資源の量に対比して適切な性能を提供する特 | 時間効率性 資源効率性 |
||
保守性 |
修正のしやすさに関する特性 | 変更容易性 安定性 試験容易性 |
||
移植性 |
ある環境から他の環境に移すための特性 | 適応性 インストール容易性 共存性 リプレース容易性 |
||
利用特性
|
ソフトウェア製品評価について要求、推奨、ガイドラインを提供して.いる。評価尺度の文書化についても記述している。 | 有効性 生産性 安全性 満足性 |
【機能性】明示的及び暗示的必要性に合致する機能を提供する特性
【信頼性】指定された達成水準を維持する特性
【使用性】理解、習得、利用でき、利用者にとって魅力的である特性
【効率性】使用する資源の量に対比して適切な性能を提供する特性
【保守性】修正のしやすさに関する特性
【移植性】ある環境から他の環境に移すための特性
また適合性(compliance)がすべての特性に共通する副特性となっている。
ISO/IEC14598では、表4に示すように、以下のプロセスを標準化している。
分類 | 説明 |
---|---|
評価要求の確立 |
評価目的の確立 評価対象製品種別の識別 品質モデルの仕様化 |
評価の仕様化 |
測定法の選択 測定法のための評定水準の確立 総合評価のための基準の確立 |
評価の設計 |
評価計画の作成 |
評価の実施 |
測定値の収集 基準との比較 結果の総合評価 |
- 評価要求の確立では、評価目的を確立し、評価対象製品種別を識別するとともに品質モデルを仕様化する。
- 評価の仕様化では、測定法を選択し、測定法のために評定水準と総合評価のための基準を確立する。
- 評価の設計では、評価計画を作成する。
- 評価の実施では、測定値を収集し、基準と比較することにより結果を総合評価する。
ソフトウェア品要求作成の留意点
ソフトウェア品質要求は、ソフトウェア内部だけで定義できるのではなく、ソフトウェアを取り巻く外部環境にある関係者のニーズ、関係者の要求、システム要求、そしてソフトウェア要求を考慮することが必要になる(図1)。関係者ニーズの一部として関係者が求める品質ニーズがある。この関係者品質ニーズを解決するための期待として関係者の品質要求が定義される。関係者品質要求に基づいてシステム品質要求と対応するソフトウェア品質要求が定義される。このようにソフトウェア品質要求の作成では、根拠となる位置づけを明確化することが重要になる。なお図1ではシステム品質要求を省略しているが、システム品質要求の一部としてソフトウェア品質要求が含まれることはいうまでもない。
図1 ソフトウェア品質の位置づけ
◆ソフトウェア品質要求作成手順
ソフトウェア品質要求は、以下の手順で定義する(表5)。
手順 | 例 |
---|---|
品質要求定義 |
システム利用環境におけるユーザが必要とするサービスを提供するための要求を定義する |
品質要求分析 |
関係者がもとめる品質要求に基づいて、ソフトウェア製品に対する品質要求を仕様化する |
(1)品質要求定義
システム利用環境におけるユーザが必要とするサービスを提供するための要求を定義する。
(2)品質要求分析
関係者がもとめる品質要求に基づいて、ソフトウェア製品に対する品質要求を仕様化する。
◆ソフトウェア要求品質の定義
ソフトウェア品質要求は、品質特性、属性、尺度、目標値の4項目で定義する。たとえば、表6に示したように定義することができる。
標準 | 例 |
---|---|
品質特性 |
時間効率性 |
属性 |
応答時間 |
尺度 |
応答メッセージXを平常時に10個生成する時間を測定して平均時間を計算する |
目標値 |
1表以内 最悪の場合3秒以内 |
ソフトウェア品質要求の構成
ソフトウェア品質要求の構成内容は、表7に示したようにスコープ、適合性、規範的参考文献、用語定義、ソフトウェア品質要求フレームワーク、品質要求の要求、付録である。
章 | 内容 | ||
---|---|---|---|
1章 |
スコープ |
||
2章 |
適合性 |
||
3章 |
規範的参考文献 |
||
4章 |
用語定義 |
||
5章 |
ソフトウェア品質要求 フレームワーク |
目的 ソフトウェアとシステム 関係者と関係者の要求 ソフトウェアの性質 ソフトウェア品質測定モデル ソフトウェア品質要求 システム要求の構成 品質要求ライフサイクルモデル |
|
6章 |
品質要求の要求 |
一般要求と仮定 | |
関係者の要求 | システム境界 関係者の品質要求 関係者の品質要求の妥当性確認 |
||
ソフトウェア要求 | ソフトウェア境界 ソフトウェア品質要求 ソフトウェア品質要求の妥当性確認 |
||
付録 |
用語と定義 ISO/IEC 15288プロセス 文献一覧 |
ソフトウェア品質要求フレームワークでは、以下を記述する。
- ソフトウェアとシステム
- 関係者と関係者の要求
- ソフトウェアの性質
- ソフトウェア品質測定モデル
- ソフトウェア品質要求
- システム要求の構成
- 品質要求ライフサイクルモデル
品質要求の要求では、一般要求と仮定、関係者の要求、ソフトウェア要求を記述する。
関係者の要求では、システム境界、関係者の品質要求、関係者の品質要求の妥当性確認を記述する。
ソフトウェア要求では、ソフトウェア境界、ソフトウェア品質要求、ソフトウェア品質要求の妥当性確認を記述する。
IEEE std-830のソフトウェア機能属性
IEEE std-830では、望ましいソフトウェア要求仕様の構成を第5章で示している。表8では、その記述内容をソフトウェアの機能とその属性、ならびにソフトウェアの外部活動とその属性に分類して説明している。このうち、ソフトウェア品質属性に係る記述は以下の3つのソフトウェア機能属性と外部活動属性である。
分類 | ソフトウェア要求仕様の構成要素 | |
---|---|---|
機能 |
ソフトウェアが受理する入力、その処理、結果として生成する出力 a)入力の妥当性チェック b)操作系列 c)例外時の出力 d)パラメータの影響 e)入力と出力の関係 |
5.3.2 |
機能属性 |
狙い、スコープ(利益、目的、目標) | 5.1 |
実現時期の配分 | 5.2.6 | |
性能 | 5.3.3 | |
論理データベース(使用頻度。アクセス性能、一貫性制約、保持条件) | 5.3.4 | |
ソフトウェア属性(信頼性、可用性、セキュリティ、保守性、移植性) | 5.3.6 | |
外部活動 |
製品の位置付け(システムインタフェース、ユーザインタフェース、ハードウェアインタフェース、ソフトウェアインタフェース、通信インタフェース、メモリ、運用、サイト適応要求) | 5.2.1 |
外部インタフェースAPインタフェース、並列操作、監査機能、制御機能) | 5.3.1 | |
制約(制度、ハード制限、他) | 5.2.4 | |
標準化(書式、命名規約、会計手続き、監査証跡) | 5.3.5 | |
付録(コード、媒体の梱包に関する指示事項 | 5.4.2d | |
外部活動属性 |
ユーザ特性(教育レベル、経験、専門技能)とその必要性の根拠 | 5.2.3 |
要求に重要な影響を与える前提条件、依存関係 | 5.2.5 | |
制約(上位言語、信号プロトコル、信頼性、臨界性、安全性、セキュリティ) | 5.2.4 | |
付録(費用分析、背景情報、解決すべき課題) | 5.4.2abc |
◆性能
ソフトウェア性能について、静的数値要求と動的数値要求とを記述する。静的数値要求には、端末数、同時接続利用者数、処理対象とする情報量と種別などがある。動的数値要求には、正常時やピーク負荷時に対して一定時間内に処理可能なトランザクション数、タスク数、処理データ量などがある。
◆論理データベース
データベースに関連する非機能要求には、使用頻度、アクセス性能、一貫性制約、保持条件などがある。
◆ソフトウェア属性
- 信頼性:サービス提供時に必要とされる信頼性を記述する。
- 可用性:同期点やリカバリ条件、再起動条件などシステムに対して要求される可用性の条件を記述する。
- セキュリティ:不慮や悪意によるアクセス、使用、変更、破壊、情報漏えいからソフトウェアを保護する要因を記述する。たとえば使用する暗号技術、保存対象ログやデータ履歴、異なるモジュールへの指定された機能の割当て、 プログラムの特定領域間での通信制限、重要データの一貫性検査などがある。
- 保守性:モジュール性などソフトウェアの保守を容易化するための属性を記述する。
- 移植性:他のホストマシンやOSなどへのソフトウェアの移植性を容易化するために、ハードウェア独立性や移植性の高い言語の利用などについて記述する。
IEEE std-830と比較すると、ISO/IEC25030ソフトウェア品質要求の特徴はソフトウェア機能属性だけでなく、関係者のニーズや要求も含む外部活動属性とともに系統的に品質要求を記述する点であると思われる。
まとめ
今回はソフトウェア品要求について、ISO/IEC25030を中心として関連するISO/IEC9126とISO/IEC14598ならびにIEEE std-830について紹介した。今後もソフトウェア品質要求を取り入れた実践的な要求工学手法が活発に研究開発されることを期待したい。
■参考文献
- [1] Jorgen Boegh, A New Standard for Quality Requirements, IEEE Software, pp.20-27, January/ February, 2008.
- [2] ISO/IEC 25030:2007, Software Enginee ring Software Product Quality Require ments and Evaluation(SQuaRE)Quality Requirements, Int’l Organi zation for Standardization, 2007.
- [3]IEEE Std. 830-1998, Recommended Practice for Software Requirements Specification, IEEE Computer Society, 1998.
- [4]山本修一郎,NFRとゴール指向要求定義,情報処理学会誌,2008年4月号
- 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:保証ケース作成支援ツールの概要