非機能要件とは何？機能要件との違いや設計方法を解説

非機能要件とは、簡単に言うとシステムを構築するにあたって性能面やセキュリティ面などにおいて実現するべき要件で、顧客が潜在的に持っている隠れた要件の事を言います。

そこで今回は、非機能要件と機能要件の違いや非機能要件を理解する上でのポイント、非機能要件の設計方法などをご紹介します。
エンジニアの方や非機能要件について知りたい方は、ぜひ参考にしてくださいね。

非機能要件とは？

まずは、非機能要件とは何かを見ていきましょう。

非機能要件とは、その名の通り機能以外の要件を意味します。
機能とは、顧客が持つ要望とほとんど同じと考えてよいでしょう。

たとえば、「今までメールで申請していた社内の手続きをウェブシステムにしたい」は顧客要望であって、大雑把な機能要件となります。

これに対し、 「大勢の社員が一斉にアクセスしてもシステムダウンしないようにしてほしい」 「障害復旧時は障害発生時点と全て同じ状態に戻してほしい」などの性能面やシステムの安全を実現するために必要な要件が非機能要件となります。

機能要件と非機能要件の違いは？

前述の通り、要件定義における顧客の要望は機能要件と非機能要件の2つに分けられます。

では、それらには具体的にどのような違いがあるのでしょうか。

機能要件

要件の定義の中で、システムに実装する機能に関わる要件を機能要件と言います。

顧客に対するヒアリングをしていく中で、こういった機能が欲しい、という顧客からの具体的な要望があります。

それに応えるために実際に必要となる機能が、機能要件として分類されているのです。

顧客の要望と、加味しなければならない予算やスケジュールなどを調整して、システムに実装する機能を共通の認識を持って機能案件として定義します。

顧客やプロジェクトの主な目的となる部分ですね。

非機能要件

対して非機能要件とは、システムの性能など実装する機能以外の要件の事を指します。 

提供したシステムが機能要件を満たしていても、動作に時間がかかる、不具合が発生した際の保守に不安があるなど、システムの質が悪ければ顧客の満足度は低下してしまいます。

そのためにも、顧客が欲しい機能を実際に運用していく中で必要な性能やセキュリティ面など、顧客側が想定していない細かな要件まで洗い出しておくことが重要になります。

そのような表立った要望に隠れた要件を非機能要件と分類し、定義しているのです。

非機能要件の項目一覧

非機能要件で定義しなければならない項目は多岐にわたるため、「FURPS+」や「ISO/IEC 9126(JIS X 0126)」など、設計項目を整理したものとして公開されているものが世界的に有名なものでもたくさんあります。

その中で、日本で良く用いられているのが、情報処理技術者試験の運営を行っていることで知られるIPA（独立行政法人情報処理推進機構）が提唱する「非機能要求グレード」です。

IT業界において情報処理技術者試験の知名度はとても高く、非機能要求グレードをベースとして対応すれば、難しい非機能要件の定義の中で顧客にも納得してもらいやすい設計方針になるでしょう。

そんな非機能要求グレードでは、非機能要件を大きく6つの項目に分類しています。

可用性

システムの稼働時間やシステムを継続的に運用するための安定性についての要件は可用性に分類されます。稼働時間や停止などシステムの運用スケジュールの策定、障害発生時の復旧方法の確立、バックアップの体制などを定義して対策します。

性能・拡張性

システムの処理性能や今後の拡張性に関する要件は性能・拡張性に分類します。機器の配置に注意し処理速度などにも対策したり、システムが処理できるデータ量や許容できる負荷、ユーザー数を決めておきます。将来的な機能の追加拡張が可能かどうかについてもここで検討します。

運用・保守性

システムの運用・保守に関する要件です。運用マニュアルを拡充することで問題発生時の役割分担。体制について対策したり、システムの監視体制やバックアップの方式、頻度などを決めたりするものは、ここに分類されます。

移行性

現行のシステムから新システムへの移行についての要求が分類されるのが移行性です。新システムへの移行期間や移行する種類、移行量などの要求を実現するために、移行スケジュールの立案、移行ツールや移行体制の確立、リハーサルの実施などを行います。

セキュリティ

不正アクセスの防止や利用制限など、システムの安全性を確保するための要求はセキュリティに分類します。アクセス制限や不正感知のための監視体制、システムを運用する社員への情報セキュリティ対策などを定義します。

システム環境・エコロジー

システムの環境やエコロジーに関する要件を定義する項目です。消費エネルギー量などの環境負荷を低減させるためにどのような構成にするかや、環境の規格や設備と整合性のとれた機器の選別を定義し対応します。

耐震や温度・湿度、騒音など、設置環境への要求もここに分類されます。細かな項目を1から考えるのは困難ですし、顧客側からも提案がなされにくいのが非機能要件です。

こういったカテゴリや指標を有効に利用して、落とし所を見つけながら満足度の高いシステムの構築を目指しましょう。

非機能要件を理解する上でのポイントをご紹介！

非機能要件の定義は難しく、経験や知識がないと抜け漏れが発生してしまいます。

スムーズに非機能要件を定義するために重要なポイントを2つ、ご紹介します。

非機能要求グレードを活用する

顧客が意識している部分ではない要求を引き出すためには、分かりやすく明確な説明とヒアリングが重要になります。

前述した非機能要求グレードをうまく活用して、漏れのないように実現可能な要件の定義を行いましょう。

非機能要求グレードには項目ごとの推奨要求レベルも定義されており、顧客の要望と実際の予算やスケジュールなど現実的な面を磨り合わせるのに役立てることができます。

もちろん、利用するユーザーを想定した操作性など、非機能要求グレードの6大項目以外にもシステムごとに考えておかなければならない要件もあります。

提案はこちらから！決定権は顧客にある

要件定義において、顧客側から細かな非機能要件について要求があることはほとんどありません。

相当システムに詳しい担当者が参加しているなどの場合以外、非機能要件の定義に関する提案はこちらから丁寧に行わなければなりません。

しかし、非機能要件に対する最終的な決定権はあくまでも顧客側にあるということを理解するのもポイントです。

エンジニアはシステムの決定権を握っているわけではなく、開発予算やスケジュールを管理しているわけでもありません。

顧客の満足度を上げるために取り入れて欲しい要件があっても、無理に提案するのではなく、顧客を誘導できると良いでしょう。

それを可能とするコミュニケーションスキルが必要になりますね。

まとめ

機能要件と非機能要件に違いはありますが、顧客が実現したい要件であることは同じです。そして、機能要件と比べて顧客の意識に上がりにくい非機能要件を設計することは、手間が多くかかる作業です。

しかし、非機能要件をきちんと設計できれば、システムとしての堅牢度が上がって顧客の信頼度へもつながる、などのメリットがあるでしょう。

非機能要件は機能要件と比べて地味な設計となりますが、顧客の隠れた要望をうまく引き出し、それを機能として現実のものにできるということは、顧客要望を実現するといったエンジニアの仕事の醍醐味と言えます。

＼　ログインしなくても検討機能が使える♪　／

新着のエンジニア案件を見てみる