システムをユーザーに利用してもらう際、処理やデータの受け渡し等が正しく行われているかは安全性・信頼性の観点からも重要な要素です。
しかし、システムを利用するだけでは見えにくいセキュリティや、運用・保守性が高いことも、システムを支える重要な土台となってきます。
今回は、非機能要求グレードについて、意味や重要性をご紹介します。
非機能要求グレードとは？
非機能要求グレードとは、ユーザーと開発側の認識の齟齬を防止するために、非機能要件の項目をリストアップ・分類して、それぞれの項目の要求レベルを示したものです。
非機能要件とは、システムを運用する際に決めておくべき副次的な内容のことを指します。
例えば、部品の在庫状況を簡単に調べることが出来る検索システムを作って欲しいという要望がクライアントから出て、そのシステムの開発を進めていくとします。
クライアントからの要望としては、「部品の在庫状況を検索したい」になるのですが、この検索するという処理の中には、検討・考慮しなければならない点が多々あります。
クライアントからすれば、部品の検索に数十秒も掛かってしまうようなシステムや、複数人で同時にシステムにアクセスするとエラーになり使えなくなってしまうシステムは利用したくありません。
ユーザビリティに欠けるシステムは、リリース当初は使ってもらえても徐々に利用されなくなっていきますし、また業務上必ず利用しなければならないシステムの場合は、クレームの原因にもなってしまいます。
また、想定外の不具合が起こった場合の挙動についても、適切な対策を講じていなければ業務に支障が出かねません。
「検索処理に掛かる時間は5秒以内にしてほしい」「同時アクセス数が多くても、ダウンしないシステムを作って欲しい」等の要求、そして想定外の不具合が起こった場合の対策は、必ずしもクライアントと直接的に話し合って決めるわけではありませんが、システムを安心・安全に利用してもらうために、開発側ではこれらを想定してシステム開発を行う必要があります。
このような、システムの機能面以外で必要となってくるものが非機能要件であり、非機能要件をまとめてレベル分けしたものが非機能要求グレードになります。
非機能要求グレードの分類
非機能要求グレードは、大きく6つの要素に分類出来ます。
可用性
可用性は、システムがどれだけ継続して稼働し続けることが出来るかを指す項目です。
システムは常に稼働し続ける訳ではありません。
重大なエラーが発生してシステムそのものがダウンしてしまう場合もあれば、システムを公開しているサーバーのメンテナンスのために一時的に停止させる場合もあります。
それらを許容した上で、システムを停止せざるを得ない障害や状況となっても、最低限の業務が行えるようにしたり、問題発生時にリカバリが早急に行えるようにすることで、影響を最小限に抑えることは出来ます。
可用性の要素では、対象のシステムがどの程度の稼働率を持つことが出来るのか、またどの程度であれば許容範囲なのかを検討します。
性能・拡張性
性能・拡張性は、システムのパフォーマンス、及びそのパフォーマンスを今後どれぐらい増強できるかを指す項目です。
性能の面では、システムの処理速度が実業務に支障がないレベルに達しているか、蓄積されたデータ量が多い時、少ない時で検索処理のパフォーマンスにはどれぐらいの差が出るのか等を検討していきます。
拡張性の面としては、実業務の作業量が増えてシステムを利用する頻度が高くなった場合、システムの処理速度は落とさないように改修することが出来るかを確認していきます。
運用・保守性
運用・保守性は、システムの運用及び保守のサービスに関する要求を指す項目です。
システムの運用保守を効率化するためのジョブ監視システムの導入や、データのバックアップの頻度・規模等を設定します。
また、エラー発生時のリカバリ対応や、サーバーメンテナンス等でシステムを一時停止せざるを得ない場合の計画停止時の対応についても検討していきます。
移行性
現在のシステムを、新しいシステムに移行する場合の要求を指す項目です。
移行期間はどれぐらい掛かるのか、移行方法、移行スケジュール、必要ならば移行中の代替システムの用意等、システムを長期間運用していく上で考慮しなければならない移行全般の作業に関しての目標を設定していきます。
システムの移行はマイグレーションとも言い、様々な種類があるため、移行するシステムに合ったマイグレーションを行う必要があります。
マイグレーションについては、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
セキュリティ
システムの安全性に関する項目です。
脆弱性による社内情報・顧客情報流出のセキュリティ事故を防ぐための機能制限やデータの暗号化等、システムを運用する上でのリスク及びその対策について検討していきます。
セキュリティについては、システム全体を精査し、様々な観点から検討する必要があります。
定期的に脆弱性診断を行うのも有効な手段です。
脆弱性診断については、こちらの記事でも詳しく紹介しているのでぜひご確認ください。
システム環境・エコロジー
システム運用時の設置環境であったり、システムを利用する人数やシステムの導入台数等の要求を指す項目です。
消費エネルギー量についても検討が必要で、利用しているサーバーがシステムの規模に合ったものか等、環境負荷を低減させる施策についても検討していきます。
機能要求と非機能要求の違いとは？
クライアント側が実装してほしいと考える機能や動きが機能要件、それ以外にシステムを運用するにあたって決めておくべき内容が非機能要件となります。
機能要件は主に、クライアント側とシステムについて打ち合わせる要件定義のフェーズで決めていきます。
要件定義で決められた機能要件をもとに、それぞれの機能に対して必要となってくる処理速度やセキュリティ等、開発側の観点だからこそ見えてくる観点が非機能要件です。
非機能要求は難しい？
非機能要求は業務に直結する要求ではなく、システムの品質そのものに関わるものが多いため、実態が見えないものが多いです。
また、クライアントが意識していない部分も多いため、定義漏れが発生する可能性もあります。
しかし、非機能要求グレードを活用すれば、システムを安心・安全に利用してもらうための非機能要求の全体像が掴めてくるかと思います。
非機能要求についてのイメージが湧かないエンジニアは、まずは非機能要求グレードの6つの要素について学習し、それぞれの観点を考慮した要件定義を行うことを心がけましょう。
【まとめ】非機能要求の難易度と重要性は高い
システムに実装する機能を万全の状態でユーザーへ利用してもらうためにも、非機能要求の重要性は高いです。
機能的には良いシステムでも、非機能要求が十分でなければ、ビジネス目的に対して良い成果をもたらしてくれるとは限りません。
セキュリティ面やユーザビリティ、システムの品質を上げるために様々な観点の非機能要求を満たす必要があります。
非機能要求は機能要求と比べて実態が見えないため、定義の難易度は高いです。また、実態が見えない分、定義漏れが発生する可能性もあります。
システムの品質向上のためには欠かせないため、非機能要求グレードによる6つの要素をもとに、開発したシステムに最適な非機能要求を定義していきましょう。
