非機能要求（要件）に関する取組みと『非機能要求グレード...

Information-technology Promotion Agency, Japan

SoftwareEngineeringCenter

Software Engineering CenterCopyright© 2010 Information-technology Promotion Agency, Japan. All rights reserved.

非機能要求（要件）に関する取組みと『非機能要求グレード』の展開

2010年10月28日

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

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

研究員柏木雅之

SECSoftware Engineeringfor Mo･No･Zu･Ku･Ri

1Software Engineering CenterCopyright © 2010 IPA, All Rights Reserved

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

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

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

0

5

10

15

20

25

30

35

40

45

502005.7

2005.8

2005.9

2005.1

0

2005.1

1

2005.1

2

2006.1

2006.2

2006.3

2006.4

2006.5

2006.6

2006.7

2006.8

2006.9

2006.1

0

2006.1

1

2006.1

2

2007.1

2007.2

2007.3

2007.4

2007.5

2007.6

2007.7

2007.8

2007.9

2007.1

0

2007.1

1

2007.1

2

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



非機能要求関連の諸活動

各種業界団体でも非機能要求に注目

JUASJUAS

JEITAJEITA

IPA/SECIPA/SEC

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

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

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

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

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

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

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

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

非機能要件とアーキテクチャの関係性分析と評価ガイド

非機能要求を正確に記述する方法をソフトウェアアーキテクチャとの関係性で提示

本日の説明



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

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

機能要求

機能要求（プロセス）

機能要求（データ）

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

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

セキュリティ

移行性

運用・保守性

性能・拡張性

可用性品質要求

運用・操作要求技術要求

その他要求

移行要求

付帯作業

その他

非機能要求

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

要求の分類

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



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

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

機能要求

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

営業情報をシステム上で

共有し把握したい。

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

を行いたい。

非機能要求

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

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

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

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

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

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


6Software Engineering Center

非機能要件定義の課題

多くの要件定義成果物において非機能要件記述が体系的に記述されていない。

要求定義成果物の中に散在することが大多数で、網羅性を欠く

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

そもそもどのような項目を記述すべきかが理解されていない

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

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

非機能要求記述のスコープが不明瞭

非機能要求記述がどの範囲で有効かが判断しにくい

※ここでは、要求と要件を同じ意味で用います。場合によっては、NFRと記述します



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

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

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

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

②利用ガイド（利用編）

①利用ガイド（解説編）

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

③グレード表

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

④項目一覧

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

⑤樹系図

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

⑥活用シート

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

利用ガイド

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

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

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

（利用編）（利用編）



非機能要求の分類

要求の分類

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

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

運用スケジュール

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

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

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

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

②性能・

拡張性

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

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

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

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

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

③運用・

保守性

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

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

問題発生時の対応レベル

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

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

マニュアルの整備

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

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

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

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

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

⑤セキュリティ

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

利用制限

不正アクセスの防止

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

不正の追跡、監視、検知

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

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

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

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

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

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

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

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



非機能要求項目の体系

大・中項目の全体像

継続性

耐障害性

災害対策

回復性

性能・拡張性

業務処理量

性能目標値

リソース拡張性

性能品質保証

通常運用

保守運用

障害時運用

運用環境

サポート体制

その他運用管理方針

移行性

移行時期

移行方式

移行対象（機器）

移行対象（データ）

移行計画

Ｗｅｂ対策

セキュリティ

ネットワーク対策

前提条件・制約条件

セキュリティリスク分析

セキュリティ診断

セキュリティリスク管理

アクセス・利用制限

データの秘匿

不正追跡・監視

マルウェア対策

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

システム制約／前提条件

システム特性

適合規格

機材設置環境条件

環境マネジメント

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

可用性運用保守性

中項目

中項目

中項目

中項目

多

少

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

合計合計236236のメトリクス（指標）のメトリクス（指標）



大分類ごとの体系化：樹系図

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

前

後

検討順序

後

重要な非機能要求項目



非機能要求グレードの使い方ユーザー視点から要求の実現レベルを見える化するため、段階的に詳細化しながら「早期に」「誤解なく」「漏らさずに」確認できるようにする。

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

②グレード表＋樹系図

③項目一覧＋樹系図

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

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

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

要求項目を決定

16メトリクス 92メトリクス 236メトリクス+76 +144



①モデルシステムの選択

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

※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時間無停止

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

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

A.1.1.3

○ ○

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

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

計画停止無し

○

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

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

可用性継続性

項番大項目中項目小項目

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

備考小項目説明

重複項目

重要項目

メトリクス(指標)

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

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

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

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

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

ス(指標)

レベル

0 1 2 3 4 5

A.1.1.1

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

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

運用時間（通常）

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




24時間無停止

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

低高

要求レベル要求項目



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

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

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

経営層

業務部門

情報システム

部門

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

システム要件定義

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

提案・見積

承認

承認

事業要件定義

業務要件定義

レビュー（要件定義書

・予算）

実行稟議

発注検討

モデル決定

利用利用利用

詳細化

作成

RFP



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

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

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

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

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

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

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

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

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

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

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

個別調整項目：

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

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

設定値を決めておく

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



非機能要求グレードの利用シーンの例

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

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

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

カスタマイズ

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



クラウドサービスと非機能要求グレード

業務アプリケーション

実行基盤

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

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

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

オンプレミス IaaS PaaS SaaS

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

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

ユーザビリティ等）

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

非機能要求

グレードの対象

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



クラウドサービスでも非機能要求が大切

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

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

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

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

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

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

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

利用者

非機能要求ＳＬＡ

クラウドサービス

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

クラウドサービス



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

社会・ＩＴ業界

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

利用者

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

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

開発者

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

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

その結果その結果



ご参考： IPA SECの関連活動非機能要件記述とＩＴシステムアーキテクチャ設計

学界産業界要求工学・設計開発技術研究部会→ 非機能要求とアーキテクチャWG

→ 非機能要件とｱｰｷﾃｸﾁｬWG大学

研究機関・研究団体

大学研究機関・研究団体

ITアーキテクトを中心とした現場技術者

ITアーキテクトを中心とした現場技術者

ベンダ系企業ベンダ系企業

ユーザ系企業ユーザ系企業

空白領域⇒IPA/SECの取組

非機能要求グレードWG

NFR記述：ユーザシナリオベース→ ビジネスリスク回避

NFRグレード表：網羅性が特徴 → 抜け洩れ防止

シナリオベースでNFRとITシステムのアーキテクチャの導出過程を検証⇒ 実践的にNFRとITシステムのアーキテクチャの関係性を分析⇒ 具体的なコンテキスト記述を伴ったNFR記述がアーキテクチャを決定

⇒ コントロールケース(*)を使ったNFR記述が有効

Copyright © 2010 IPA, All Rights Reserved

*:特定条件下のNFRインスタンスがどのようになるかをシステムの内部状況・外部状況に従った記述




NFR記述に関するプロセス・フロー

ビジネス・コンテキストの理解

ITシステムの

スコープ定義要求の抽出

と整理・仕様化アーキテクチャ

の検討実現可能性確認

と合意形成

ビジネスコンテキストビジネスユースケース

ビジネス戦略CSF, KGI, KPI

ITシステムの目的

とそのスコープ

ステークホルダー一覧

システムユースケース

システムコンテキスト

NFR（コントロールケース）

SituationOperation Mode

Operating Condition

アーキテクチャモデル要求定義書

ビジネスイベントビジネスルール

繰り返し

リスク候補一覧

ポリシー/ガイドライン、

制約の一覧

アーキテクチャ決定アーキテクチャ決定

アーキテクチャパターン候補とNFR得失関係表

アーキテクチャパターン候補とNFR得失関係表

××NFRとアーキテクチャの単純な得失関係表NFRの抽象的なテンプレート

⇒要求からアーキテクチャが導出できるとは言えず！



ご参考： IPA SECの関連活動非機能要件記述とITシステムアーキテクチャ設計

NFR記述に関するプロセス・フロー

ビジネス・コンテキストの理解

ITシステムの

スコープ定義要求の抽出

と整理・仕様化アーキテクチャ

の検討実現可能性確認

と合意形成

ビジネスコンテキストビジネスユースケース

ビジネス戦略CSF, KGI, KPI

ITシステムの目的

とそのスコープ

ステークホルダー一覧

システムユースケース

システムコンテキスト

NFR（コントロールケース）

SituationOperation Mode

Operating Condition

アーキテクチャモデル要求定義書

ビジネスイベントビジネスルール

繰り返し

リスク候補一覧

ポリシー/ガイドライン、

制約の一覧

アーキテクチャ決定!!

ビジネスコンテキストに合ったビジネスパターン候補の抽出

ビジネスコンテキストに合ったビジネスパターン候補の抽出

システムコンテキストに合ったアーキテクチャパターン候補の抽出

システムコンテキストに合ったアーキテクチャパターン候補の抽出

ゴール、リスクからすぐにアーキテクチャには落ちない

ＩＴアーキテクトはコンテキストを理解し、NFR決定フローと並行してアーキテクチャ候補を絞込

⇒アーキテクチャ決定可能な詳細なNFR記述を

ゴール、リスクからすぐにアーキテクチャには落ちない

ＩＴアーキテクトはコンテキストを理解し、NFR決定フローと並行してアーキテクチャ候補を絞込

⇒アーキテクチャ決定可能な詳細なNFR記述を

具体的なコンテキストNFRとアーキテクチャ

パターンの得失表

具体的なコンテキストNFRとアーキテクチャ

パターンの得失表




本成果を「非機能要求記述ガイド」の続編の

「非機能要件とアーキテクチャの関係分析と評価ガイド(仮)」をWeb公開予定

企画プロセスシステム化構想の立案システム化計画の立案

要件定義プロセス要件定義（ビジネス/業務）

開発プロセスシステム要件定義システム方式設計

保守プロセス保守

運用プロセスシステム運用

・企画書のNFRとアーキテクチャ

・RFPのNFRとアーキテクチャ・提案書のNFRとアーキテクチャ

・基本設計書のNFRとアーキテクチャ

開発プロセスシステム結合テストシステム適格性テスト

・テスト計画書・テスト仕様書のNFRとアーキテクチャ

・システム運用計画書,運用仕様書のNFRとアーキテクチャ

・保守・改修計画書、保守・改修仕様書のNFRとアーキテクチャ

非機能要件記述アーキテクチャとの関係分析・評価



IPA SECでの今後の取り組み

非機能要求グレードをより多く使ってもらうために、セミナーや啓発用小冊子の作成などの普及・推進活動を行っていきます。

非機能要求グレードのメトリクスを国際標準化する活動に取り組みます。

その一環として、英語版を近日中に公開します。

現状のシステム基盤に対する非機能要求グレードを、業務アプリケーションの非機能要求（利用性など）にも広げることを検討します。

非機能要求も含む、要求からITシステムのアーキテクチャまでのトレーサビリティ分析に関わる活動も検討しています。

非機能要求（要件）に関する取組みと 『非機能要求グレード...

Documents

非機能要求（要件）に関する取組みと『非機能要求グレード...