非機能要求グレードご紹介 - IPA非機能要求グレードご紹介 - IPA ... 14

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

0Software Engineering CenterSODEC 2010 Copyright © 2010 IPA, All Rights Reserved

非機能要求グレードご紹介～システム基盤における非機能要求の見える化ツール～

2010年5月

独立行政法人情報処理推進機構

ソフトウェア・エンジニアリング・センター



情報システム「障害」に関する報道件数の推移

社会的に情報システムの「品質」に注目が集まってきている

出典：経済産業省「第1回高度情報化社会における情報システム・ソフトウェアの信頼性及びセキュリティに関する研究会」資料を抜粋・修正

0

5

10

15

20

25

30

35

40

45

502005.7

2005.8

2005.9

2005.10

2005.11

2005.12

2006.1

2006.2

2006.3

2006.4

2006.5

2006.6

2006.7

2006.8

2006.9

2006.10

2006.11

2006.12

2007.1

2007.2

2007.3

2007.4

2007.5

2007.6

2007.7

2007.8

2007.9

2007.10

2007.11

2007.12

2008.1

2008.2

2008.3

2008.4

2008.5 年月

累計・月別件数

件数

合計

情報システム障害の報道件数が増加

東証・建築（構造計算）トラブル

通信・交通系でシステム障害

金融関連でシステム障害発生



11.7%

15.0%

16.7%

18.3%

21.7%

31.7%

31.7%

31.7%

36.7%

41.7%

0% 10% 20% 30% 40%

その他

ベンダの選択に問題

システムの企画が不十分

計画が現実の利用形態に沿わず

社内の開発体制に問題

システムの設計が不正確

エンドユーザへの教育が不十分

システム開発の質が悪い

要件定義が不十分

テストが不十分

2008年 2003年

システム障害の要因とは

「日経コンピューター 2008年12月1日号」の「第2回プロジェクト実態調査」を元に作成

要件定義など上流工程の改善が品質向上に効果的 5年間に要件定義の問題が改善されていない



本日のターゲットは「非機能要求」に関するコミュニケーション

要件定義成果物からみた要求の分類※

機能要求

機能要求（プロセス）

機能要求（データ）

機能要求（インタ－フェース）

システム環境・エコロジー

セキュリティ

移行性

運用・保守性

性能・拡張性

可用性品質要求

運用・操作要求技術要求

その他要求

移行要求

付帯作業

その他

非機能要求

※参考：SECBOOK 「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～」（オーム社刊）

要求の分類

非機能要求グレードでの分類



要件定義で解決すべき課題

実現したい業務機能について、利用者が自らの言葉で語ることができる

機能要求

要求の中でも利用者側の把握が難しい「非機能要求」がターゲット

営業情報をシステム上で

共有し把握したい。

受発注情報に連動した在庫管理

を行いたい。

非機能要求

システムの実現方法に関係し、具体化が進まないと語りにくい

業務に直結せず技術的要素が強いため、要求項目が漏れやすく、開発者との共通認識を持つのが難しい

レスポンスは３秒以内にして欲しい。

システムダウン時は３時間以内に復旧して欲しい。

将来の処理量増大に備え、2倍の性能に拡張できるようにして欲しい。業務時間中は、システム

に関する質問に答えてくれる担当者がいて欲しい。



非機能要求グレード公開URL http://sec.ipa.go.jp/reports/20100416.html

次の２つのガイド(①②) と３つのツール(③④⑤)から構成。

さらに、自由にカスタマイズできるスプレッドシート(⑥)を用意。

非機能要求グレードの具体的な利用方法について解説したもの

②利用ガイド（利用編）

①利用ガイド（解説編）

非機能要求グレードを作成した背景やツールの詳細等を解説したもの

③グレード表

３つのモデルシステムと重要な非機能要求項目に対する要求レベルとグレードを一覧表化したもの

④項目一覧

システム基盤に関わる非機能要求項目を利用者／開発者間で漏れなく共通に認識できるよう体系化した一覧表。

⑤樹系図

グレード表、項目一覧の閲覧性を向上させ、要求項目の検討順を可視化した図。

⑥活用シート

グレード表と項目一覧の内容をまとめた一覧表。スプレッドシート形式で使用条件の範囲で改変が可能。

利用ガイド

（解説編）利用ガイド利用ガイド

（解説編（解説編））利用ガイド

（利用編）利用ガイド利用ガイド

（利用編）（利用編）



非機能要求の分類

要求の分類

説明要求例確認結果に基づき、実施する対策例

① 可用性システムサービスを継続的に利用可能とするための要求

運用スケジュール

（稼働時間・停止予定など）

障害、災害時における稼動目標

機器の冗長化やバックアップセンタの設置

復旧・回復方法及び体制の確立

②性能・

拡張性

システムの性能、および将来のシステム拡張に関する要求

業務量及び今後の増加見積り

システム化対象業務の処理傾向（ピーク時、通常時、縮退時など）

性能目標値を意識したサイジング

将来へ向けた機器・ネットワークなどのサイズと配置＝キャパシティ・プランニング

③運用・

保守性

システムの運用と保守のサービスに関する要求

運用中に求められるシステム稼動レベル

問題発生時の対応レベル

監視手段及びバックアップ方式の確立

問題発生時の役割分担、体制、訓練、

マニュアルの整備

④ 移行性現行システム資産の移行に関する要求

新システムへの移行期間及び移行方法

移行対象資産の種類及び移行量

移行ｽｹｼﾞｭｰﾙ立案、移行ツール開発

移行体制の確立、移行ﾘﾊｰｻﾙの実施

⑤セキュリティ

情報システムの安全性の確保に関する要求

利用制限

不正アクセスの防止

アクセス制限、データの秘匿

不正の追跡、監視、検知

運用員等への情報セキュリティ教育

⑥ｼｽﾃﾑ環境・ｴｺﾛｼﾞｰ

システムの設置環境やエコロジーに関する要求

耐震／免震、重量／空間、温度／湿度、騒音など、システム環境に関する事項

CO2排出量や消費ｴﾈﾙｷﾞｰに関する事項

規格や電気設備に合った機器の選別

環境負荷を低減させる構成

システム基盤に関する非機能要求を６つの大項目に分類



非機能要求項目の体系

大・中項目の全体像

継続性継続性

耐障害性耐障害性

災害対策災害対策

回復性回復性

性能・拡張性性能・拡張性

業務処理量業務処理量

性能目標値性能目標値

リソース拡張性リソース拡張性

性能品質保証性能品質保証

通常運用通常運用

保守運用保守運用

障害時運用障害時運用

運用環境運用環境

サポート体制サポート体制

その他その他運用管理方針運用管理方針

移行性移行性

移行時期移行時期

移行方式移行方式

移行対象移行対象（機器）（機器）

移行対象移行対象（データ）（データ）

移行計画移行計画

ＷｅｂＷｅｂ対策対策

セキュリティセキュリティ

ネットワーク対策ネットワーク対策

前提条件・前提条件・制約条件制約条件

セキュリティセキュリティリスク分析リスク分析

セキュリティ診断セキュリティ診断

セキュリティセキュリティリスク管理リスク管理

アクセス・アクセス・利用制限利用制限

データの秘匿データの秘匿

不正追跡・監視不正追跡・監視

マルウェア対策マルウェア対策

システム環境・ｴｺﾛｼﾞｰシステム環境・ｴｺﾛｼﾞｰ

システム制約／システム制約／前提条件前提条件

システム特性システム特性

適合規格適合規格

機材設置機材設置環境条件環境条件

環境環境マネジメントマネジメント

非機能要求項目非機能要求項目

可用性可用性運用保守性運用保守性

中項目中項目

中項目中項目

中項目中項目

中項目中項目

多

少

メトリクスに重要項目を含む割合

小項目で合計236項目



大項目ごとの体系化：樹系図

非機能要求項目の大項目単位に中項目以下の検討順序を可視化したもの

前

後

検討順序

後

重要な非機能要求項目



非機能要求グレードの使い方ユーザー視点から要求の実現レベルを見える化するため、

段階的に詳細化しながら「早期に」「誤解なく」「漏らさずに」確認できるようにする。

①モデルシステム（３つのモデル）

②グレード表＋樹系図

③項目一覧＋樹系図

システムの特徴重要項目詳細項目

方向性の確認コストに大きな影響がある

要求項目を決定開発開始までに必要な

要求項目を決定

16項目 92項目 236項目



①モデルシステムの選択

信頼性の観点から定めた情報システムの３つのモデルから１つ選ぶことでイメージを固める。

※IPA/SEC 重要インフラ情報システム信頼性研究会報告書のシステムプロファイルより定義

モデルシステム名

社会的影響が

ほとんどないシステム

社会的影響が

限定されるシステム

社会的影響が

極めて大きいシステム

モデルシステムの概要

ごく小規模のインターネットに公開されたシステムをイメージ

企業の特定部門が比較的限られた範囲で利用しているシステムで、機能が低下または利用不可な状態になった場合、利用部門では大きな影響があるが、その他には影響しないもの。

企業内のネットワークに限定した基幹システムをイメージ

企業活動の基盤となるシステムで、その機能が低下又は利用不可能な状態に陥った場合、当該企業活動に多大の影響を及ぼすと共に取引先や顧客等の外部利用者にも影響を及ぼすもの。

社会インフラのシステムなど不特定多数の人が利用するシステムをイメージ

国民生活・社会経済活動の基盤となるシステムで、その機能が低下又は利用不可能な状態に陥った場合、国民生活・社会経済活動に多大な影響を与えるもの。



モデルシステムの選択は１６の特徴項目から

要求レベル（グレード）の特徴を示す非機能要求（16項目）を用いて一番合うモデルシステムを選び、システムに合わせてカスタマイズ

モデルシステム

社会的影響が殆ど無いシステム

社会的影響が限定されるシステム

社会的影響が極めて大きいシステム

可用性

稼動率９９％（年間許容停止時間数日）

９９．９９％（年間許容停止時間約１時間）

９９．９９９％（年間許容停止時間約数分）

目標復旧水準

週次のバックアップからの復旧１営業日以内の復旧数時間で障害発生時点に復旧

大規模災害

システム再構築による復旧１週間以内の業務復旧ＤＲサイトで業務継続

性能・拡張性

性能目標

大まかな性能目標（他の要求より重視しない）

性能面でのサービスレベルを規定性能面でのサービスレベルを規定

拡張性拡張性は考慮しない拡張計画が決められている拡張計画が決められている

運用・保守性

運用時間

業務時間のみサービス提供夜間バッチ終了後、業務開始まで若干の停止時間あり

常時サービス提供が前提（２４Ｈ／３６５日稼動）

バックアップ

手動で必要データのみ日次に自動でシステム全体運用サイトと同期したバックアップサイトを構成

運用監視

機器の死活監視業務機能を監視障害の予兆監視

：：：

特徴モデルシステムの要求レベル



②グレード表の確認（システム基盤の非機能要求に関するグレード表）

コストや品質に影響が大きい重要項目（92項目）についてあらかじめ要求レベルの値を例示することで判断を「早期に」できる。

レベル値選択時の条件レベル値選択時の条件レベル値選択時の条件

2 夜間のみ停止

（9時～21時）

夜間に実施する業務はなく、システムを停止可能。

[-] 運用時間をもっと限って業務を稼働させる場合

[+] 24時間無停止やリブート処理等の短時間の停止のみを考える場合

4 若干の停止有り

（9時～翌朝8時55分）

24時間無停止での運用は必要ないが、極力システムの稼働は継続させる。

[-] 夜間のアクセスは認めないなど、長時間運用を停止する場合

[+] 24時間無停止で運用する場合

5 24時間無停止システムを停止できる時間帯が存在しない。

[-] 1日のスケジュールで定期的に運用を停止する時間帯が存在する場合

「可用性」：運用時間の例

社会的影響がほとんどないシステム

社会的影響が極めて大きいシステム

社会的影響が限定されるシステム

要求レベルの値を調整するための判断条件を記載

モデルシステムごとに事前に要求レベルの値を例示



0 1 2 3 4 5

A.1.1.1

○ ○

運用時間（通常）規定無し定時内（9時～17時）

夜間のみ停止（9時～21時）

1時間程度の停止有り（9時～翌朝8時）

若干の停止有り（9時～翌朝8時55分）

24時間無停止

【重複項目】C.1.1.1。運用時間は、システムの可用性の実現レベルを表す項目であると共に、運用・保守性に関する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。

【メトリクス】運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。

【レベル】（）内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。規定無しは、固定のサービス時間が存在しないことを示し、基本的にシステムは停止していて、必要に応じてユーザがシステムを起動するようなケースを想定している（例：障害発生に備えた予備システム、開発・検証用システム等）。定時内や夜間のみ停止は、一般的な業務形態を想定したもので、業務が稼動する時間帯が異なるシステムにおいては、時間帯をスライドさせるなどの読替えが必要である。停止有りとは、システムを停止しなければならない時間帯ではなく、システムを停止できる可能性のある時間帯を指す。24時間無停止は、オンライン業務が稼動していない時間にバッチを稼動させる必要があり、システムを停止することができないようなケースも含まれる。

A.1.1.2

○ ○

運用時間（特定日）

規定無し定時内（9時～17時）




24時間無停止


【メトリクス】特定日とは、休日/祝祭日や月末月初など通常の運用スケジュールとは異なるスケジュールを定義している日のことを指す。特定日が複数存在する場合は、それぞれにおいてレベル値を整合する必要がある（例：「月～金はレベル2だが、土日はレベル0」、「通常はレベル5だが、毎月1日にリブートをするためその日はレベル3」など）。また、ユーザの休日だけでなく、ベンダの休日についても特定日として認識し、運用保守体制等を整合すること。

A.1.1.3

○ ○

計画停止の有無計画停止有り（運用スケジュールの変更可）

計画停止有り（運用スケジュールの変更不可）

計画停止無し

○

【重複項目】C.2.1.1。計画停止の有無は、システムの可用性の実現レベルを表す項目であると共に、運用・保守性に関する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。

【運用コストへの影響】計画停止が”有り”の場合、事前のバックアップや、システム構成に応じた手順準備など、運用時のコストがかさむ。

可用性継続性

項番大項目中項目小項目

レベル運用コストへの影響

備考小項目説明

重複項目

重要項目

メトリクス(指標)

システムの稼働時間や停止運用に関する情報。運用スケジュール

③項目一覧の確認（システム基盤の非機能要求項目に関する項目一覧）

網羅的な項目と選択肢を提示することで、要求項目のレベルを「漏れなく」「誤解なく」確認し、必要に応じて「レベルを調整」

開発契約までに確認が必要な要求項目一覧

項番大項目中項目小項目小項目説明メトリク

ス(指標)

レベル

0 1 2 3 4 5

A.1.1.1

可用性継続性運用スケジュール

システムの稼働時間や停止運用に関する情報。

運用時間（通常）





24時間無停止

コスト感に基づく要求レベルに応じたに選択肢を提示

低高

要求レベル要求項目



【参考】非機能要求グレードのカスタマイズ

自由にご利用いただくために改変可能な使用条件で、スプレッドシートの「活用シート」を提供。

項目一覧

グレード表

0 1 2 3 4 5 選択時の条件選択時の条件選択時の条件

A.1.1.1

○ ○

運用時間（通常）





24時間無停止


【メトリクス】運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。

【レベル】（）内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。規定無しは、固定のサービス時間が存在しないことを示し、基本的にシステムは停止していて、必要に応じてユーザがシステムを起動するようなケースを想定している（例：障害発生に備えた予備システム、開発・検証用システム等）。定時内や夜間のみ停止は、一般的な業務形態を想定したもので、業務が稼動する時間帯が異なるシステムにおいては、時間帯をスライドさせるなどの読替えが必要である。停止有りとは、システムを停止しなければならない時間帯ではなく、システムを停止できる可能性のある時間帯を指す。24時間無停止は、オンライン業務が稼動していない時間にバッチを稼動させる必要があり、システムを停止することができないようなケースも含まれる。

2 夜間のみ停止（9時～21時）

夜間に実施する業務はなく、システムを停止可能。

[-] 運用時間をもっと限って業務を稼働させる場合[+] 24時間無停止やリブート処理等の短時間の停止のみを考える場合

4 若干の停止有り（9時～翌朝8時55分）

24時間無停止での運用は必要ないが、極力システムの稼働は継続させる。

[-] 夜間のアクセスは認めないなど、長時間運用を停止する場合[+] 24時間無停止で運用する場合

5 24時間無停止

システムを停止できる時間帯が存在しない。

[-] 1日のスケジュールで定期的に運用を停止する時間帯が存在する場合

A.1.1.2

○ ○

運用時間（特定日）





24時間無停止


【メトリクス】特定日とは、休日/祝祭日や月末月初など通常の運用スケジュールとは異なるスケジュールを定義している日のことを指す。特定日が複数存在する場合は、それぞれにおいてレベル値を整合する必要がある（例：「月～金はレベル2だが、土日はレベル0」、「通常はレベル5だが、毎月1日にリブートをするためその日はレベル3」など）。また、ユーザの休日だけでなく、ベンダの休日についても特定日として認識し、運用保守体制等を整合すること。

0 規定無し通常と異なる運用時間となる特定日は存在しない。

[+] 休日にバックアップ運用を行うなど、通常とは異なる運用時間となる特定日が存在する場合

2 夜間のみ停止（9時～21時）

週末はバックアップ運用のみのため、夜間は停止する。

[-] 週末運用するバックアップやバッチ処理などが存在せず、土休日は運用を停止する場合[+] 休日出勤する社員の業務に必要なため、土休日も運用する場合

5 24時間無停止


[-] 定期的に運用を停止する日が存在する場合

A.1.1.3

○ ○

計画停止の有無

計画停止有り（運用スケジュールの変更可）

計画停止有り（運用スケジュールの変更不可）

計画停止無し

○

【重複項目】C.2.1.1。計画停止の有無は、システムの可用性の実現レベルを表す項目であると共に、運用・保守性に関する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。

【運用コストへの影響】計画停止が”有り”の場合、事前のバックアップや、システム構成に応じた手順準備など、運用時のコストがかさむ。

0 計画停止有り（運用スケジュールの変更可）

事前の合意があれば、停止は可能。

[+] 運用時間外での停止だけで対応可能な場合

1 計画停止有り（運用スケジュールの変更不可）

24時間無停止での運用は必要ない。停止可能な時間が存在し、計画的な停止は可能。

[-] 運用スケジュールとしては停止可能な時間帯は存在しないが、事前の調整で停止が可能な場合[+] 24時間無停止が要求される場合

2 計画停止無し


[-] 運用スケジュールとして停止可能な時間帯が存在し、計画停止の必要性がある場合

A.1.2.1

○

対象業務範囲

内部向けバッチ系業務

内部向けオンライン系業務

内部向け全業務

外部向けバッチ系業務

外部向けオンライン系業務

全ての業務

【メトリクス】ここでの対象業務範囲とは、稼働率を算出する際の対象範囲を指す。

【レベル】内部向けとは対象とするシステム内に閉じた処理（業務）、外部向けとは他システムとの連携が必要な処理（業務）を表している。

2 内部向け全業務

内部向けの業務が主要業務であり、内部向け全業務が稼働していることがシステム稼働の条件となる。

[+] 外部向け業務も実施しており、必要な業務としている場合

3 外部向けバッチ系業務

外部とのバッチ的な処理で業務が主要業務であり、内部向けの業務および外部とのバッチ的な業務が稼働していることがシステム稼働の条件となる。

[-] 外部との業務が必要ない場合[+] 業務継続に、外部とのリアルタイムでの処理が必要な場合

4 外部向けオンライン系業務

外部とのリアルタイムでの処理が主要業務であり、外部向けオンライン業務が稼働していることがシステム稼働の条件となる。

[-] 業務継続に、外部とのリアルタイムでの処理が必要とならない場合

A.1.2.2

○

サービス切替時間

24時間以上

24時間未満

2時間未満 60分未満 10分未満 60秒未満

○

【メトリクス】サービス切替時間とは、想定できる障害（例えばハードウェアの故障等により業務が一時的中断するケースなど）に対して、対策を施すこと（例えばクラスタ構成でのサーバの切替えなど）により、業務再開までに要する時間を指す。

【運用コストへの影響】中断を許容する時間が長くなれば、復旧対策としてはシステムでの自動化から人員による手動での対処に比重が移るため、運用コストへの影響が出てくる。

1 24時間未満

外部向けの業務はなく、1日程度の中断であれば許容できる。

[-] 障害時の対策を必要としない場合[+] サービス切替の影響がある場合（影響度に応じて中断を許容できる時間を検討する）

3 60分未満外部とのオンラインでの業務はあるが、数十分の停止までは許容可能。

[+] オンライン業務においてサービス切替の影響がある場合（影響度に応じて中断を許容できる時間を検討する）

5 60秒未満リアルタイム性が要求されるため、システム停止時は瞬時の復旧が必要となる。

[-] 業務の停止が1時間以内であれば許容できる場合

A.1.2.3

○

業務継続の要求度

障害時の業務停止を許容する

単一障害時は業務停止を許容せず、処理を継続させる

二重障害時でもサービス切替時間の規定内で継続する

【メトリクス】業務継続の要求度とは、発生する障害に対して、どこまで業務を継続させる必要があるかを示す考え方の尺度を示している。システムを構成する機器や部位には、単一障害点SPOF（Single Point Of Failure）が多数存在し、システム停止となるリスクを多く含んでいる。これらのSPOFを許容するか、冗長化などの対策で継続性をどこまで確保するかが要求の分かれ目となる。

1 単一障害時は業務停止を許容せず、処理を継続させる

障害時の業務停止の許容時間に合わせる。

[-] リスクを認識した上、障害発生時の業務停止を許容できる場合[+] コスト増を考慮した上で二重障害による業務停止を防止する必要がある場合

2 二重障害時でもサービス切替時間の規定内で継続する

障害時の業務停止の許容時間に合わせる。

[-] リスクを認識した上、二重障害での業務停止を許容できる場合

2 二重障害時でもサービス切替時間の規定内で継続する

二重障害でも業務継続が前提となる。

A.1.3.1

○

RPO（目標復旧地点）

復旧不要 5営業日前の時点（週次バックアップからの復旧）

1営業日前の時点（日次バックアップからの復旧）

障害発生時点（日次バックアップ+アーカイブからの復旧）

【メトリクス】RLOで業務の復旧までを指定している場合、該当する業務のデータの復旧までが対象であり、業務再開の整合性の確認は別途必要となる。

【レベル3】障害発生時点とは、障害が発生する直前のトランザクションなどの処理が完了している時点のことを指し、障害発生時点まで復旧するためには、発生直前の完了した処理のジャーナルログが保証されていることが前提となる。またジャーナルログをアーカイブすることで、障害発生までの任意の時点への復旧に対応することを想定している。

1 5営業日前の時点（週次バックアップからの復旧）

データの損失はある程度許容でき、週次のバックアップからの復旧とする。

[-] データを持たず、復旧が不要な場合[+] 日次のバックアップからの復旧でないと、データ損失の影響が大きい場合

3 障害発生時点（日次バックアップ+アーカイブからの復旧）

データの損失は許容できないため、障害発生時点までの復旧が原則。

[-] データの損失がある程度許容できる場合（復旧対象とするデータ（日次、週次）によりレベルを選定）

3 障害発生時点（日次バックアップ+アーカイブからの復旧）

データの損失は許容できないため、障害発生時点までの復旧が原則。

A.1.3.2

○

RTO（目標復旧時間）

1営業日以上

1営業日以内

12時間以内

6時間以内 2時間以内【メトリクス】サービス切替時間（A.1.2.2）での復旧時間と異なり、RTOでの復旧時間は、業務の継続対策を実施していない（業務停止となる）ケースでの障害での復旧時間を指している。RLOで業務の復旧までを指定している場合、該当する業務のデータの復旧までが対象であり、業務再開の整合性の確認は別途必要となる。

1 1営業日以内

目標復旧地点を考慮し、システムの規模から判断する。

[-] 業務停止の影響が小さい場合[+] 業務停止の影響が大きい場合

2 12時間以内

目標復旧地点を考慮し、システムの規模から判断する。

[-] 業務停止の影響が小さい場合[+] 業務停止の影響が大きい場合

4 2時間以内

なるべく早く復旧する。

A.1.3.3

○

RLO（目標復旧レベル）

システムの復旧

特定業務のみ

全ての業務

【メトリクス】業務停止を伴う障害が発生した際、何を復旧の対象とするかのレベルを示す。

【レベル0】システムの復旧は、ハードウェアの復旧だけでなくデータのリストアまでを対象とする。

【レベル1】特定業務とは、例えばA.1.2.1対象業務範囲で定義する継続性が要求される業務などを指す。

1 特定業務のみ

主要な業務のみを対象とすることができる。

[+] 業務毎に影響を切り離せない場合

2 全ての業務

全ての業務が稼働していないと影響がある。

[-] 影響を切り離せる業務がある場合

2 全ての業務

全ての業務が稼働していないと影響がある。

[-] 影響を切り離せる業務がある場合

A.1.4.1 目標復旧水準（大規模災害時）

大規模災害が発生した際、どれ位で復旧させるかの目標。大規模災害とは、火災や地震などの異常な自然現象、あるいは人為的な原因による大きな事故、破壊行為により生ずる被害のことを指し、システムに甚大な被害が発生するか、電力などのライフラインの停止により、システムをそのまま現状に修復するのが困難な状態となる災害をいう。

○

システム再開目標

再開不要数ヶ月以内に再開

一ヶ月以内に再開

一週間以内に再開

3日以内に再開

1日以内に再開

【メトリクス】大規模災害としては、RPO、RTO、RLOなどの細かな要求までは確定せず、システム再開目標として大まかな復旧時間を設定する。目標復旧レベルについては、業務停止時の目標復旧水準を参考とする。

1 数ヶ月以内に再開

データの損失はある程度許容でき、週次のバックアップからの復旧とする。

[-] データを持たず、復旧が不要な場合[+] 業務停止の影響が大きい場合

3 一週間以内に再開

大規模災害時は、保管するデータからの復旧により業務を再開する。

[-] 代替機器の調達や、復旧体制の準備に時間がかかる場合[+] 業務停止の影響が大きく、DRサイトによる早急な復旧が必要な場合

4 3日以内に再開

ライフラインの復旧を考慮し、システムとして最大限の回復に努める。

[+] 人命に影響を及ぼす、経済的な損失が甚大など、安全性が求められる場合

A.1.5.1 稼働率明示された利用条件の下で、システムが要求されたサービスを提供できる割合。明示された利用条件とは、運用スケジュールや、目標復旧水準により定義された業務が稼働している条件を指す。その稼働時間の中で、サービス中断が発生した時間により稼働率を求める。 ○

稼働率 95%以下 95% 99% 99.9% 99.99% 99.999% 【レベル】24時間365日の稼働の場合、1年間で業務が中断する時間の合計は、それぞれ以下の通りとなる。95%・・・・・・・・・18.3日99%・・・・・・・・・87.6時間99.9%・・・・・・・ 8.76時間99.99%・・・・・・ 52.6分99.999%・・・・・ 5.26分

また1日8時間で週5日稼働のシステムではサービス切替時間と稼働率の関係は以下の通りとなる。週に1時間・・・・97.5%月に1時間・・・・99.4%年に1時間・・・・99.95%

2 99% 1年間で数時間程度の停止を許容。

備考に記載した稼働率での目安となる稼働時間を参考にして決定する。

4 99.99% 1年間で1時間程度の停止を許容。 5 99.999% 1年間で数分程度の停止までしか許容できない。

A.2.1.1 冗長化（機器）

非冗長構成

特定のサーバで冗長化

全てのサーバで冗長化

【メトリクス】冗長化における機器、コンポーネントは、冗長化の単位を表し、機器は筐体を複数用意することによる冗長化、コンポーネントは筐体を構成する部品（ディスク、電源、FAN、ネットワークカード等）を複数用意することによる冗長化を指す。また、仮想化技術の適用により、同一ハードウェア上にサーバ機能を集約させることで、冗長化に必要なハードウェア所要量を削減することも可能である。いずれにしても、ハードウェア上で実現される業務継続性の要求を満たすよう機器の冗長化を検討する必要がある。

【レベル1】特定のサーバで冗長化とは、システムを構成するサーバの種別（DBサーバやAPサーバ、監視サーバなど）で冗長化の対応を分けることを意味する。また要求としてサーバの単位ではなく、業務や機能の単位で冗長化を指定する場合、それを実装するサーバを想定してレベルを設定する。

A.2.1.2 冗長化（コンポーネント）

非冗長構成

特定のコンポーネントのみ冗長化

全てのコンポーネントを冗長化

【レベル1】サーバを構成するコンポーネントとして、内蔵ディスクや、電源、FANなどを必要に応じて冗長化することを想定している（例えば内蔵ディスクのミラー化や、ネットワークIFカードの2重化など）。

可用性

項番大項目中項目小項目小項目説明

重複項目

重要項目

メトリクス(指標)

レベル運用コストへの影響

備考

社会的影響が殆ど無いシステム社会的影響が限定されるシステム社会的影響が極めて大きいシステム

選択レベル選択レベル選択レベル

継続性運用スケジュール

システムの稼働時間や停止運用に関する情報。

業務継続性可用性を保証するにあたり、要求される業務の範囲とその条件。

目標復旧水準（業務停止時）

業務停止を伴う障害が発生した際、何をどこまで、どれ位で復旧させるかの目標。

サーバ耐障害性サーバで発生する障害に対して、要求されたサービスを維持するための要求。

改変・再配布が可能

スプレッドシート化

活用シート



非機能要求グレードの利用時期の例

ゴールは「開発」を開始するために十分な要求項目の確認・決定参考： SECBOOKS 「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～」（オーム社刊）

モデルシステムグレード表・樹系図項目一覧・樹系図

経営層

業務部門

情報システム

部門

ベンダ業務要件定義作成支援

システム要件定義

システム要件定義作成支援

提案・見積

承認

承認

事業要件定義

業務要件定義

レビュー（要件定義書

・予算）

実行稟議

発注検討

モデル決定

利用利用利用

詳細化

作成

RFP



非機能要求グレードの活用例

共通インフラ基盤や社内グレードが存在する場合には要求を段階的に確認することで、非機能要求グレードを効果的に活用できることがわかりました。

※経済産業省「非機能要求グレード評価委員会報告書」を元に作成

システム共通基盤・設備・社内規程システム共通基盤・設備・社内規程可用性（ネットワーク機器、災害対策）運用性（運用管理方針）セキュリティ（セキュリティ前提条件）環境・エコ（データセンタの仕様） etc

社内ランクＡ社内ランクＡ社内ランクＢ社内ランクＢ社内ランクＣ社内ランクＣ可用性=超高セキュリティ=高社会的に影響がある

可用性=高セキュリティ=中全社的業務に影響がある

可用性=低セキュリティ=低社内ローカルシステム

性能･拡張性（ユーザ数、同時アクセス数）移行性（移行方式）システム環境・エコ（システム特性）etc

共通基盤：共通インフラ基盤・社内規則等あらかじめ

レベルが決まっている項目

社内グレード：各社独自のシステム分類定義によってレベルが分かれる項目

個別調整項目：

構築するシステムに応じてレベルが異なる項目

社内グレード別に、項目のレベルを定義したセットを作っておく項目一覧を用いて

設定値を決めておく

毎回個別にレベルを検討・調整して決める



業界全体への普及（期待）

完成した非機能要求グレードが業界の皆様によって様々な形で活用されることを期待

ITベンダーだけでなく、ユーザ企業での利用を期待

社内標準への取り込み業種・業界向けに

カスタマイズ

教育コンテンツ化 RFPへの掲載



「非機能要求グレード」による効果「非機能要求の見える化」を通じ、利用者・社会・開発者

の発展に貢献

社会・ＩＴ業界

業務への情報システムの影響を明確に把握情報システムの安心・安全な利用や効率的利用情報システム費用の説明根拠の明確化

利用者

より安心・安全で便利な社会インフラの実現

健全な業界構造と業界発展（受発注関係や責任の明確化）

開発者

システム開発における手戻りコストの圧縮・期間短縮

システム運用におけるトラブルの減少・削減

その結果その結果

・過不足のないシステム基盤

・稼働遅延の防止



【参考】非機能要求関連の諸活動経済産業省「ソフトウェアメトリクス高度化プロジェクト」で

整理中

JUASJUAS

JEITAJEITA

IPA/SECIPA/SEC

企画要件定義開発運用・保守

非機能要求仕様定義ガイドライン（ＵＶＣ Ⅱ）非機能要求に関して、各フェーズで実施すべきことと、

検収フェーズでの評価指標を提示各フェーズのユーザとベンダ間の役割分担も提示

民間向けITシステムのSLAガイドライン運用時のサービスの要求レベルを定義し合意することでサービス運用の品質を高める考え方提示

非機能要求記述ガイドアーキテクチャ設計を実施するために

非機能要求を正確に記述する方法を提示

非機能要求グレード要求の定義段階での非機能要求のグレード（要求レベル）を開発に入る前に利用者と開発者間で確認し合意する手段を提示

システム基盤構築の判断（難度や費用）に直結



IPA SECでの今後の取り組み

非機能要求グレードをより多く使ってもらうために、推進活動を行っていきます。

非機能要求グレードは次のURLから公開しています。是非ダウンロードしてご利用ください。http://sec.ipa.go.jp/reports/20100416.html

非機能要求グレードご紹介 - IPA非機能要求グレードご紹介 - IPA ... 14

Documents

Transcript of 非機能要求グレードご紹介 - IPA非機能要求グレードご紹介 - IPA ... 14