システム基盤の非機能要求の合意手法 - ieice the...

Information-technology Promotion Agency, Japan

Software Engineering Center

Software Engineering Center Copyright© 2010,2011 Information-technology Promotion Agency, Japan. All rights reserved.

システム基盤の非機能要求の合意手法

２０１１年１１月１８日

独立行政法人情報処理推進機構（IPA）技術本部

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

研究員柏木雅之

SWIM研究会基調講演

SWIM研究会基調講演 2011.11.18 Software Engineering Center 1

SEC Software Engineering for Mo･No･Zu･Ku･Ri

Copyright © 2010,2011 IPA, All Rights Reserved

非機能要求の重要性と課題

1




１-１情報システムの社会基盤化と高度化

情報システムはビジネス・社会活動を支える基盤であり、ビジネス・社会活動の発展に伴い要求も高度化

情報システムの利用者

社内全員

基幹業務担当者

ITと業務の関係

技術変化

数台～数百台

数百台～数千台数千台～

数万・数十万台

社外利用/企業間接続

全社員PC/社内システム

コンピュータセンタバックオフィス

技術的な高度化（複雑なシステム要素の連携）

利活用の高度化（利用範囲の拡大）

社会活動・ビジネスと情報システムが直結（情報システムの社会基盤化と高度化）

社外企業

一般消費者

ビジネスニーズへの迅速な対応要請の高まり。

情報システムのリスクがビジネスリスクに直結！（非機能要求項目への

対応の必要性）

参考：情報サービス白書２００９ P.143




1 1

0

1

3

2

1

0 0

1

0 0 0 0 0 0 0

1

0 0

2

1

10

4 4 4

1

4

3

4

6

5

7

4

7

5

6

0

6

3

4

1

0

1 1

2

1

2 2

1 1

2

1

2

3

0

1

0 0

2 2

1 1

0

2

4

6

8

10

2005.7

2005.9

2005.1

1

2006.1

2006.3

2006.5

2006.7

2006.9

2006.1

1

2007.1

2007.3

2007.5

2007.7

2007.9

2007.1

1

2008.1

2008.3

2008.5

2008.7

2008.9

2008.1

1

2009.1

2009.3

2009.5

2009.7

2009.9

2009.1

1

2010.1

2010.3

2010.5

2010.7

2010.9

月別

１-２情報システムの障害件数の推移（報道ベース）

月別件数

年月

2005 2006 2007 2008 2009 2010

3.1件/月

4.5件/月

1.3件/月 1.１件/月




１-３「品質」に“悪い影響を与える”要因とは

要件定義など上流工程の改善が品質向上に効果的

出典：情報サービス産業協会（JISA) 「情報サービス産業における受託ソフトウェア開発実態アンケート調査」 2005より

品質に悪い影響を与える要因は？

14%

外注管理

6%

4% 3%

進捗管理 2%

1%

要件定義

33%

21%

開発体制

16% 要員の技術力とその維持/ トレーニング

プロジェクト計画

構成管理（変更管理）

レビュー活動

プロジェクト間又は組織間の調整




１－４システム障害の要因とは

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年間に要件定義の問題が改善されていない

6 SWIM研究会基調講演 2011.11.18 Software Engineering Center


発見工程別相対修正コスト

ソフトウェアテスト

システムテスト

運用テスト

システム仕様

プログラミング

要件定義

システムテスト

運用テスト

ソフトウェア仕様

ソフトウェアテスト

5

10～100

修正

コ

ス

ト

右の出典：B.W.Boehm “Soft. Eng.” IEEE Trans. com (Nov ‘76)

1-5 稼働直前に判る要件定義の問題

SEC-BOOKS『経営者が参画する要求品質の確保』（P26)より

Copyright © 2010 IPA, All Rights Reserved

システム開発における手戻り発生工程とコストの関係




1-6 情報システムの信頼性は、非機能要求で決まる！

今やビジネスの多くは、情報システムに大きく依存

情報システムの停止＝ビジネスの停止

情報システムのリスク＝ビジネスのリスク

情報システムの信頼性向上は、ビジネス戦略を実現

するＩＴ戦略上の重要な課題

社会的影響が大きい情報システムの信頼性向上は必須

一方、社会的影響が小さいシステムは、過度の信頼性を

実現する必要なし

情報システムの信頼性などはビジネスで必要とする

非機能要求が左右する




【ご参考】非機能要求関連の各種活動

JUAS

JEITA

IPA/SEC

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

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

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

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

非機能要求グレード要求の定義段階での非機能要求のグレード（要求

レベル）を開発に入る前にユーザとベンダ間で確認し合意する手段を提示。

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

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

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

JISA REBOK

要件定義の知識体系。非機能要求も含む




１－７誰が要求するのか？

顧客の要求？

顧客自身が意識していない要求もある

意識的要求

無意識の要求（社内ルール、業界の商習慣など）

顧客以外（ステークホルダ：取引先、監督官庁など）の要求もある

⇒ 顧客に聞いても分からない要求がある！



出典：共通フレーム2007「ソフトウェアとシステム」に追記

Copyright © 2010 ＩＰＡ, All Rights Reserved

1-８事業、業務、システム要求の関係

事業

人による活動

人による活動業務D

業務C

業務A

人による活動

システム人による活動

システム

人による活動

システム

業務B

業務E

業務E 人による活動

システム

システム利用

ハードウェアソフトウェア

その他設備 (ネットワークなど)

事業/業務とシステム/ソフトウェアとの関係

業務要件のブレークダウン

業務要件

システム要件

システム要件

機能要件

ソフトウェア要件

アーキテクチャ設計

非機能要件

要件定義

システム設計

ソフトウェア設計



開発者のステークホルダ

ユーザ企業のステークホルダ

顧客社内ユーザ

企画／業務設計担当

システム開発担当

経営者

監督官庁

開発グループ

アウトソーサ

ヘルプデスク

コールセンタ

運用・業務支援グループ

代理店企業・個人ユーザ

顧客社外ユーザ SECBOOKS 共通フレーム2007(第2版)P.6

「コミュニケーションチャネルの複雑さ」を参考

オフショア

ソフトハウス

開発ベンダ

Copyright © 2010 ＩＰＡ, All Rights Reserved

システム開発におけるステークホルダーの増加により、発注者間、発注者と開発者間の認識の齟齬、意思伝達の漏れが多く発生

1-９要件定義のステークホルダー

企画／業務設計担当

システム開発担当

経営者




1-10 要求と要件

英語ではどちらも「Ｒｅｑｕｒｅｍｅｎｔ(ｓ）」 ANSI/EIA-632の要求の定義製品が「何を、どれほどよく、どういった状態

で」与えられた目的を達成するかを決めるもの合意、計画、仕様のような標準となる文書

IEEE1220の要求の定義曖昧さがなく、テストあるいは計測が可能で、製品や

プロセスを顧客あるいは内部の品質管理部門が受領に必要である、製品やプロセスの運用面、機能面、設計特性、制約を規定した文書

一般には、要求とは「～したい」という利用者の願望要件とは要求を実現するためにシステムが備えるべきもの

ここでは、要件＝要求とし、同じ意味で扱う




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

1-11 機能要求と非機能要求

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

機能要求

機能要求（プロセス）

機能要求（データ）

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

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

セキュリティ

移行性

運用・保守性

性能・拡張性

可用性品質要求

運用・操作要求技術要求

その他要求

移行要求

付帯作業

その他

非機能要求

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

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




【参考】非機能要求の啓発用小冊子

非機能要求が難しいので啓発用小冊子を作成

A5版 48ページカラー 4/27にPDFをWeb公開。小冊子の構成 •第1部車選びと情報システム ⇒両者の非機能を対比して説明 •第2部非機能要求とは ⇒非機能要求の説明




【参考】車選びと情報システムの非機能要求の対比例

車選び情報システム

車検やディーラのサービス保守

故障の少なさ可用性

定員将来の拡張性（処理量）

エンジンの排気量性能

コーナーセンサー、後方カメラ、縦列駐車アシスト機能

運用の容易性、安全性

燃費消費電力、ＣＯ２排出量




機能要求はシステム化したい「業務」だが非機能要求は様々で曖昧

1-12 システムに対する機能要求と非機能要求の例

非機能要求

機能要求

製造販売物流会計分析 EUC

障害が発生してもサービスは極力止め

ないでほしい

事務室内で運用したい

情報漏洩、ウィルス混入は防止してほしい

いつでも、誰でもどこでも使える

ようにしてほしい

情報は確実に保全してほしい

この業務をシステム化したい

対象業務は全てor特定？「極力」で許容される時間は１分、１０分、or１時間？

サービス時間帯は２４Ｈ、９～２１時、 or ９～１７時？

対象ユーザ数はどのくらい？セキュリティ認証の程度は？

どこでもの範囲は？建屋内、同一県内、

国内 or 海外？

データの暗号化の範囲は？暗号化の鍵管理方法は？

不正アクセスの追跡範囲は？




非機能要求の多くは「システム基盤」にて実現

１-13 非機能要求の実現要素

非機能要求

機能要求

製造販売物流会計分析 EUC

ＨＷ／ＮＷ機器による実現

ＯＳ、ミドルウェアによる実現

制御/運用アプリケーションによる実現

分かり易い操作、容易な業務変更、ｱﾌﾟﾘｹｰｼｮﾝ性能

システム運用・調達の仕組み、体制による実現

(運用設計にて検討)

システム基盤業務アプリ




お客様（発注者）とベンダの間で認識のギャップがある

１-14 非機能要求に関する課題（1/2)

お客様（発注者）開発ベンダ（受注者）

技術的でイメージできない

業務にあった要求が示せない

わかりやすく説明できない

期待レベルが把握できない

業務ごとに最適解が異なる

ベンダから提案してほしい

どう提示してよいかわからない

何を提案してよいかわからない




１-14 非機能要求に関する課題（2/2)

非機能要求のギャップがシステム開発・運用のリスクとなる

具体化が進んでいない上流工程で決めきることは困難発注者・受注者で共通認識を持てない、合意できない

ベンダ

（受注者）

システム開発（プロジェクト運営）の成否へ影響

[基盤の変更、下流で問題発覚]

システム運用上のリスク拡大 [想定外、あるいは、

極限状態での利用運用]

リスク誘発

結果

ユーザ（発注者）




１-15 要件定義書における非機能要求の課題

多くの要件定義成果物において非機能要件記述が体系的に記述されておらず、そもそもどのような項目を記述すべきかが理解されていない要求定義成果物の中に散在する

実現すべき程度（レベル）があいまい。

散在する非機能要求間に矛盾がある

非機能要求が網羅的でない

非機能要求の分類に一貫性を欠く

非機能記述の根拠付けおよび優先順位付けができない

例：出張申請機能は、勤怠管理と旅費精算を行うための機能で、 … （中略） … 本人または指定された代行者が申請し、利用者にストレスを感じさせない応答を実現すること。

何をどの程度に決めるのかが難しい




非機能要求グレードのコンセプトと構成

２




2-1 非機能要求グレードの構成

非機能要求グレードは次の３つの図表（③④⑤）と２つのガイド（①②）から構成される。

さらに、自由にカスタマイズできるスプレッドシート（⑥）を用意している。

②利用ガイド（利用編）

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

①利用ガイド（解説編）

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

③グレード表

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

④項目一覧

非機能要求項目をユーザ／ベンダ間で漏れなく共通に認識できるよう体系化した一覧表

⑤樹系図

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

⑥活用シート

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




2-1 （１）利用ガイド

用途別に２種類の利用ガイドを整備

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

1. はじめに

1.1 非機能要求グレード策定の背景とねらい

1.2 非機能要求の問題と非機能要求グレードの解決方法

1.3 非機能要求グレードのスコープ

1.4 非機能要求グレードの概要

2. 非機能要求グレードの詳細説明

2.1 非機能要求グレードの詳細説明

2.2 各大項目の概要と留意事項

3. FAQ

4. 用語集

5. 付録

5.1 非機能要求に関する他活動との関係について

5.2 他活動との関係について

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

1.非機能要求グレードの概要

2.開発プロセスと非機能要求グレードの利用の関係

3.基本的な利用例

4.いろいろな利用例

5.留意事項




2-1 （２）グレード表：モデルシステムシート

モデルシステムシート

３つのモデルシステムにおいて、特徴を表す非機能要求を整理したものモデルシステムの定義




【参考】モデルシステムの非機能要求

モデルシステムを定義するにあたり、個々のモデルシステムに対する非機能要求を典型的な１６の特徴で定義した。

モデルシステム

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

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

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

可用性

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

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

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

目標復旧水準

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

大規模災害

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

性能・

拡張性

性能目標

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

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

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

運用・保守性

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

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

バックアップ

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

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

：：：

非機能要求の特徴モデルシステムの定義




【ご参考】モデルシステム名

モデルシステム名は「重要インフラ情報システム信頼性研究会報告※」から引用

注：「Type Ⅳ：人命に影響、甚大な経済損失」はType Ⅲに含めて検討

※ http://sec.ipa.go.jp/reports/20090409.html




2-1 （２）グレード表：グレード表

グレード表ユーザの視点で非機能要求を抽出

要求レベルグレードの定義重要な非機能要求項目




2-1 （２）グレード表：グレード

グレードの定義

選択レベル：個々のメトリクスに対して、該当するモデルシステムを想定して選択したレベル。ベース値と呼ぶ。

選択時の条件：ベース値を選択したときの条件。さらに、ベース値を調整する際の条件を[＋][－]で示した。




2-1 （３）項目一覧

システム基盤に関わる非機能要求項目と要求レベルを一覧化した表

ユーザ／ベンダが合意すべき非機能要求を網羅

要求項目要求レベル

低

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

要求レベルにより具体的な選択肢を提示

高

重複項目他の大項目に同じ項目があるかどうかの識別

重要項目 QCDに大きな影響がある項目（グレー

ド表対象項目）

運用コストへの影響要求される要求ﾚﾍﾞﾙに

要するｺｽﾄと運用ｺｽﾄとの間にﾄﾚｰﾄﾞｵﾌがある項目を示す

備考（補足説明）

メトリクス（指標）当該項目を定量的に表現

するための指標




2-1 （４）樹系図

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

前

後

後

重要な非機能要求項目検討順序




2-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時間無停止」は、オンライン業務が稼動していない時間にバッチを稼動させる必要があり、システムを停止することができないようなケースも含まれる。

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

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

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

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

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

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

5 24時間無停止

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

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

A.1.1.2

○

運用時間（特定日）規定無し定時内（9時～17時）




24時間無停止


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

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

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


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

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

5 24時間無停止


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

A.1.1.3

○

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

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

計画停止無し

○

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

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

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

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

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

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

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

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

2 計画停止無し


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

項番大項目

中項目

小項目小項目説明

重複項目

メトリクス(指標)

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

備考

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

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

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

継続性

可用性

…

0 1 2 3 4 5

A.1.1.1

○ ○

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




24時間無停止



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

A.1.1.2

○ ○

運用時間（特定日）

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




24時間無停止


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

A.1.1.3

○ ○

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

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

計画停止無し

○

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

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

可用性継続性


備考

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

小項目説明

重複項目

重要項目


項番大項目中項目小項目

…

② 項目一覧：03_hikinou_list_201002.pdf

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

C.1.1.1

○ ○

運用時間（通常）





24時間無停止

【重複項目】A.1.1.1。運用時間（通常）は、システムの可用性の実現レベルを表す項目でもあるため、重複項目となっている。


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


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

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

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

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

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

5 24時間無停止


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

C.1.1.2

○ ○

運用時間（特定日）





24時間無停止

【重複項目】A.1.1.2。運用時間（特定日）は、システムの可用性の実現レベルを表す項目でもあるため、重複項目となっている。

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

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

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


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

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

5 24時間無停止


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

C.1.2.1

○

データ復旧範囲

復旧不要一部の必要なデータのみ復旧

システム内の全データを復旧

【重複項目】A.2.6.2。可用性ではデータをどこまで保全するかという観点で、運用ではデータをどこまで復旧させるかという観点で本項目が必要となり、重複項目としている。

【メトリクス】システムを障害から復旧するためには、データバックアップ以外に、OSやアプリケーションの設定ファイル等を保管するシステムバックアップも必要となることが考えられる。システムバックアップの取得方法や保管方法についても、同時に検討すべきである。

【レベル1】一部の必要なデータとは、業務継続性の要求を満たすために必要となるようなデータを想定している。

C.1.2.2

○

外部データの利用可否

全データの復旧に利用できる

一部のデータ復旧に利用できる

外部データは利用できない

【メトリクス】外部データとは、当該システムの範囲外に存在するシステムの保有するデータを指す（開発対象のシステムと連携する既存システムなど）。外部データによりシステムのデータが復旧可能な場合、システムにおいてバックアップ設計を行う必要性が減るため、検討の優先度やレベルを下げて考えることができる。

1 一部のデータ復旧に利用できる

他システムから必要なデータを修復することができるため、バックアップによってシステムの全データを復旧しなくてもよいことを想定。

[-] 外部に同じデータを持つシステムが存在するため、バックアップを取得しなくても本システムの全データを復旧できるような場合

2 外部データは利用できない

全データを復旧するためのバックアップ方式を検討しなければならないことを想定。

[-] 外部に同じデータを持つシステムが存在するため、本システムに障害が発生した際には、そちらからデータを持ってきてシステムを復旧できるような場合

2 外部データは利用できない

全データを復旧するためのバックアップ方式を検討しなければならないことを想定。

[-] 外部に同じデータを持つシステムが存在するため、本システムに障害が発生した際には、そちらからデータを持ってきてシステムを復旧できるような場合

C.1.2.3

○

バックアップ利用範囲

バックアップを取得しない

障害発生時のデータ損失防止

ユーザエラーからの回復

データの長期保存（アーカイブ）

【レベル2】ユーザエラーからの回復の場合、システムとしては正常に完了してしまった処理を元に戻さなければならないため、複数世代のバックアップの管理や時間指定回復（Point in Time Recovery）等の機能が必要となる場合が考えられる。

1 障害発生時のデータ損失防止

障害発生時に決められた復旧時点（RPO）へデータを回復できれば良い。

[-] 障害時に発生したデータ損失を復旧する必要がない場合[+] 復旧時点（RPO）が固定ではなく、障害の内容に応じて時間指定で復旧する必要がある場合

2 ユーザエラーからの回復

管理者の作業ミスなどによって発生したデータ損失についても回復できることを保証したい。

[-] 管理者の作業ミスによる復旧は管理者が作業前に個別にデータ保全作業を実施することで担保することとし、バックアップによる回復は必要としない場合[+] データ損失からの回復だけでなく、過去データの保存用途に用いる場合

3 データの長期保存（アーカイブ）

内部統制対応の要件に基づき、データの履歴を保存する必要がある。

[-] バックアップはデータ損失からの回復に対する用途にのみ使用する場合

システムが利用するデータのバックアップに関する項目。

運用・保守性

通常運用

運用時間システム運用を行う時間。利用者やシステム管理者に対してサービスを提供するために、システムを稼動させ、オンライン処理やバッチ処理を実行している時間帯のこと。

バックアップ

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

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


備考


小項目説明

重複項目

重要項目


項番大項目

中項目

小項目

…

…

①

＋

②

＝

③

項目一覧と同一の情報（236項目分：「項目」「レベル」「備考」など）

グレード表で追加されている情報（92項目分：モデルシステムのレベル値）

① グレード表： 02_hikinou_grade_201002.pdf

③ スプレッドシート：05_hikinou_sheet.xls




2-2 非機能要求項目の体系化

システム基盤に関する非機能要求を大きく６項目に分類大項目要求例確認結果に基づき、実施する対策例

可用性運用スケジュール

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

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

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

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

性能・

拡張性

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

システム化対象業務の特性（ピーク時、通常時、縮退時など）

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

将来へ向けた機器・ネットワークなどのサイズと配置＝ｷｬﾊﾟｼﾃｨ･ﾌﾟﾗﾝﾆﾝｸﾞ

運用・

保守性

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

問題発生時の対応レベル

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

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

マニュアルの整備

移行性新ｼｽﾃﾑへの移行期間および移行方法

移行対象資産の種類および移行量

移行スケジュール立案、移行ツール開発

移行体制の確立、移行リハーサルの実施

ｾｷｭﾘﾃｨ利用制限

不正アクセスの防止

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

不正の追跡、監視、検知

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

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

CO2排出量や消費エネルギーなど、エコロジーに関する事項

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

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




２-２非機能要求項目の体系

非機能要求を６つの大項目に分類し、さらに具体的な項目に細分化

大項目

中項目

中項目

小項目

小項目

小項目

メトリクスメトリクス

メトリクス

メトリクス

…

非機能要求を体系的に整理したときの最も広い分類

検討すべき単位で小項目をまとめた分類

ユーザと開発ベンダの間で合意される非機能要求を示す項目の分類

小項目を定量的に表現するための指標

（システムの開発コストや品質に影響を与える度合いの大きいメトリクスを

重要項目とする。）




【ご参考】ソフトウェア品質基準（ISO/IEC 9126-1：2001）との関係

システム基盤の非機能要求を対象としている非機能要求グレードとは一概に比較できないが、用語は可能な範囲でISO/IEC 9126 を参考

ＩＳＯ／ＩＥＣ 9126-1:2001 非機能要求項目（大項目）

ＩＳＯ／ＩＥＣ 9126-1:2001 非機能要求項目（大項目）特性副特性特性副特性

機能性合目的性 × 効率性時間効率性性能・拡張性

正確性 × 資源効率性性能・拡張性

相互運用性 × 効率性標準適合性性能・拡張性、システム環境・エコロジーセキュリティセキュリティ

機能性標準適合性セキュリティ、システム環境・エコロジー

保守性解析性運用・保守性

変更性 ×

信頼性成熟性可用性安定性 ×

障害許容性可用性試験性 ×

回復性可用性、運用・保守性

保守性標準適合性運用・保守性、システム環境・エコロジー

信頼性標準適合性システム環境・エコロジー移植性環境適用性移行性

使用性理解性 × 設置性システム環境・エコロジー

習得性運用・保守性共存性移行性

運用性運用・保守性置換性移行性

魅力性 × 移植性標準適合性システム環境・エコロジー

使用性標準適合性システム環境・エコロジー




２-３非機能要求グレードの基本コンセプト（１）

レベルによる要求項目の共通認識メトリクス毎に実現上必要となるコストや実装上のアーキテクチャの難易度が大きく変わるポイントで『レベル』を設定。最大レベル０からレベル５までの６段階で設定。レベル値が大きいほど実現難易度は高くなり、一般に開発コストは増加。レベルで示す値はユーザ／ベンダ間で合意形成を図る出発点とし、最終的に具体的な数値として合意することを想定。

大項目中項目小項目メトリクスレベル

０１２３４５

可用性継続性業務継続性

（可能性を保証するにあたり、要求される業務の範囲とその条件）

対象業務範囲内部向けバッチ系業務

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

内部向け全業務

外部向けバッチ系業務

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

全ての業務

サービス切替時間

２４時間以上

２４時間未満

２時間未満

６０分未満

１０分未満

６０秒未満

業務継続の要求度

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

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

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

レベルの例非機能要求を提示しやすいユーザ

ベンダ非機能要求を確認しやすい




２-３非機能要求グレードの基本コンセプト（２）

グレードによる要求項目の選定利用目的、規模、障害時に社会に与える影響が異なることにより実現水準に有意な差がある３つのモデルシステムを定義。

モデルシステム毎に重要項目の選択レベルと選択時の条件をグレードと定義。

グレードは、非機能要求項目を決定する目安として有効。

モデルシステム名




システムの概要

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

ここでは、ごく小規模のインターネット公開システムを想定している。

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

ここでは、企業内のネットワークに限定した基幹システムを想定している。

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

ここでは、不特定多数の人が利用するインフラシステムを想定している。




２-３非機能要求グレードの基本コンセプト(３)

段階的な要求項目の詳細化モデルシステム、グレード、レベルの考え方を用いて、非機能要求を段階的に詳細化




章扉

非機能要求グレードを利用した非機能要求の合意プロセス例（ケーススタディ）

３

※非機能要求を決める他の方法もあります。




３-１非機能要求グレード利用方法

お客様と段階的に詳細化しながら非機能要求を確認する手法

レベル0 非冗長構成

レベル1 特定のサーバで

冗長化

レベル2 すべてのサーバ

で冗長化

段階① 「モデルｼｽﾃﾑの選定」：開発するシステムに最も近いモデルシステムを１つ選択

段階② 「重要項目のレベル決定」：樹系図で全体を俯瞰し、グレード表でレベル値を決定

調整レベル3

6時間以内に復旧レベル2

12時間以内に復旧

「社会的影響が限定されるシステム」における「目標復旧時間（RTO）」の例

要求により、レベルを調整

冗長化（機器）

・・・

耐障害性

モデルシステムシート（グレード表）

段階③ 「重要項目以外のレベル決定」：項目一覧で非機能要求項目の要求レベルを決定

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



「可用性」の重要項目以外の非機能要求項目を検討する例

調整前調整後

選択

サーバ

中項目小項目メトリクス（指標）

・・・

・・・

選択

グレード表・樹系図

項目一覧・樹系図災害対策システム復旧方針

モデルシステムシートを使用し開発システムに最も近いモデルシステムを選択

高

低




想定システムイメージ

小売店から本部への「商品発注」、「商品受注」、「在庫管理」システムを対象

・・・

小売店Z

小売店A 商品発注

在庫管理

商品受注

業態：ホームセンター

店舗：県内20店舗

システム概要：本部で一括納入・管理している商品の発注～在庫管理までを自動化するシステム。

システムが利用不可能な状態に陥った場合、企業活動に多大の影響を及ぼす。

商品発注

ケーススタディ

本部

プロファイル




段階①：モデルシステムを参考に方向性確認

お客様要求を「段階的詳細化」しながら確認するためのツール「群」


モデルシステムシート

（グレード表）グレード表・樹系図項目一覧・樹系図

イメージレベル重要項目詳細項目

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

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

要求項目を決定

１６項目９２項目２３６項目

段階①




段階①-1 モデルシステムの選択

システムのプロファイルから最も近いモデルシステムを選択

モデルシステム名

社会的影響が

ほとんど無いシステム

社会的影響が

限定されるシステム

社会的影響が

極めて大きいシステム

モデルシステムの

概要

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

ここでは、ごく小規模のインターネット公開システムを想定している。

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

ここでは、企業内のネットワークに限定した基幹システムを想定している。

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

ここでは、不特定多数の人が利用するインフラシステムを想定している。

システム基盤の発注者要求を見える化する非機能要求グレード検討会公開資料「非機能要求グレード」利用ガイドより引用





段階①-2 モデルシステムとの差を確認

選択したモデルシステムと開発するシステムの差を確認する


お客様（発注者）

システムダウンは避けたい

「社会的影響が限定されるシステム」が一番近い

・・・

比較障害時は6時間以内に復旧

被災時は1週間以内で復旧

発注の95%以上を3秒以内

・・・

モデルシステム定義

稼働率99.99% （年間停止許容時間 1時間未満）

1営業日以内での復旧

被災時は1週間以内で復旧

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




「社会的影響が限定されるシステム」の構成イメージ

VPN

WEB /AP

サーバ

DB サーバ

予備サーバ

ストレージ開発環境

正センタ

WEB /AP

サーバ

DB サーバ

予備サーバ保管

拠点内LAN

コールドスタンバイ自動切換

バックアップセンタ

バックエンド

WEB /AP

サーバ

WEB /AP

サーバ


WEB /AP

サーバ




段階②：重要項目のレベル決定

グレード表を用いてコスト等に影響がある重要な要求項目を決定



グレード表・樹系図項目一覧・樹系図

重要項目イメージレベル詳細項目

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

９２項目１６項目２３６項目

方向性の確認コストに大きな影響がある要求項目を決定

段階②




「重要項目」の要求レベルの設定例を用いて、より「早期に」判断

段階②-1 重要項目の調整前ケーススタディ

「重要」な非機能要求項目（抜粋）要求レベルの設定例

重要項目例メトリクス(指標) レベル選択時の条件

業務継続性ｻｰﾋﾞｽ切替時間 3 60分未満

目標復旧水準 RTO(目標復旧時間) 2 12時間以内

稼働率稼働率 4 99.99%

大規模災害時ｼｽﾃﾑ再開目標 3 1週間以内

業務処理量同時ｱｸｾｽ数 1 上限が決まっている

ﾊﾞｯﾁ処理件数 0 件数が決まっている

業務量増大度ｵﾝﾗｲﾝ件数増大率 1 1.2倍

ｵﾝﾗｲﾝﾚｽﾎﾟﾝｽ通常時ﾚｽﾎﾟﾝｽ順守率 3 90%

運用時間運用時間(通常) 4 若干の停止有り

内部統制対応対応実施有無 1 既存の社内規定での対応実施

移行ｽｹｼﾞｭｰﾙｼｽﾃﾑ停止可能日時 4 夜間など

ｾｷｭﾘﾃｨﾘｽｸ分析ﾘｽｸ分析範囲 1 重要資産

地域的広がり地域的広がり 0 拠点内

（１）重要項目毎に、該当モデルにおける標準レベルを選択した条件を示す。

（２）レベルを調整する際の条

件を示す。




「重要項目」の要求レベルの設定例を用いて、より「早期に」判断

段階②-2 重要項目の調整後

「重要」な非機能要求項目（抜粋）要求レベルの設定例

重要項目例メトリクス(指標) レベル選択時の条件

業務継続性ｻｰﾋﾞｽ切替時間 3 60分未満

目標復旧水準 RTO(目標復旧時間) 2 12時間以内

稼働率稼働率 4 99.99%

大規模災害時ｼｽﾃﾑ再開目標 3 1週間以内

業務処理量同時ｱｸｾｽ数 1 上限が決まっている

ﾊﾞｯﾁ処理件数 0 件数が決まっている

業務量増大度ｵﾝﾗｲﾝ件数増大率 1 1.2倍

ｵﾝﾗｲﾝﾚｽﾎﾟﾝｽ通常時ﾚｽﾎﾟﾝｽ順守率 3 90%

運用時間運用時間(通常) 4 若干の停止有り

内部統制対応対応実施有無 1 既存の社内規定での対応実施

移行ｽｹｼﾞｭｰﾙｼｽﾃﾑ停止可能日時 4 夜間など

ｾｷｭﾘﾃｨﾘｽｸ分析ﾘｽｸ分析範囲 1 重要資産

地域的広がり地域的広がり 0 拠点内


（１）重要項目毎に、該当モデルにおける標準レベルを選択した条件を示す。

（２）レベルを調整する際の条

件を示す。レベルダウン

夜間停止：夜間要員不要

レベルアップ順守率：95%以上

レベルアップ復旧時間：6時間以内

仮決め稼働率：後日最終決定




段階③：重要項目以外のレベル決定

システム基盤構築のためのお客様要求を「段階的詳細化」しながら確定



グレード表・樹系図

項目一覧・樹系図

詳細項目重要項目

コストに大きな影響がある要求項目を決定

２３６項目９２項目

段階③

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

方向性の確認

イメージレベル

１６項目




段階③-1 「非機能要求項目一覧」の要求レベルを活用

具体的な選択肢を提示することで「誤解なく」要求を確認

小項目メトリクスレベル

（指標） 0 1 2

サーバ冗長化（機器）非冗長構成特定サーバを冗長化全サーバ冗長化

アーキテクチャ

保守/リカバリ待ち

B

全てのサーバを二重化 DBサーバを二重化

A 冗長

A


障害発生時のサービス中断時間は60分目標

WEB/APサーバは入力を分散させる方式にしよう

DBサーバを冗長化して自動切換、再立ち上げ中は利用できない

最適なのは「レベル1」だ!!

B 冗長 B A

冗長

お客様が直接利用しないので切替後に実施すれば問題ない




段階③-2 「非機能要求項目一覧」の網羅性を活用

チェックリストとして利用することで要求を「漏れ」がないよう確認


要求の確認漏れはないか？

開発フェーズを開始しよう!!

要件定義書仕様書

・・・

非機能要求項目一覧

要求間に矛盾はないか？

記載漏れなどはないか？

仕様は要求を満たしているか？

未決定な項目は合意済か？

要求に誤りはないか？

確認




３-２まとめ：「非機能要求グレード」のメリット

非機能要求を「早期に」判断できる

最初は「モデルシステム」でイメージレベルから確認

「グレード表」で重要な項目に絞ってから検討

１から決めるのではなく、推奨された要求値を「調整」

非機能要求を「誤解なく」提示・確認できる

要求レベルで「具体的な選択肢」を提示

「十分に」「しっかりと」のようなあいまいな表現ではなく、「レベル3で」と具体的に確認

非機能要求を「漏らさずに」確認できる

網羅的な要求項目の一覧をチェックリストとして活用

樹系図による全体を俯瞰することで「矛盾」がないかチェック




非機能要求グレードの開発と評価

４




4-1 非機能要求グレードの作成元

「非機能要求の見える化」という課題に共感したベンダ６社で構成

正式名称システム基盤の発注者要求を見える化する非機能要求グレード検討会（略称：非機能要求グレード検討会）

参加企業

㈱ＮＴＴデータ、富士通㈱、日本電気㈱、㈱日立製作所、三菱電機インフォメーションシステムズ㈱、沖電気工業㈱

活動時期 2008年4月～2010年3月（解散）

設立趣旨

情報システムを開発する際には、受発注者の双方が要求を正確に認識することに多大な労力を使っている。中でも「非機能要求」と呼ばれる要求はその認識共有が難しい、かつ、その手段が確立していない。そこで本検討会は非機能要求の選択肢を提示しメニュー化する「非機能要求グレード」を策定し開発ベンダのみならず、発注者企業を含む業界全体へ広くその利用を働きかける。

IPA へ移管独立行政法人情報処理推進機構

http://sec.ipa.go.jp/reports/20100416.html




4-2 非機能要求グレード検討の経緯

お客様（ユーザ企業）に活用頂けるようご意見を取り入れながら「非機能要求グレード」を開発／改訂した。

IPA/SEC での活動

2008年度 2009年度 2010年度以降

上期下期上期下期

非機能要求項目体系化

実現レベル設定

お客様ヒアリング

お客様机上評価

評価結果反映

パブリックコメント募集

実システムによる評価

評価結果反映

お客様による評価

2010年2月25日 2009年5月26日 2008年9月29日

非機能要求グレード完成版公開

非機能要求項目一覧公開

非機能要求グレード評価版公開




章扉

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

５




５-１非機能要求グレードの基本的な活用シーン

活用シートを適宜加工することでさまざまなワークシートとして活用できる。

（１）要件定義書やＲＦＰに添付上記資料の非機能要求はまとめて書かれていない。

このため、付録などに非機能要求を添付して抜け・もれチェックに使う。また、まとめることで矛盾や優先順位の検討が容易になる。

（２）非機能要求ヒアリング用シート

要件定義を行う場合、業務担当者や運用担当者に非機能要求を確認する際に使う

（３）非機能要件チェックシート

第三者が非機能要求グレードを使わずに作成した要件定義のチェックを行う時に使う

（４）既存のシステム診断シート

既存のシステムの非機能要求が正しく設定されているかを診断し、ITリスクや過剰なシステムを把握




5-2 共通インフラ基盤や社内グレードとしての活用例

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

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

システム共通基盤・設備・社内規程可用性（ネットワーク機器、災害対策）

運用性（運用管理方針）セキュリティ（セキュリティ前提条件）環境・エコ（データセンタの仕様） etc

社内ランクＡ社内ランクＢ社内ランクＣ可用性=超高セキュリティ=高

社会的に影響がある

可用性=高セキュリティ=中

全社的業務に影響がある

可用性=低セキュリティ=低

社内ローカルシステム

性能･拡張性（ユーザ数、同時アクセス数）移行性（移行方式）

システム環境・エコ（システム特性） etc

共通基盤：共通インフラ・社内規則等あらかじめ決まっている項目

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

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

社内グレード毎に、レベルを定義したセットを作っておく

項目一覧を用いて設定値を決めておく

毎回個別にレベルを検討・調整

して決める




５-３ (1)クラウドサービスと非機能要求グレード

業務アプリケーション

実行基盤

ハード、OS、ミドルウェア

：利用者が決めることができる（自分で作る）

：利用者が決めることができない

オンプレミス IaaS PaaS SaaS

非機能要求（可用性、性能・拡張性、運用保守性、

移行性、セキュリティ、システム環境・エコロジー、

ユーザビリティ等）

機能要求 (業務フロー、データ項目等)

非機能要求

グレードの対象

クラウドサービスは、作るから選択への転換




５-３ (2)クラウドサービスでも非機能要求が大切

次のステップでクラウドサービスを検討：

1. 利用者の要求を明確にする（機能、非機能とも）

2. クラウドサービスの機能・SLA(=非機能要件)を評価する。

⇒クラウドサービスの情報開示が必要

3. 双方の要件のすり合わせ⇒「割り切りも必要」クラウドの利便性の裏にある、ITリスクの把握をする

要件を満たさない場合、ビジネス側でITリスクの担保や受容

Ex. クラウドサービスが何らかの理由で使えない場合に備え、人手の作業で業務を代行するなどの対策を講じておく。

利用者

非機能要求ＳＬＡ

クラウドサービス

検証、リスクの担保・受容

クラウドサービス




章扉

おわりに

６




６-１非機能要求グレードの課題

モデル数が３種類と少ない社会的影響度（＝可用性）で３段階。もっと段階数を増やしたり、

セキュリティの切り口のグレードがほしいとの要望あり。

クラウドサービス用のモデルも必要と考える。

システム基盤に限定しているアプリケーションセキュティや操作性（ユーザビリティ）などは、

未対応

要求レベルの変動に対応できていない⇒最大レベルで対処? 人気のチケット販売では、発売当初のアクセスがピークで、その後

は少ないCPU取引量

各種申請の申し込み期限にダウンしてはいけないが、それ以外の時は多少ダウンしても許される。

仮想化やクラウドに対応できていない仮想化したリソースの可用性や拡張性などへの対応が必要

経営層への訴求が難しい経営層には、投資コストや事業リスクでの訴求が重要だが、まだ技

術用語での説明




６-２今後の計画

2010年度は、非機能要求グレードの普及活動がメイン

各種セミナー

啓発用の読本（2011年４月末公開）

事例集（2011年４月末公開）

英語版の公開(２０１０年１２月末公開）

2011年度は、下記を準備中

モデルシステムのカストマイズの説明方法を検討中

追加の事例集（2012年3月末公開予定）

他の標準との棲み分けの提示

など




ご静聴ありがとうございました。

非機能要求グレードをお使いいただいた、ご意見・ご感想をお寄せください。

E-mail:[email protected]




章扉

ご静聴ありがとうございました。

非機能要求グレードをお使いいただいた、ご意見・ご感想をお寄せください。

E-mail:[email protected]

システム基盤の非機能要求の合意手法 - ieice the...

Documents