SH29_999_非機能要件定義書

※経済産業省委託事業「平成29年度新エネルギー等の保安規制高度化事業（監督部電子申請システム構築に向けた検討業務）」においてアクセンチュア株式会社が作成した原案をもとに、経済産業省にて作成

0. 非機能要件項目電子申請システム（以下、「本システム」）の非機能要件にて定める項目は以下の通り。

1

定義概要

• 情報システムを利用するユーザの組織、役割・作業、作業時間帯等• 使いやすさについて検討を要する業務や画面等• クライアントとして想定する機器の分類、使用者、設置場所等• システムの理解性、習得性、操作性等• 特定ユーザの年齢や身体的制約への対応等• システム化対象業務において発生する単位時間当たりの処理件数等• ユーザの分類定義および各ユーザ分類におけるアクセス数等• システムで取り扱うデータ量等• 機能やデータ量増加に伴う対応等• オンラインレスポンス時間とその対象処理等• バッジ処理の指標及びその対象等• システムの正常な動作を保つための対策及び目標値等• 外的要因によるシステム停止リスク及び再稼働条件・目標値等• 不正アクセス等によるデータ改ざん・破壊・紛失への対策等• ＯＳ及びミドルウェア等のバージョンアップへの対応等• ベンダーロックイン解消や透明性向上に係る対応等

要件種別

1.ユーザビリティ・アクセシビリティ

2.規模・拡張性

3.性能

4.信頼性

1.1 ユーザ定義1.2 使いやすさを求められる業務・処理1.3 クライアント機器1.4 ユーザビリティ要件1.5 アクセシビリティ要件2.1 業務処理量2.2 利用数とアクセス数及びアクセス方式2.3 データ量2.4 拡張性要件3.1 オンライン処理の性能3.2 バッジ処理の性能4.1 可用性要件4.2 継続性要件4.3 完全性要件

5.上位互換性6.システム中立性7.移行性 • 業務及びデータの移行に係る対応等

2

1. ユーザビリティ・アクセシビリティ本システムにおけるユーザビリティ・アクセシビリティを以下に定義する。

ユーザビリティ・アクセシビリティ

要件種別 要件

使いやすさを求められる業務・処理

• 本システムについて、ユーザビリティ要件、アクセシビリティ要件を特に考慮すべき業務・処理を以下に記す。

【特に使いやすさを求められる業務・処理】基礎情報入力画面、添付書類アップロード画面、入力内容確認・確定画面、問い合わせ対応画面【使いやすさを求められる業務・処理】届出・申請内容確認画面、問合せ登録画面、決裁画面

ユーザ定義

【組織】 経済産業省 本省 産業保安グループ、資源エネルギー庁、産業保安監督部、経済経産局産業部 製品安全室【ユーザ】 上記組織の職員【役割・作業】 全国の申請者及び代行申請者から提出された届出・申請の受理・承認及び閲覧を行う。【人数】 約400名【作業時間】 24時間 365日【情報リテラシ】 パソコン上で基礎的なExcel操作等をほぼ問題なく完遂できるが、データベースの操作まではできない。【特記事項】なし【組織】 なし【ユーザ】 申請者及び代行申請者（一般ユーザ）【役割・作業】 本システムを利用し、産業保安に係る各種手続きを実施する。【人数】 約365,000名（2020年時点で想定される総ユーザ数）【作業時間】 24時間 365日【情報リテラシ】 パソコン上でマクロを含むExcel操作等を問題なく完遂できるユーザから、パソコンを持たないユーザまで多様。【特記事項】 なし

本省・監督部等

申請者・代行申請者

3

1. ユーザビリティ・アクセシビリティ本システムにおけるユーザビリティ・アクセシビリティを以下に定義する。

ユーザビリティ・アクセシビリティ

要件種別 要件

クライアント機器

アクセシビリティ要件

ユーザビリティ要件

• 利用者が想定する流れに沿った手順(画面遷移・タブの移動順等)にすること• ユーザが必要な操作を想起しやすい画面構成とすること• 出来る限り、最小限の操作、入力で届出・申請等ができるような画面構成とすること• 操作の指示や説明、メニュー等には、利用者が正しく理解できる用語を使用すること• 基本的な用語、指示、デザインには一貫性を持たせること• 必要に応じて確認画面を用意し、入力の取り消し・やり直しができるようにすること• エラーが発生した時には、ユーザが何をすべきかをメッセージ等で指示すると共に、エラーコード等、問題解決に資する情報を表示すること

• ユーザが必要とする時に、ヘルプやマニュアル等を利用できるようにすること• ユーザから収集した意見を可能な限りユーザビリティに反映すること

• ユーザには60歳以上の高齢者が一定の割合で存在することを考慮すること• 申請者や一部の監督部等が使用する環境のネットワーク回線が脆弱である場合があることを考慮すること

【機器の分類】 パソコン、タブレット【機器の用途】 届出・申請及び各種情報参照、並びに各種設定及びアカウント紐付等【設置場所】 不定

本省・監督部等

申請者・代行申請者

【機器の分類】 パソコン、タブレット、スマートフォン【機器の用途】 届出・申請情報の確認及び各種情報参照・集計並びに各種設定等【設置場所】 不定

4

2. 規模・拡張性本システムに要求される規模・拡張性については、以下の項目について整理する。

要件種別 要件

規模・拡張性

業務処理量

＜導入後5年目時点の業務処理量想定＞・届出・申請数（全手続）- 25,000件/1ヶ月(定常時)、40,000件/1ヶ月(ピーク時)・ページビュー数（申請者・代行申請者及び本省・監督部等における総閲覧数）- 225,000件/1ヶ月(定常時)、351,000件/1ヶ月(ピーク時)※ 4月のピーク時に年間届出総数の13％が提出される前提で算出※ 届出・申請数は2017年時点で約26万件だが、今後毎年1万件程度純増していく前提で算出

利用者数とアクセス数及びアクセス方式 ＜導入後5年目時点の業務処理量想定＞

【利用者】 一般ユーザ【利用者数】 約365,000名【同時アクセス数(最大値)】 1,000【利用時間帯】365日24時間【アクセス方式】 インターネット※法人共通認証基盤とのシングルサインオンによる認証が可能なこと※ピーク時の1日の手続の50％が同時にアクセスされる想定で試算

本省・監督部等

申請者・代行申請者

＜導入後5年目時点の業務処理量想定＞【利用者】 本省、監督部、及び経産局ユーザ【利用者数】 約400名【同時アクセス数(最大値)】 400【利用時間帯】 365日24時間【アクセス方式】 インターネット及び省内イントラネット

5

2. 規模・拡張性本システムに要求される規模・拡張性については、以下の項目について整理する。

要件種別要件

規模・拡張性

データ名称 データ種類 データ量2023年3月末2019年3月末 備考

データ量

届出・申請情報（データ項目数） トランザクション 41,307,000

• 発生頻度：随時• 1申請あたり50項目のデータがあるものとして算出

• 過去データ移行分を含む

アカウント情報（データ項目数） マスタ 232,000

• 発生頻度：随時• 1アカウントに10項目のマスタデータがあるものとして算出

149,500,000

送信メール（送信件数）

問い合わせログ（データ項目数）

その他

ログ

259,500

13,000

• 発生頻度：随時• 1申請あたり2通の送信メールが発生するものとして算出

• 発生頻度：随時• 総申請件数の10％に問い合わせが発生するものとして算出

2,500,000

125,000

3,654,000

データ保有期間 • データ保有期間は原則60ヶ月とすること※但し、法令・手続によって保持期間・対象は異なる場合が発生することとする

6

2. 規模・拡張性本システムに要求される規模・拡張性については、以下の項目について整理する。

規模・拡張性 拡張性要件

本システムの対象となる業務処理量、ユーザ数・アクセス数、データ量は、いずれも導入後増加することが予測されることから、可能な限りコストと時間を抑える中、円滑且つ安全に行われる為、以下を拡張性要件として定義する。

• 業務処理量、ユーザ数・アクセス数、データ量が増加してもクラウドのスケールアウト又はスケールアップにより対応できること

• サーバー負荷軽減の為、分散処理可能な構成であること• 2020年度以降の電子化対象手続の追加、省内外の接続先システムとのインターフェース、バッチ処理の追加、及びユーザ種別の追加に対応できること

• 2019年度までに開発される対象機能の改修や、追加機能の開発に対応できること• Internet Explorer, Google Chrome, Fire Fox, Edge, Safari等、主要なブラウザがアップグレードされた際も使用可能であること

要件種別 要件

7

3. 性能本システムに要求される性能について、以下に示す。

性能

オンライン処理の性能

バッチ処理の性能

•応答時間について、基本的なリクエスト（20項目・100文字程度）に対し3秒を基本の目標時間とすること※オンラインレスポンス値は、利用者のネットワーク帯域の影響を受けるため、サーバのアプリケーション処理時間及び本省内のネットワーク時間とすること

※レスポンスタイムに外部システム連携処理は含まないものとすること※他の業務に影響しない範囲で省内ネットワークにてオンラインレスポンスの目標値が達成できるか検証すること※目標値の達成率は90％とすること

•システムの応答時間については、利用者にストレスを感じさせない十分なレスポンスを確保すること

【想定されるバッチ】マスタ更新【指標名】マスタ更新が終了するまでの時間【指標】業務に極力支障の出ない時間帯、且つ日次で処理を完了すること【達成率】100％※要件定義の段階ではバッチ処理の定義が未確定のため、今後新たに定義されるバッチ処理についても対応可能なこと

要件種別 要件

8

4. 信頼性本システムに要求される信頼性について、以下に示す。

要件種別 要件

信頼性

可用性要件

継続性要件

【想定するリスク】• 地震、火災、風水害等、攻撃等による直接的なセンタ設備及びシステムの損壊• センタ周辺のライフライン（電力、通信、交通等）の機能不全による情報システムの長時間停止• 新型インフルエンザウイルスによるパンデミック、及び人員や交通機関の被災等によるセンタの運用者不在【事業再開の定義】• システム運用をメインセンタからバックアップセンタへ切替え、システム資源及び要員体制の範囲内での縮退運用により業務を継続できること

• 冗長化構造やホットスタンバイ状態の予備機の提供等の対策を講じることで、大規模障害発生時もサービスを継続できること

【目標値】• 目標復旧地点：4時間• 目標復旧時間：12時間※経済産業省職員においては早期の事業再開が必要であり、その目標値については当省と協議の上決定すること

• 365日24時間の運用を目標とすること• 計画的システム停止期間を除く、99.5％の稼働率を目標値とすること• 通常時の負荷分散及び障害発生時の縮退運転を可能とすること• 障害発生時にも業務が継続できるよう待機系への切替えを可能とすること• 障害時のデータ消失対策として、サーバ上のデータベースファイルは、冗長構成をとるものとすること• 業務に用いるデータのバックアップ処理は業務への影響を排除した設計とすること• 異常な入力や処理を検出しデータの滅失や改変を防止する対策を講ずること• 処理の結果を検証可能とする為、ログ等の証跡を残すこと• 標準メンテナンスは、開始から5日前までに連絡すること

9

4. 信頼性本システムに要求される信頼性について、以下に示す。

要件種別 要件

信頼性 完全性要件

【完全性実現施策】• 30日分のアプリケーションログをいつでも閲覧可能とし、30日以前のログも請求・取得可能とすること• 自動でデータベースファイルのバックアップを取得し、必要に応じ手動バックアップも可能であること

【リスク低減施策】• プロバイダー提供による暗号化にてデータ保護が行われていること• ノード、リソース(CPU・メモリ・ディスク)、プロセス、ジョブ、データベースの監視を実施すること• 不正な通信を遮断する対策を講じることができること• 不正アクセスが無いか、攻撃検知・不正検知・防止ができること• マルウェアやDos攻撃に代表される、外部からの攻撃に対する対策が講じられていること• アプリケーション特有の脅威、脆弱性について対策すること• 権限設定により機能やデータに対する認可を制御できること• メジャーなブラウザの新しいバージョンが公開された際はテストを行うこと

5. 上位互換性本システムに要求される上位互換性について、以下に示す。

10

上位互換性

• クライアントOS のバージョンアップに備え、OS の特定バージョンに依存する機能が判明している場合は、その利用を最低限とすること

• Webブラウザ及び実行環境等のバージョンアップの際、必要な調査及び作業を実施することで、バージョンアップに対応可能な情報システムとすること

• 契約期間中にアプリケーション稼働環境として導入しているソフトウェアのバージョンアップが発生した場合は、原則、バージョンアップ後の環境を前提として開発を行うこと。なお、バージョンアップの決定時期によって対応が困難な場合には、経済産業省と協議の上、その指示に従うこと

• バージョンアップについて、技術的な問題等がある場合は、経済産業省と協議の上、その指示に従うこと

要件種別 要件

6. システム中立性

11

本システムに要求されるシステム中立性について、以下に示す。

システム中立性

【オープンな標準的技術又は製品に関する事項】• 提供するハードウェア、ソフトウェア等は、原則としてオープンなインタフェースを利用して接続又はデータの入出力が可能であること

• システム更改の際に、移行の妨げや特定の装置や情報システムに依存することを防止するため、原則として情報システム内のデータを標準的な形式で取り出すことができるものとすること

【他事業者への円滑な引き継ぎに関する事項】• 特定の事業者に依存することなく、他者による保守、追加開発が可能なシステム構成であること

要件種別 要件

7. 移行性

12

本システムに要求されるシステム移行性について、以下に示す。

移行性

要件種別 要件

• データ移行については、「（参考）データ移行に際して検討すべき事項」を参照

• 並行稼働するシステムとの連携を図りつつ移行を実施すること• Wave1～3で段階的に移行作業を実施すること• 移行計画書を作成すること

業務移行

データ移行

（参考）データ移行に際して検討すべき事項

13

移行対象とするデータの分類及び各分類の優先度をもとに、調達仕様書において対象手続を整理済。設計・開発・移行着手までに、移行データの特定や、移行方法の確定、移行計画の策定を完了させる必要がある。

データ移行において実施すべき作業の概略

①移行対象の選定

②移行方法の確定

③移行計画の策定

④移行作業の実施

移行対象とするデータを分類し、優先度付けを行う 現状のデータ保持状況を確認の上、移行すべきデータの

分類毎に対象項目、量、断面等を詳細化する

パッケージを前提とした場合の移行方法(移行ツールの種別、利用有無やパンチ入力の有無等）を選定する

移行方法に応じて、欠損データの補完や名寄せ等データクレンジングの要否等の対応範囲を確定する

移行用のツール、データフォーマットを作成し、データ整備する

整備された移行データを確認の上、テスト及び本番移行作業を実施する

移行データの検証方法や移行リハーサル、本番移行の実施要件、実施手順を整理する

移行作業に係る作業の役割分担・スケジュールを策定する

（参考）データ移行における難所

システムの利用価値向上に資するデータの見極め

• 予算制約や移行作業に係る手間を考慮した対象データの見極めが必要

パッケージ製品上の制約• カスタム開発時のように移行ツールを用いたデー

タの流し込みが実施できない場合もあり、パッケージ制約に応じた移行方式の確定が必要

開発や導入支援等の要件への影響• 移行に係る作業やスケジュールに応じて、開発

時の前提・スケジュールやユーザ研修等導入支援におけるドキュメント等への反映が必要

設計・開発・移行着手までに確定が必要

設計・開発と平行して実施