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

Software
Engineering
Center
Information-technology Promotion Agency, Japan
『非機能要求グレード』活用事例集
2011年4月27日
独立行政法人情報処理推進機構 (IPA)
ソフトウェア・エンジニアリング・センター (SEC)
Copyright© 2011 Information-technology Promotion Agency, Japan. All rights reserved.
Software Engineering Center
SEC
使用条件
Software Engineering
for Mo･No･Zu･Ku･Ri
1. 本資料の著作権は、独立行政法人情報処理推進機構(IPA)が保有しています。
2. 独立行政法人情報処理推進機構は、「本資料の全部又は一部を複製、改変、公衆送信、又は翻
訳/翻案し、第三者に有償又は無償で再配布すること」を許諾します。なお、複製し再配布する場
合は、実際の契約書として使用する場合を除き、本使用条件を添付し、本使用条件に記載されて
いる条件を配布先に遵守させて下さい。改変又は翻訳/翻案し再配布する場合は、実際の契約書と
して使用する場合を除き、新しく使用条件を設定することが可能ですが、本使用条件を必ず含め
て下さい。
3. 独立行政法人情報処理推進機構は、本資料が第三者の著作権、特許権、実用新案権等の知的財
産権に抵触しないことを一切保証するものではなく、また、本資料の内容に誤りがあった場合で
も一切責任を負いかねます。
4. 独立行政法人情報処理推進機構は、本ページで記載された許諾内容を除き、独立行政法人情
報処理推進機構又は第三者の著作権、特許権、実用新案権等の知的財産権に基づくいかなる権利
を許諾するものではありません。
5. 独立行政法人情報処理推進機構は、本資料の商取引への利用、システム開発への利用、開発さ
れたシステムの使用、及び当該システムの使用不能等により生じるいかなる損害についても、な
んら責任を負うものではありません。
6. 本資料へのお問い合わせについては、独立行政法人情報処理推進機構ソフトウェア・エンジ
ニアリング・センターまでご連絡下さい。
7. 二次利用時に著作権を表示する場合は、次のように表記してください。
 2011年に公開した場合
Copyright © 2011 IPA, 二次著作権者名
 2012年に公開した場合
Copyright © 2011,2012 IPA, 二次著作権者名
 2013年以降に公開した場合
Copyright © 2011-公開年 IPA, 二次著作権者名
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
1
SEC
ご利用にあたって
Software Engineering
for Mo･No･Zu･Ku･Ri
当活用事例集は、「非機能要求グレード」の実際に活用して頂いて
いる企業・団体の皆様のお話やご意見を基に、活用局面に関する情報
を活用事例としてまとめたものです。活用局面をご紹介することで、
「非機能要求グレード」が単なる要件定義時の利用に留まらず、多様
な活用への可能性があることをご理解頂けると幸いです。
各事例内容は、次の項目を中心にまとめています。
 概要およびプロジェクトプロファイルとして業種、業務
 システム概要、利用工程、利用目的、利用方法など
 非機能要求グレードのレベル算出の工数
 利用効果と非機能要求に関する留意点
 活用者視点で気がついた非機能要求グレード利用の
注意点など
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
2
SEC
目次
Software Engineering
for Mo･No･Zu･Ku･Ri
 事例１．予算作成時の利用事例・・・・・・スライド４
 事例２．稼働中システムの再評価・・・・・スライド６
 事例３．非機能要求定義のリファレンス利用
・・・・・スライド９
 事例４．非機能要求定義のチェックに利用
・・・・・スライド１２
 事例５．社内システム開発標準への適用
・・・・・・スライド１４
 事例６．組込システムのソフトウェアアーキテクチャ
策定に利用・・・・・・スライド１８
 事例７．社内開発標準の統合事例・・・・スライド２１
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
3
事例１．予算作成時の利用事例（1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
製造業のA社はプロジェクト予算作成時に、非機能要求グレードのモデル
システムを使って、ざっくりとした予算を算定し、予算見積もりの精度を
高めている。
 業種、業務
製造業、全ての業務
 システム概要
省略（個別システムではない）
 利用工程
予算作成時
 利用目的
予算作成の精度向上、算出根拠の明確化
 利用方法
予算作成時にそれぞれのシステムが非機能要求グレードのどのモデルシス
テムに該当するかを算出し、それを元にベンダにRFIを出して、ざっくり
としたシステム構成や予算額を把握している。
 非機能要求グレードのレベル算出の工数
１システムあたり2人日
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
4
事例１．予算作成時の利用事例（2/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用効果
 システム基盤の予算見積もりの精度が向上し、システム基盤に対する予
算不足や予算余りというプロジェクトが削減できた。
 また、RFIでのベンダの提案間で金額やシステム構成に違いがあれば、原
因を調査し、最適なものにできた。
 非機能要求に対する留意点
過剰や過少ではない、最適なシステム基盤を目標にした。
 非機能要求グレード利用時の注意事項
 非機能要求グレードでは、要求とその程度しか定めていないので、それ
を実現する実際のシステム基盤はベンダによって異なる。
 アプリケーションの非機能要求が対象でない。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
5
事例２．稼働中システムの再評価(1/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
稼動中システムの再評価作業に活用した。暗黙知的に扱っていた非機能要
求項目の明確化、レベルの高低などの確認に活用した。
 業種、業務
金融業
 利用工程、利用シーン
運用工程。稼働中システムの再評価（リスクの把握とコスト削減）
 利用目的
ユーザ部門など社内でのコミュニケーションをとりながら、非機能要求に
関する暗黙知や非機能要求のレベル感を中心とした評価を行うこと。
これらを通じて、稼働中システムのリスク把握とコスト削減を行う。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
6
事例２．稼働中システムの再評価(2/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
 サービス中のシステムの非機能要求を振り返るため、設計工程で作成
したドキュメントを収集し、定義した項目の網羅性・設定したレベル
が明確化されているか振り返って確認した。
 本グレード表の重要項目は、ユーザにとっても比較的分かりやすい言
葉で定義されているため、システム用語に精通していないユーザ部門
の担当者を情報システム部門との認識合わせに利用した。
 利用効果
 実装時の要求レベルの課題を見つけた。今後のリスク回避のための投
資やコストダウンの検討の材料とすることができた。
 システム基盤の設計や運用ノウハウを暗黙知から形式知へ多少転換で
きた。ノウハウの形式知化が進めば、非機能要求は超上流で決めるこ
とができる。
 非機能要求に対する留意点
 クラウドのようなアプリ先行で早期開発可能な状況下では、基盤担当
内での漏れ防止が重要である。
 非機能要求グレード利用時の注意事項
グレード表のレベルの考え方が、多元的である。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
7
事例２．稼働中システムの再評価(3/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
非機能要求グレードの概要
 非機能要求グレードとは、情報システム
2009年5月公開の非機能要求グレード成果物
のシステム基盤の可用性や拡張性などの
非機能要求を明確化し、システム構築に
おける開発ベンダとユーザ企業間の合意
形成を支援する手法である
樹系図
利用ガイド
グレード表
項目一覧
 開発ベンダ企業6社からなる非機能要求グ
レード検討会で策定し、その後IPA/SECに非機能要求グレードのユーザ視点で非機能ユーザ/ベンダが合意す項目一覧の閲覧
構成と利用法の解説書要求を抽出するためべき非機能要求項目を性を補完する図
移管。
の項目
網羅的にまとめたもの
実証評価の概要
 ユーザ企業の実システムへの試行適用を通して、利用効果、利用可能性、課題を評価
■評価作業A
RFP等に記載されている非機能要求からグレード表・項目一覧
を記述
実システム
のRFP等
グレード表
項目一覧
■評価作業C
評価作業A,B結果の比較分析
グレード表（評価作業A）
RFP等の情報より
値を記載した
グレード表
同じシステムであること
差分を分析
実システムの現状
グレード表
項目一覧
Copyright © 2011 IPA, All Rights Reserved
■評価作業B
実システムの現状に係わる資料・ヒアリングからの非機能要求抽出
※RFP：Request for Proposal
Copyright © 2011 IPA, All Rights Reserved
本来RFP等で確認
すべき値が入った
グレード表
グレード表（評価作業B）
Software Engineering Center
8
事例３．非機能要求定義のリファレンス利用（1/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
沖電気工業様では、システム基盤の設計にあたり、「非機能要求グレード」
をリファレンスとして利用し、開発品質の向上を目指した。顧客との合意形
成だけでなく、「グレード表」を一部拡張・調整しながら、プロジェクトメ
ンバ間でシステムの非機能要求に関する知識を共有する場としても利用した
。
 システム概要
人事院の人事・給与関係業務情報システム
 利用工程、利用シーン
ハードウェア調達のための要件定義工程
 利用目的
要件整理、設計の検証
 利用方法（続く）
要件定義書へのインプットとして利用し、議論の入り口として活用した。
顧客と情報共有するために、「活用シート」の空欄にした箇所を埋めてい
く方法で、情報共有した。体系的に広く利用した。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center
9
事例３．非機能要求定義のリファレンス利用（2/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法（続き）
非機能要件定義の項目から基盤設計に反映すべき項目と運用設計に反映
すべき項目をそれぞれ分類して記載し、合意を行った。
要件定義で決められない項目は、未定義事項として設計時に定義するこ
とも実施した。決まっていないことが明らかになることが重要である。
 非機能要求グレードのレベル算出の工数
初期は4、5回ほど打合せをする必要があった。その後も適宜打合せを実施。
 利用効果
知識体系としてみると、広く網羅的に漏れなく非機能項目を含むという
ことがメリットとなっている。
顧客より、「グレード表」を使用し最初から示してもらえるので助かる
と言われた。網羅性は安心感をもたらす。
本システムの次期開発でも一度整理した同じ形式で合意が出来た為、効
率が良かった。
全体のギャップを埋めることに使用したので、内容が覆えることが減っ
た。
公的な機関から提供されたこのような基準は顧客に説明し易い。
トータルなコスト削減効果については把握できていない。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 10
事例３．非機能要求定義のリファレンス利用（3/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 非機能要求に対する留意点
性能や可用性などの導入時の基盤設計については、官庁の調達仕様で定
められているので、「非機能要求」は運用設計を主眼とした。
 非機能要求グレード利用時の注意事項
セキュリティは官庁の統一基準※があるので、そちらをメインに実施す
る必要があった。今後非機能要求グレードからその基準が導出できること
を期待。
※「政府機関の情報セキュリティ対策のための統一基準」
http://www.nisc.go.jp/active/general/kijun01.html
システム基盤（インフラ）担当者とアプリ開発担当者が性能に関して一
緒に検討する必要がある（責任分担が難しかった）。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 11
事例４．非機能要求定義のチェックに利用（1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
試験支援システムの開発にあたって、顧客からの要望があり、非機能要求
グレード表にて最終的な非機能要件の調整を行った。
 システム概要
試験問題作成および試験実施システム
 利用工程、利用シーン
要件定義の最終工程
 利用目的
要件の抜け洩れの確認に活用
 利用方法
 非機能要件定義の結果に対して、重要項目を対象とした抜け洩れとい
う観点での確認に活用した。
 自社の項目をまずマップし、抜けている項目は、基本的に「社会的影
響が限定されているシステム」としてレベル設定を行った。
 非機能要求グレードのレベル算出の工数
ユーザとの検討を5日程度実施した。社内検討にも同程度の時間を掛け
た。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 12
事例４．非機能要求定義のチェックに利用（2/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用効果
 漏れを極力防止できるという意味で安心して使用できる。顧客と網羅性につ
いて詰める際に、うまく活用できた。
 重要項目とそれ以外をわけているところが便利であった。
 公的機関が提供していることで、非機能要求の物差しとして非常に役立つ。
 非機能要求に対する留意点
顧客は性能面を最も重視しており、その次が稼働率であった。
 非機能要求グレード利用時の注意事項
 非機能要件定義を後追いで実施したので、コスト面でのトレードオフがでて
しまうことがあった。
 性能はインフラとアプリで決まるため、インフラだけの設定は困難なところ
があった。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 13
事例５．社内システム開発標準への適用(1/4)SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
NTTデータ様では、社内のシステム開発標準に取込んで活用している。苦慮し
ていたシステム基盤設計のインプットの吸い上げや、属人的となっていたシス
テム基盤設計の導出を解決した。
 業種、業務
SIer、コンサル業務
 システム概要
省略（個別システムではない）
 利用工程、利用シーン
企画、システム要件定義、システムアーキテクチャ設計
 利用目的
社内標準TERASOLUNA®への反映。中でも基本構想立案、システム要件定義、
システムアーキテクチャ概要設計の成果物様式に取り込んだ。
また、各設計書のレビュー観点、テストケース抽出観点の整理軸として利用。
※TERASOLUNAは、ネーミング、ロゴタイプ、ロゴマーク合わせて
(株)NTTデータの登録商標です。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 14
事例５．社内システム開発標準への適用(2/4)SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
 各工程でグレード表の次の箇所を活用した。
 企画段階：レベル感
 要件定義(システム要件の整理)：企画段階で策定した内容の確認・精





査のためのレベル感
 要件定義(システムアーキテクチャ設計)：項目一覧のレベル
 レビュー観点/テストケース抽出：大項目、中項目に合わせ観点の分
類
社内共通用語として利用
非機能要求グレードの項目と、開発手順で定義している成果物の目次と
の対応を整理している。
現行システムのレベルと新システムのレベルを併記できるようにカスタ
マイズして、議論をしやすくした。
要件の確定状況を明記できるようにした。
要件定義の中で、二段階構成にして非機能要求を掘り下げた。要件定義
の冒頭で要件整理レベル感、その後システムアーキテクチャ検討の項目
一覧で、非機能要求の掘り下げと対応方針を策定する。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 15
事例５．社内システム開発標準への適用(3/4)SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用効果
 イントラネットに公開した、新社内標準TERASOLUNA®の平成21
年度と平成22年度のダウンロードは合計約1,000件。
 測定のための項目として使用できるものであり、良い物差しであ
ると認識している。
 コスト低減にも貢献できることがあると考えている。
 翻訳版を用意し、海外子会社での活用も考えている。
 非機能要求に対する留意点
移行データ量、移行データ方式なども意識する必要がある。
 非機能要求グレード利用時の注意
 非機能要求と実現方式（アーキテクチャ）の紐付け（要件追跡
性）がわからないこと。
外字・文字コードの非機能要求がない。
ユーザ企業内での知名度は十分でない。
各社でのカスタマイズなどをIPAにフィードバックする仕組みが
現在のところない。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 16
事例５．社内システム開発標準への適用(4/4)SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
旧版の
TERASOLUNAⓇ
新版の
TERASOLUNAⓇ
非機能要求
グレード
基本構想立案、システム要件定義、
システムアーキテクチャ概要設計の
成果物様式に取り込む
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 17
事例６．組込システムのソフトウェア
アーキテクチャ策定に利用（1/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
オムロン株式会社殿では、鉄道事業者向けシステムの券売機などの端末機
器のソフトウェアアーキテクチャ策定に非機能要求グレードを活用した。
券売機などの組込みソフトウェアにも非機能要求の適用が可能であり、か
つ効果をもたらすことを示した。
 業種、業務
製造業（組込みシステム開発業務）
 システム概要
鉄道事業者向けシステム（券売機などの端末機器）
 利用工程、利用シーン
システム要件定義、アーキテクチャ設計
 利用目的
顧客とコミュニケーションをとりながら非機能要求の重要性を確認しつつ
設定し、かつソフトウェアアーキテクチャを策定する。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 18
事例６．組込システムのソフトウェア
アーキテクチャ策定に利用（2/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
非機能要求グレード活用シートをもとに、券売機などの端末機器にそれぞれ
のモデルシステムのレベル感を適用する。非機能要求グレードの各項目に対
して券売機のシステム特性を当てはめた。組込みシステムに合致しない部分
は調整した。
項目一覧表に明示されている他の規格との関係性を活用し、ソフトウェアア
ーキテクチャの策定を実施した。
システム環境・エコロジーの大項目には、券売機などの端末機器特有の項目
を追加した。
非機能要求グレード表をもとに、組込み特有の項目を追加し当該システムへ
の非機能要求を設定した。
非機能要求グレードで使っている一般的な用語を、社内の組織名や製品名と
いった固有名詞に置き換えることで、社内設計者の視認性を良くした。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 19
事例６．組込システムのソフトウェア
アーキテクチャ策定に利用（3/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用効果
技術者は、非機能要求について認識していても、表現力に乏しいことが多く
、一覧表に掲載されている説明が役に立った。
非機能要求に関する社内認識の共通化に大きな効果があった。
運用・保守性で取り上げられている項目を券売機などの端末機器のソフトウ
ェアに適用したことで、保守に関する要件を数値で定義でき、運用フェーズ
において配置すべきサポート要員数を考える指針になった。
券売機などの端末機器だけでなく、駅務システムも非機能要求グレードを使
って検討したのは、組込みシステム開発者にとって、組込み系でないPCの非
機能要求の勉強となった。
 非機能要求に対する留意点
非機能要求に関しての共通認識を、社内のマネジメント層や顧客の鉄道事業者
から、更に鉄道事業者間、システムベンダ間で持つことが重要と考えられる。
 非機能要求グレード利用時の注意
他のセキュリティ基準との整合性が十分とは言えない。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 20
事例７．社内開発標準の統合事例(1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
企業合併時には、システム開発標準として共通の物差しを必要とする。各社
古いものを引きずっている状況下で、非機能要求グレードに注目し、基盤系
のサービスレベルを揃えた標準策定に活用した。
 業種、業務
金融業
 利用工程、利用シーン
開発標準の策定
 利用目的
開発標準化。企業合併時に各社各様であったシステムの可視性を向上するた
めの共通の物差しとして活用。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 21
事例７．社内開発標準の統合事例（2/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
標準策定に向けてグレード表をもとに、非機能要求項目の解説作成向け
にカスタマイズした上で、必須項目を選別した。
検討主体者欄を設け、システムや営業、基盤のサービスレベルの違いを
確認した。
モデルシステムシートの大項目を、レベル感や認識の違いを探るために
使った。内部調整を行い、ベンダ見積を取得した。金額を下げるとサービ
スレベルが変化することがわかった。
 利用効果
ストレスがなく、無駄がない。ただし人を見ながら使うことは必要。
自分がわかる（関わる）ところをピンポイントで見るときに、整理され
ているので便利である。
 非機能要求グレード利用時の注意
エコロジーのところで、端末数が要求としてでてくる等、改善点がまだ残
っている。
Copyright © 2011 IPA, All Rights Reserved
Software Engineering Center 22

Download Report