機能要件・非機能要件とは？違いや重要な理由、定義する手順を解説

システム開発における機能要件の重要性は理解していても、非機能要件についてはいまいちわからないという人も多いのではないでしょうか。

そこで今回は、機能要件と非機能要件とは何か、何が違うのか、それぞれの定義の仕方などについて詳しく解説します。どちらも重要な要件なので、この記事を読んで正しく理解しシステム開発に活かしましょう。

要件定義などの相談ができる開発会社一覧は、「見積依頼が可能なソフトウェア・業務システム開発の会社一覧」をご覧ください。

1.　機能要件とは？

機能要件とは、わかりやすく言うとシステムを発注するクライアントが要望している機能のことです。画面仕様や画面遷移の流れ、入出力機能、保持するデータ項目など、クライアントが実現したい機能や挙動のすべてを指します。

これらの機能要件は、要件定義工程でドキュメント化します。クライアントが要望する機能要件をすべて取り込み、漏れなく要件定義することが重要です。

非機能要件との違い

非機能要件は、機能要件以外にシステムに必要な要件のことです。たとえば、検索結果画面が出力されるまでの時間を何秒以内にするか、セキュリティの強度をどこまで高めるか、運用時に必要なログ出力はどうするかなどです。

機能要件のようにクライアントが直接意識することはなくても、システムにとって非常に重要な機能です。一見わかりづらい機能に見えますが、非機能要件の定義が充実したシステムを開発すれば、クライアントから喜ばれるでしょう。

機能要件はもちろん、非機能要件を的確に定義することは非常に重要なことなのです。

2.　機能要件を定義する手順

機能要件を定義する手順は、次のとおりです。

1．クライアントから詳細なヒアリングをする

まずは、クライアントの要望を詳細にヒアリングします。とはいっても、クライアントはITのプロではないので、どんなシステムがほしいのか、要件に合ったシステムとはどのようなものかを明確に定義できません。 そのため、クライアントが開発を依頼する背景と目的を明確化するところからはじめます。クライアントの要望はどこからきているのかという背景と目的を明確化し、詳細にヒアリングを行っていきます。

2．必要機能を洗い出す

ヒアリングの結果を元に必要な機能を洗い出し、その機能をクライアントに提示して、細かく確認していきます。 ただし、必要な機能をクライアント主導で決めると、工数が膨らみすぎて無駄な機能が増えてしまうため、注意が必要です。

3．機能要件を選定する

必要な機能がそろったら、機能実現の難易度や工数を見積もり、実装する機能要件を選定します。クライアントに機能ごとの予算を認識してもらうことで、無駄な機能を省いて効率的なシステムの機能要件を選定できます。 値引き交渉に発展する可能性が高いので、あらかじめそれを見越した見積もりを設定しておくのもよいでしょう。

3.　非機能要件はクライアントの満足度向上にかかわる重要なもの

次に、非機能要件について、詳しく見ていきましょう。機能要件も重要ですが、非機能要件も、クライアントの満足度を向上させるために重要な要素です。

たとえば、処理速度が速ければサクサクと使いやすいですし、不正ログインを検知して通知するシステムがあれば、不正アクセス対策になり、安心です。

このように、クライアントが気づかなかった重要な非機能要件をしっかりと実装できると、クライアントからの信頼度が向上するでしょう。

4.　非機能要件として定義されるカテゴリー

非機能要件は機能要件とは違い、目に見えにくいものなので定義しづらいという問題があります。そこで、IPA（情報処理推進機構）による以下の非機能要件の、6つのカテゴリーの定義に沿って、説明します。

可用性

システムを継続的に利用するための要件です。24時間稼働に耐えうるか、障害や災害発生時のサーバー機器などの冗長化やバックアップが十分か、復旧が可能な作りになっているかなどです。

クライアントの要望に応じて、1日何時間稼働できるか、何年間運用が可能かなど、可用性について、設計する必要があります。

性能・拡張性

システムの性能や拡張性の観点についても、設計する必要があります。たとえば、将来ユーザー数が増える見込みがある場合は、データベース容量やアクセス数の増加に耐えうる設計になっている必要があります。

また、今後業務を拡張していく予定があるなら、データ項目の定義拡張やサーバー・ネットワーク環境の拡張などができる設計にしなければなりません。

運用・保守性

システムの運用・保守に関する機能が整っているかも重要です。具体的には、日次・月次メンテナンス時に、サーバー再起動やログ出力、設定変更などができる運用コマンドや手順が整っているかです。

エラーや障害発生に備えてシステムの監視手段があるか、バックアップ方式の確立や障害発生時の体制、マニュアルが整備されているかも重要です。

移行性

既存のシステムがある場合は、データを新システムに移行する必要がありますし、今後も新しいバージョンのシステムに移行していく可能性もあります。

移行時には、移行スケジュールの立案や移行ツールの開発、移行作業手順と体制の確立、リハーサルの実施、失敗時の戻し作業などを計画する必要があります。

セキュリティ

不正アクセスや情報漏洩などのセキュリティ対策も、非常に重要です。ファイアウォールなどのネットワークセキュリティ対策、ログイン回数の制限による不正アクセス対策など、あらゆるセキュリティインシデントに対する対策を講じる必要があります。

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

近年の環境対策への意識の高まりを受け、システム環境・エコロジーに対する対応も必要になってきました。たとえば、耐震や免震対策、騒音対策、二酸化炭素の排出量や電力消費エネルギーの削減などの項目があります。

5.　非機能要件を定義する手順

非機能要件の定義方法は、以下のとおりです。

1．機能要件が定義できていることを確認する

前提として、機能要件の定義が終わっている必要があります。

2．非機能要件を仮設定しクライアントと調整する

上記のIPAの非機能要件の定義を元に、何段階かのレベルで非機能要件を仮設定します。 たとえば可用性なら、運用継続時間が定時内のみ、夜間のみ停止、1日1時間程度の停止、若干の停止あり、24時間無停止という5段階が定められています。そして、それぞれのレベルの非機能要件の、概要と見積もりを用意し、クライアントに提示します。

3．非機能要件を選定する

クライアントと非機能要件のレベルと内容を調整し、見積もりも提示したうえで要件を選定します。

6.　非機能要件を定義・搭載するうえでの注意点

非機能要件を考えるうえで注意すべき点は、以下のとおりです。

正確な要件定義を行う

機能要件と同様に、非機能要件を要件定義する際には、詳細で正確な定義を行いましょう。抜けや漏れ、不明確な点があると、システム開発に悪影響を与えます。

クライアントから入念なヒアリングを行う

クライアントは、当然最大レベルの非機能要件を要望するでしょうが、コストの関係で、それができるとは限りません。本当に必要な非機能要件は何かを入念にヒアリングを行って選定することで、最小限のコストで必要な非機能要件を実装できます。

クライアントの合意をとったうえで搭載する

開発していくうえで「この非機能要件は不要では」と判断した場合にも、必ずクライアントの合意をとりましょう。逆に、不要な非機能要件を搭載して後で不要だったと言われるケースもあるので、必ず合意をとってください。

非機能テストを重ねる

非機能要件を搭載しても狙った性能が出ない場合があるため、必ず以下のような非機能テストを重ねる必要があります。

• 性能テスト：レスポンスタイムや処理速度の測定などのテスト
• ストレステスト:アクセス数の限界値テストなどの負荷テスト
• ユーザビリティテスト：システムの使いやすさを調べるテスト
• 保守性テスト：システム改修時や機能追加時などの拡張がしやすいかのテスト

発注クライアント側で意識すべきこと

開発会社側は、上記で見てきたような内容を注意事項として確認しながら非機能要件を定義していきます。

発注側としては、上記の注意点を踏まえ、できる限り開発会社側が求める情報を提供することが大切です。些細な情報でも、より正確な開発に近づけるために、システムの導入目的をベースとした情報をできるだけ共有していきましょう。

もし、開発会社との打合せにて上記工程などを進める上で、不安に思うことなどあれば、率直に開発会社に伝えることが大切です。伝えても、なかなか改善の余地や不安感が解消されない場合は、念の為に別で相談できる会社の候補も準備しておくことをおすすめします。万が一依頼している会社に継続して依頼が難しいと判断した場合に、スケジュールの遅れや費用リスクを最小に抑えるためです。

リカイゼンでは、そのような状況などお伺いしながら、対応可能な会社候補を案内しますので、「相談フォーム」よりご連絡ください。無料でご利用いただけます。

7.　まとめ

この記事では、機能要件と非機能要件とは何か、何が違うのか、それぞれの定義の仕方などについて詳しく解説しました。

機能要件だけでなく、非機能要件もまた重要なシステム要件です。IPAの非機能要件の定義を参考に、非機能要件を適正に定義しましょう。