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

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

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

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

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

1.非機能要件定義の目的
2.非機能要件で押さえるべき6つの観点
3.参考動画
4.非機能要件定義のまとめ

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、ネットワーク転送等の応答時間やスループットについて判断する監視。