非機能要件定義で押さえるべき6つの観点について(サンプルあり)

非機能要件定義で押さえるべき6つの観点について

こんにちは!わさおです!

非機能要件定義はシステムの品質を高め、使いやすいシステムにするために必ず行うべきです。

ユーザーは機能面ばかりに目が行きがちになりますが、非機能要件をおろそかにすると使い勝手の悪いシステムが出来上がってしまうかもしれません。

ここでは非機能要件定義について解説したいと思います。

学習と実践でスキルアップしよう(お得に).   対象コースが¥1800から

1.非機能要件定義の目的

そもそも非機能要件定義とは、システム要件のうち機能面以外の要件を明確にすることです。

要件定義というと機能面ばかりが注目されがちなのですが、「システム稼働時間」や「システム利用者数」のような非機能面も考慮しないと、業務に耐えないシステムになる可能性があります。

非機能要件定義が行われず業務実態に合っていないシステムだと、ユーザーに制限を強いることになります。すると、システムに対する満足度が下がり、いずれは利用されなくなるでしょう。

非機能要件定義はそのような事態を防ぐために行います。つまり、非機能要件定義の目的は、ユーザーの満足度を高めるためと言えるでしょう。

2.非機能要件で押さえるべき6つの観点

非機能要件定義はIPA(情報処理推進機構)が提唱している「システム構築の上流工程強化(非機能要求グレード)」が提唱している下記6つの観点で行いましょう。

なお、非機能要求グレード2018はこちらからダウンロードできますので、非機能要件定義を行う際の参考にしていただければと思います。

①可用性

②性能・拡張性

③運用・保守性

④移行性

⑤セキュリティ

⑥システム環境

①可用性(Availability)

可用性とは、システムが継続して稼働できる能力のことです。
具体的な指標としては、「運用スケジュール」「目標復旧水準」「稼働率」などが挙げられます。

運用スケジュール

システムの稼働時間や停止運用に関する情報(計画停止の有無など)を定義します。

業務継続性

可用性を保証するにあたり、要求される対象業務の範囲やその条件を定義します。

システム障害が起こった際のサービス切替時間や業務停止の許容度なども検討します。

目標復旧水準(通常時・大規模災害時)

通常時や大規模災害時において、業務停止を伴う障害が発生した際、何をどれ位で復旧ささるかの目標を定義します。

稼動率

明示された利用条件の下で、システムが要求されたサービスを提供できる割合を表します。

なお、非機能要求グレード2018の稼働率の水準は以下の通りです。
 ・稼働率95%以下:レベル0(最も低い水準)
 ・稼働率99.999%:レベル5(最も高い水準)

耐障害性

サーバ、端末、ネットワーク機器、ネットワーク、ストレージにおける耐障害性(冗長性)を定義します。

また、データ保護に対しての考え方(バックアップ方式・データ復旧範囲)なども定義します。

災害対策

災害時の業務継続性を満たすための要求を定義します。復旧方針やデータ・システムの保管場所などを検討します。

復旧作業

業務停止を伴う障害が発生した際の復旧作業に必要な労力を定義します。

②性能・拡張性(Performance・Extensibility)

性能・拡張性とは、システム性能・機能追加/向上などを表します。
具体的な指標としては、「通常時の業務量」「業務量増大度」「システム起動時間」などが挙げられます。

通常時の業務量

性能・拡張性に影響を与える業務量を定義します。ユーザ数、同時アクセス数、データ量、オンラインリクエスト件数、バッチ処理件数などを検討します。

業務量増大度

システム稼働開始からライフサイクル終了までの間で、開始時点と業務量が最大になる時点の業務量の倍率。必要に応じ、開始日の平均値や、開始後の定常状態との比較を行う場合もある。

保管期間

システムが参照するデータのうち、OSやミドルウェアのログなどのシステム基盤が利用するデータに対する保管が必要な期間。必要に応じて、データの種別毎に定める。

レスポンスタイム

オンラインシステムやバッチシステム利用時に要求されるレスポンス。通常時、ピーク時、縮退時のレスポンス順守率を定める。

スループット

オンラインシステムやバッチシステム、帳票印刷の利用時に要求されるスループット。対象業務の特性を踏まえ、単位時間にどれだけの量の作業ができるかを確認する。

こちらもレスポンスタイムと同様、通常時、ピーク時、縮退時の処理余裕率を定める。

リソース拡張性

CPU、メモリ、ディスク、ネットワーク環境などの拡張性を定める。それぞれの利用率や拡張性を定義する。

サーバ処理能力増強

将来の業務量増大に備える方法をあらかじめ考慮する。増強方法としては以下の方法が挙げられる。

スケールアップ:より処理能力の大きなサーバと入れ替えを行う
スケールアウト:同等のサーバを複数台用意し、サーバ台数を増やすことで処理能力の増強を行う

性能品質保証

システム性能品質に関する項目を定義する。具体的には、ネットワーク帯域保証機能の有無、HWリソース専有の有無などを検討する。

また、性能テストなどを実施する場合、測定頻度や確認範囲を定めておく。

③運用・保守性(Operation・Maintainability)

システム納品後の運用や保守について定義します。

運用時間

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

バックアップ

システムが利用するデータのバックアップに関する項目。データ復旧範囲、外部データの利用可否、バックアップ利用範囲、バックアップ自動化の範囲、バックアップ取得間隔、バックアップ保存期間、バックアップ方式などを定義する。

運用監視

システム全体、あるいはそれを構成するハードウェア・ソフトウェアに対する監視に関する項目。監視情報、監視間隔、監視レベルなどを定める。

なお、非機能要求グレード2018における監視情報のレベルは以下の通り。

 ・レベル1(死活監視):対象のステータスがオンラインがオフラインかを判断する監視。
 ・レベル2(エラー監視):対象が出力するログ等にエラー出力が含まれているかどうかを判断する監視。
 ・レベル3(エラー監視[トレース情報含む]):トレース情報を含む場合は、どのモジュールでエラーが発生しているのか詳細についても判断することができる。
 ・レベル4(リソース監視):対象が出力するログやパフォーマンス情報に基づいて、CPUやメモリ、ディスク、ネットワーク帯域といったリソースの使用状況を判断する監視。 
・レベル5(パフォーマンス監視):対象が出力するログやパフォーマンス情報に基づいて、業務アプリケーションやディスクI/O、ネットワーク転送等の応答時間やスループットについて判断する監視。

時刻同期

システムを構成する機器の時刻同期に関して定義する。

計画停止

点検作業や領域拡張、デフラグ、マスターデータのメンテナンス等、システムの保守作業の実施を目的とした事前計画済みのサービス停止に関する項目。

運用負荷削減

保守運用に関する作業負荷を削減するための設計に関する項目。保守作業、サーバソフトウェア更新、端末ソフトウェア更新の自動化などを検討する。

運用環境

開発環境や試験環境の設置や運用マニュアルの準備について検討する。また、リモートオペレーションの可否も定義する。

サポート体制

保守契約やライフサイクル期間の定義を行う。

内部統制対応

IT運用プロセスの内部統制対応を行うかどうかに関する項目。

サービスデスク

ユーザの問合せに対して単一の窓口機能を提供するかどうかに関する項目。

④移行性(Migratability)

業務移行やシステム移行に関する項目を定義します。

移行のスケジュール

移行作業計画から本稼働までのシステム移行期間、システム停止可能日時、並行稼働の有無。(例外発生時の切り戻し時間や事前バックアップの時間等も含むこと。)

システム展開方式

システムの移行および新規展開時に多段階による展開方式をどの程度採用するかの程度。

移行設備

移行前のシステムで使用していた設備において、新システムで新たな設備に入れ替え対象となる移行対象設備の内容。

移行データ量

旧システム上で移行の必要がある業務データの量やデータ形式を定義する。

⑤セキュリティ(Security)

セキュリティに関する項目を定義します。

情報セキュリティに関するコンプライアンス

順守すべき情報セキュリティに関する組織規程やルール、法令、ガイドライン等が存在するかどうかを確認するための項目。

セキュリティリスク分析

システム開発を実施する中で、どの範囲で対象システムの脅威を洗い出し、影響の分析を実施するのかの方針を確認するための項目。また、洗い出した脅威に対して、対策する範囲を検討する。

セキュリティ診断

対象システムや各種ドキュメントに対して、セキュリティに特化した各種試験や検査の実施の有無を確認するための項目。

認証機能

資産を利用する主体(利用者や機器等)を識別するための認証を実施するか、また、どの程度実施するのかを確認するための項目。複数回の認証を実施することにより、抑止効果を高めることができる。

利用制限

認証された主体(利用者や機器など)に対して、資産の利用等を、ソフトウェアやハードウェアにより制限するか確認するための項目。

データ暗号化

機密性のあるデータを、伝送時や蓄積時に秘匿するための暗号化を実施するかを確認するための項目。

不正監視

不正行為を検知するために、それらの不正について監視する範囲や、監視の記録を保存する量や期間を確認するための項目。

ネットワーク対策

ネットワーク制御、不正検知、サービス停止攻撃の回避などに関する項目を定義する。

マルウェア対策

マルウェア(ウィルス、ワーム、ボット等)の感染を防止する。マルウェア対策の実施範囲やチェックタイミングを確認するための項目。

Web実装対策

Webアプリケーション特有の脅威、脆弱性に関する対策を実施するかを確認するための項目。

⑥システム環境(System environment)

構築時・運用時の制約条件

構築時や運用時の制約となる社内基準や法令、各地方自治体の条例などの制約が存在しているかの項目。

システム特性

ユーザ数、クライアント数、拠点数、地域的広がり、特定製品の採用有無などを定義する。

適合規格

提供するシステムに使用する製品について、製品安全規格(UL60950など)や特定有害物質の使用制限についての規格(RoHS指令など)の取得を要求されているかを確認する項目。

耐震/免震

地震発生時にシステム設置環境で耐える必要のある実効的な最大震度を規定する。

スペース

どの程度の床面積・高さが必要かの項目。保守作業用スペースについても考慮する。

【まとめ】非機能要件定義について

非機能要件はユーザーの満足度を高めるために必ず行いましょう。
この記事の項目で非機能要件はほぼ網羅できますので、是非参考にしていただければと思います。

学習と実践でスキルアップしよう(お得に).   対象コースが¥1800から

↓↓このブログが少しでもお役に立ったならば、応援クリック頂けると嬉しいです!↓↓

ブログランキング・にほんブログ村へ