開発の非機能要件とは？

非機能要件とは、ハードウェア、OS、ミドルウェア、データベースのシステムの品質の要求があります。加えて、ユーザインタフェースの反応性や操作性、ソフトウェアの品質など「アプリケーション」に対する要求などをいいます。

非機能要件は、システムの拡張性などの要求を見えるかし、あるシステムの商談における発注側（ユーザ企業）と開発側（開発企業）で合意するための要件です。

システム開発の非機能要件が必要な理由

社会的に情報システムの品質に注目が集まっています。ニュースなどでソフトウェアに起因する不具合の報告を聞くことがあります。こういった不具合は非機能要件が起因していると言われています。

こういった不具合の改善には一般的に要件定義などの上流工程の改善が品質改善に効果的と言われています。

要件定義では、要求に関する部分で機能要件は、実現したい業務内容などで説明することが容易にできます。しかしながら、非機能要件は、反応を3秒以内にするなど時間に対する性能やセキュリティなど、システム自体が具現化しないと説明ができないことがあります。

機能要件との違い

機能要件は、プロセス、データ、インターフェイスなど、実現したい業務機能についての要求となります。発注側としても説明や紹介しやすい要件となります。

例えば、営業情報をシステム上で共有したい、在庫管理システムを複数拠点で共有できるようにしたいというという説明になります。実現したい機能について、利用者が自らの言葉で語ることができるようなものになります。

非機能要件は性能や運用やセキュリティの要求になります。実現したい非機能要求は発注側では説明しづらく、開発がある程度進まないとわからなかったり上流工程でそもそも定義されていないことがあります。

例えば、レスポンスは5秒以内にしてほしい、システムダウン時は3時間以内に復旧して欲しい、将来の処理量増大に備え、3倍の性能に拡張できるようにしてほしいなどになります。

そのため、非機能要件は業務とは直結せず技術的要素が強いという点から、要求項目がもれやすく発注者と開発者で共通の認識が難しいといえます。

非機能要件が構成される項目6つ

非機能要件を構成する要素はなんでしょうか。非機能要件が構成される項目を紹介します。項目は6つあり、「可用性」、「性能・拡張性」、「運用・保守性」、「移行性」、「セキュリティ」、「システム環境・エコロジー」です。

ここからは、6つの項目についてそれぞれ紹介していきます。

1：ITシステムの機能の使いやすさ

可用性としてITシステムの機能の使いやすさも観点の1つです。システムを継続的に利用可能とする要求です。運用スケジュールでは稼働時間、停止予定を提示したりします。実施する対策の例としては、機器の冗長化やバックアップセンタの設置が考えられます。

2：システム自体の性能・拡張性

性能・拡張性を示す項目で、システムの性能と今後のシステム拡張に対する要求となります。業務量の増加を見積をしたり、システムがピークの時の処理の傾向を検討します。実施する対策例は、性能目標を提示したりします。また、今後のシステム拡張の計画を行います。

3：システムの運用・保守性

システムの運用と保守に関する要求では、運用中に求められるシステムの稼働状況や、問題が発生した時の対応方法を検討します。

実施する対策例としては、監視手段やバックアップ方法を確立することや問題発生時の対応をマニュアル化、訓練することになります。

4：システムの移行の方法・計画トラブル対処

現行システム資産の移行の要求です。新システムへの移行方法や移行スケジュールを検討します。また合わせて移行する資産や移行する量を検討します。

実施する対策例は、移行スケジュールを計画することや移行する手法やツールを作成することです。また移行する際の体制の確立やリハーサルを実施することです。

5：安全なセキュリティ

セキュリティの要求となります。情報システムの安全に関する要求です。ユーザーの利用制限や不正なアクセスの対応方法について検討します。

対策の実施例としては、アクセスを制限することやデータの秘匿をすることです。また不正を検出したい場合に追跡、監視、検知する対策をとります。

6：システム環境やエコロジー

システムの設置環境やエコロジーに関数要求です。温度／湿度、騒音など、システム環境について検討します。

また、CO2排出量や消費エネルギーなどの検討もあります。対策の実施例としては、規格や電気設備にあった機器の選別、環境負荷を低減させる構成を提案することになります。

非機能要件に重要な単語3つ

非機能要件を検討するうえで、押さえておきたいポイントがあります。非機能要件に関しては、顧客と定義を共有する必要があります。非機能要件を考えるうえで、運用時のサービスの要求レベルを定義し合意することでサービス運用の品質を高める考え方を3つ紹介します。

1：SLA

SLAは翻訳すると、サービスレベル合意とサービスレベル保証になります。サービスの提供側と利用者側が、そのサービスを満たすべき品質について、合意することを示しています。

SLAと似ている言葉があります。それは、「SLO」（Service Level Objective）です。

SLAは「サービスレベル合意」や「サービスレベル保証」を指す言葉で、サービスの両者（提供者側と利用者側）が、そのサービスが満たすべき品質について合意すべきものとして解釈されています。

SLAで定義する内容は、業務内容やサービス内容次第で異なります。可用性ではなくシステムのパフォーマンスや拡張性などをSLAとして定義することもあります。

たとえばシステムにアクセスした際の応答速度や、検索サービスで検索結果が表示されるまでの応答性として平均時間をSLAとして定めるといったことが考えられます。

このSLAのポイントは、お互いに合意した成果物またはサービス内容を満たせなかった場合は罰則（ペナルティ）があるということです。

2：SLO

SLOは「サービスレベル目標」です。こちらはSLAで決めた内容を達成するためのものです。サービス提供者が設定する目標となります。一般的にSLOの設定した目標はSLAで設定したものよりも厳しくする方向になります。

SLAとSLOの違いは、SLOには罰則（ペナルティ）がないことが挙げられます。SLOにはサービス提供者側の目標の数値となります。クラウドサービスのように利用者側に開示されないことが多い傾向にあります。

3：RASIS

RASISは、システムの性能・機能を評価する以下の5つの概念の頭文字を合わせた言葉となります。Reliabilityは、信頼性です。故障を起こしにくさの度合いでありMTBF（平均故障間隔）が指標として用いられます。

Availabilityは、可用性です。必要な時にシステムが使用可能状態である度合いで、稼働率が指標として用いられます。

Serviceabilityは、保守性です。システム障害時の修理しやすさの度合いです。

Integrityは完全性です。保存されているデータが完全で損なわれてないかどうかの度合いです。

Securityは、安全度合いです。保存されているデータが、災害や障害などに対してもつ耐性の度合いです。機密性とも呼ばれています。

非機能要件を構成する際のポイント3つ

非機能要件について、構成する際のポイントを3つ紹介します。担当者からクライアントに提示すること、システム基盤の関連性を意識すること、システム基盤の関連性を意識することを説明します。

総じて非機能要件の見える化を通じて、利用者・社会・開発者の発展に貢献することを狙いとしています。

1：担当者がクライアントに提示する

まず、担当者がクライアントの要求に沿って非機能要件を提示します。このとき、業務への情報システムの影響を明確に説明するようにします。

これによって情報システムの安心・安全な利用や効率的利用を推進し、情報システム費用の説明根拠を明確にすることができます。

2：システム基盤の関連性を意識する

システム基盤の関連性を意識することも、非機能要件を構成する際に重要なポイントとなります。これにより、安心・安全で便利な社会インフラの実現する、健全な業界構造と業界発展を考えられるようになります。

システム基盤の関連性を意識することは、受発注関係や責任の明確化につながるのです。

3：利用者がストレスなく使うシステム構築が必要

利用者がストレスなく使うシステム構築が必要になります。非機能要件を可視化することで、システム開発における手戻り、コストの圧縮・期間短縮が見込めます。

加えて、システムに運用におけるトラブルの減少・削減にもつながり、それは、利用者がストレスなく使うことにもつながります。

非機能要件を理解して転職活動に活かしてみよう

非機能要件を理解して、転職活動に活かしてみましょう。非機能要件を開発の序盤から意識することで、その後の開発がスムーズになります。セキュリティ観点も含めて、今後も必要になる要件といえます。その知識を得られれば、いろいろな開発で応用できます。

是非、非機能要件の知識をつけてください。

インフラエンジニア専門の転職サイト「FEnetインフラ」

FEnetインフラはサービス開始から10年以上『エンジニアの生涯価値の向上』をミッションに掲げ、多くのエンジニアの就業を支援してきました。

転職をお考えの方は気軽にご登録・ご相談ください。