発注ラウンジTOP>ノウハウ>機能要件とは?システムの品質向上にかかわる非機能要件との違い

機能要件とは?システムの品質向上にかかわる非機能要件との違い

XのアイコンFacebookのアイコン

functional-requirement機能要件は、ソフトウェアやシステム開発において必要となる大切な工程です。制作するシステムに盛り込みたい機能をクライアントから適切に聞き出し、どのような機能が必要なのかを明確に定義します。また、機能要件と反する言葉に、「非機能要件」があります。
非機能要件は、クライアントから提示された機能ではなく、レスポンススピードやセキュリティといった機能要件以外の要件を指します。今回は、システム開発・制作工程において重要な機能要件と非機能要件についてご紹介します。

 

目次

 

初めてプロジェクト担当者になった方向け
プロが教える「IT基礎知識・用語集」プレゼント

システム開発「はじめの一歩」ITのプロから学ぶ基礎知識

この資料でわかること
・システム開発の流れ
・専門用語の解説
・開発手法によるメリット・デメリット
・失敗を防ぐコツ

 

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

機能要件は、「ソフトウェアやシステム開発において、クライアントから求められる『機能』のこと」です。一方、非機能要件とは『機能以外』のユーザービリティ、性能、拡張性、セキュリティなどの品質的に関連するもの全般を指します。

ソフトウェアやシステムなどにおいて、クライアントからの要望としてある『機能』を満たすことは、開発においては最低条件です。非機能要件となる『機能以外』の全般部分が備わっていないと、ユーザーから使い勝手が悪いと不満が出たり、セキュリティに不備があり情報漏洩するという問題に発展したりする可能性があります。そのため、機能要件と共に非機能要件についてもバランス良く兼ね備えることで、はじめて品質が担保されるのです。

それぞれの役割については以下に解説します。

 

機能要件とは?

機能要件と非機能要件は、どちらもシステム開発における最初の工程です。まずは、開発の中心となる機能要件について見ておきましょう。

一般的にシステム開発・構築では「要件定義」→「設計」→「製造」→「検査」の順で、制作が進行していきます。

要件定義では、制作するソフトウェアやシステムについて、クライアントから求められている機能を確認します。要件定義のうち、「必ず搭載すべき機能」を「機能要件」といいます。機能要件は、クライアントが搭載してほしいと望んでいる事項であるため、直接のヒアリングで比較的容易に吸い上げることができます。例えば、「現行システムで今利用している機能は必ず盛り込んでほしい」、「◯◯ができなくなると困る」など、達成しなければならない基本となる部分が機能要件です。

機能要件はクライアントにとって絶対に必要な機能であり、納品時に定められた機能が未実装であればプロジェクトとして失敗ということになります。クライアントにとって機能要件の実装は当たり前であり、最低限必要な機能なので、搭載されているからといって、満足度が大きく高まることはありません。

 

クライアントの満足度が高まる「非機能要件」

一方、要件定義のうち、機能要件に当てはまるもの以外を「非機能要件」といいます。非機能要件は、クライアントの満足度向上に直結します。

 

●非機能要件とは

非機能要件とは、主目的となる機能要件以外の機能であり、機能面以外の要件全般を指します。ユーザービリティ、性能、拡張性、セキュリティなどの機能を指し、製品にとって不可欠な「質」の部分です。例えば、高機能な売上管理システムを開発しても、1日の売上集計に実行開始から30分以上もかかってしまうと、顧客満足度は低くなるでしょう。高品質な非機能要件が定められれば、クライアントの満足度アップにつながります。

 

●非機能要件は決めるのが難しい

非機能要件の内容は多岐にわたり、運用する過程での条件やセキュリティ、管理のしやすさ、パフォーマンスなど、網羅するのが難しいほど副次的な項目が多くあります。

非機能要件はクライアントから確実な要望があるわけではなく、ヒアリングした内容をベースに、開発側が考える要件です。考えられるすべての非機能要件を盛り込むと、予算と合わなくなってしまうため、どこまでの非機能要件を含むのか判断しなければならない点も非機能要件を難しくしている要因の一つです。

 

非機能要件のグレード

「非機能要求グレード」は、「非機能要求」についてのクライアント(ユーザー)と開発者との認識の行き違い、互いの意図とは異なる理解を防止することを目的として作成されたツールです。非機能要求に関する項目を、網羅的に一覧化し、さらに分類されています。重要な項目から順に並んでいるため、要求レベルを双方が確認、設定しながら、非機能要求の確認を行えるようになります。

非機能要求グレードでは、非機能要件を以下の6種類238項目に分類しています。

大枠となる「可用性」、「性能・拡張性」、「運用・保守性」、「移行性」、「セキュリティ」、「システム環境・エコロジー」の6分類について、以下に解説します。

 

●可用性

可用性とは、システムやサービスを継続的に利用可能にするための要求です。具体的には、運用スケジュールや障害発生時の復旧などに関する要求のことを指しています。可用性を実現させるには、バックアップ体制や障害発生時の回復方法を確立させることが必要です。

例えば、ECサイトの場合は、24時間364日の稼働が原則です。メンテナンス時も、なるべくサービスを停止しないことを求め、さらに災害発生時にもダウンタイムを最小にしたいならその旨を記載する必要があります。

 

●性能・拡張性

性能・拡張性とは、システムの性能および将来的なシステム拡張を可能にするための要求です。

性能・拡張性を実現させるには、ソフトウェア内部の処理を効率化したり、ネットワーク機器の配置に配慮したりして、処理速度や機器の新規設置が必要です。

例えば、稼働当初は問題なかったのに、稼働後3ヶ月くらいでシステムが遅くなってユーザーの使い勝手を著しく低下させることもよくあります。開発サイドからすると「そんなに増加するとは聞いていなかった」というわけですが、最初からデータ量やユーザー数がどれくらい増加するか示していれば責任は開発側に移ります。そのため、開発側もきちんとスケーラビリティを考えてプラットフォームやシステム構成を企画・設計するので、こうしたトラブルが起こりにくくなるのです。

 

●運用・保守性

運用・保守性とは、システムの運用や保守におけるサービスに関する要求です。具体的には、システム運用時の稼働率や問題発生時の対応などに関する要求は運用/保守性のことを指しています。

運用・保守性を実現させるには、正常運用のための監視の充実や、運用マニュアルの拡充によって対策が必要です。

例えば、Webサイトや社内システムで「システムメンテナンスのため、明日の3時から6時までサイトを止めます」というようなアナウンスをよく目にします。メンテナンスである程度のダウンタイムを認めても良いシステムならば、コスト削減のために割り切るのは当然です。ただし、その場合でも、どの程度までメンテナンスのための停止を許容できるかを非機能要件に記載した方が間違いはないです。一方、メンテナンスの際でもシステムを連続運転させて欲しい場合は、その旨を非機能要件に明記し、ホットスタンバイなどの仕組みを用意することになります。

 

●移行性

移行性とは、現行システム資産の移行に関する要求です。

移行性を実現させるには、移行までのスケジュール調整や、リハーサルの実施によって対策が必要です。

例えば、その要求には新システムへの移行期間および移行方法や移行対象資産の種類および移行量などがあります。この要求への対処には、移行スケジュール立案、移行ツール開発や移行体制の確立、移行リハーサルの実施などが出てきます。

 

●セキュリティ

セキュリティは、情報システムの安全性の確保に関する要求です。具体的には、利用者の制限や不正アクセスの防止などに関する要求はセキュリティのことを指します。セキュリティを実現させるには、例えば、アクセス制限、データの秘匿や不正の追跡・監視・検知、運用員などへの情報セキュリティ教育などが必要です。

 

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

システム環境・エコロジーとは、システムの設置環境やエコロジーに関する要求のことです。具体的には、耐震/免震、重量/空間、温度/湿度、騒音など、システム環境に関する事項、そしてCO2排出量や消費エネルギーなどエコロジーに関する事項があります。システム環境・エコロジーを実現させるためには、規格や電気設備に合った機器の選別、環境負荷を低減させる構成などが必要です。

非機能要求グレードは、独立行政法人情報処理推進機構(IPA)が、要求定義の品質を確保するために策定し、ガイドラインを提供しています。非機能要求グレードは、誰でも使用できるようにIPAの公式サイトよりダウンロードが可能です。より詳細な内容を知りたい方や、非機能要求グレードを実務で使ってみたい方は「システム構築の上流工程強化(非機能要求グレード):IPA 独立行政法人 情報処理推進機構」から資料をダウンロードして活用してください。

 

非機能要件の大切さと注意点

非機能要件は、クライアントが直接求めている要求ではありません。それなのに、システム開発において重要視されるのはどうしてなのでしょうか。

 

●なぜ非機能要件が重要なのか?

非機能要件は、機能要件を満たした上で搭載される要件です。システム開発において、機能要件がメイン機能だとすると、非機能要件はオプションのような機能であり、非機能要件を満たせば満たすほど、クライアントの満足度が高まります。

システム会社も、1つのクライアントからシステムを1つ受注して、納品したらそれで終わりというわけでありません。システム拡張や数年後のシステムリプレース、新たなシステムの発注や運用など、クライアントとの継続的な付き合いは必要不可欠です。そのため、非機能要件を満たしてクライアントの満足度を高めることはとても重要なのです。

 

●非機能要件の注意点

非機能要件はクライアントが本当に困っていること、改善したいことについてヒアリングを通して聞き出します。事前にある程度想定される要件項目を準備しておき、クライアントの要求を聞き出しながら提案しましょう。良かれと思って勝手に盛り込んだ機能が実際の仕事の流れに沿っていなければ、時間をかけて制作した機能であってもクライアントの満足度は下がってしまいます。

クライアントが確実な要求をしたわけではない非機能要件については、搭載前に事前に合意が必要です。「非機能要件のどの項目が何を示しているか」「どれくらいの重要性があるか」など、項目についてクライアントにどう伝えるのかを確認しておきましょう。例えばセキュリティ項目を強固にするシステムであれば、その重要性を説明するのはもちろん、セキュリティ機能の開発予算もクライアントに納得してもらう必要があります。

すべての非機能要件をクライアントに説明しなくても良いですが、特にユーザービリティや性能など、ユーザーが直接触れる部分は事前に合意を取っておかないと、納品後のクレームにつながってしまう危険性があります。

 

●非機能要件を双方で確認してトラブルを回避しよう

システム開発のプロジェクトで、トラブルが発生しやすいのが非機能要件です。すべてのクライアントに当該するわけではありませんが、一般的に何かのシステムを開発する上で、クライアントは「何をしたいか」までは検討できます。しかし、その次の段階にある「実際の使い勝手」については把握できないことがほとんどです。

例えば、自動で給与計算をするシステムを開発するとなった場合、そのシステムの処理が1ヶ月もかかるような機能では、実際の現場では使い物になりません。そのため、クライアント側としては「そんなに時間がかかるとは聞いていない」というクレームになりますが、外注先としては「要望された通りの機能は搭載した」と話が平行線になりかねません。

そのため、非機能要件でトラブルを起こさないためには、双方が非機能要件についてきちんと話し合い、現実的な運用目線で検討することが大切なのです。

 

ソフトウェアの魅力をアップする非機能テスト

クライアントの満足度に直結する品質の高いソフトウェアやシステムを納品するために、非機能テストで確認をしてみましょう。

 

●非機能テストとは?

システム制作の検査工程に該当する非機能テストとは、システムの主目的となる機能以外の部分を検証するテストです。機能以外のすべてが検証対象のため、テスト項目には多くの種類が含まれます。非機能テストをクリアすればするほど、クライアントの満足度は上がるでしょう。

 

●非機能テストの内容例

非機能テストの一部の内容をご紹介します。

 

<性能テスト>

性能テストは、パフォーマンステストとも呼ばれ、ソフトウェアやシステムの処理速度、レスポンススピードなどパフォーマンス部分に関するテストです。特に、ユーザーの操作感に影響する内容で、性能テストがクリアされていないシステムは操作ストレスなどが発生し、クレームの原因となります。

 

<ストレステスト>

事前に定義した限界値や、それ以上の負荷を与えて検証するのがストレステストです。例えば、多数の同時アクセスによってサーバーのレスポンススピードが低下したり、停止したりしないように、事前に想定した同時アクセス数に耐えられるかなど、テストを行いって確認していきます。

 

<ユーザービリティテスト>

直感的な操作ができるかなど、システムの使いやすさをテストするのがユーザービリティテストです。機能をすべて満たしており、レスポンスも高く、セキュリティも万全という完璧なシステムだとしても、どこにどの機能があるのかユーザーがわからないような設計では機能を使いこなせず、満足度が下がってしまうでしょう。

 

<保守性テスト>

ソフトウェアやシステムに欠陥があり、改修が必要となった際に、修正・追加しやすく設計されているかなどを確認するテストです。保守性テストが不十分だと、システム改修時にクライアントが予想しているよりも、多額の予算が必要になることがあり、後から問題が発生するおそれがあります。

 

機能要件・非機能要件には正確な要件定義が必要不可欠

要件定義はどちらも大切で、ソフトウェアやシステムの開発には正確な要件が必要不可欠です。

もちろん最重要は機能要件であり、漏れがあった場合には大きなトラブルになりかねません。

しかし、クライアントにとっては機能要件に定義されている機能は実装されて当たり前のもので、システムの質を上げて満足度を高めるのは非機能要件です。満足度の高いシステムをクライアントへ提供するためにも、機能要件と非機能要件は時間をかけてでも正確かつ丁寧に行う必要があるでしょう。

 

システム開発の最適な発注先をスムーズに見つける方法

システム開発会社選びでお困りではありませんか?
日本最大級のシステム開発会社ポータルサイト「発注ナビ」は、実績豊富なエキスパートが貴社に寄り添った最適な開発会社選びを徹底的にサポートいたします。
ご紹介実績:22,000件(2024年10月現在)

外注先探しはビジネスの今後を左右する重要な任務です。しかし、

「なにを基準に探せば良いのか分からない…。」
「自社にあった外注先ってどこだろう…?」
「費用感が不安…。」

などなど、疑問や悩みが尽きない事が多いです。
発注ナビは、貴社の悩みに寄り添い、最適な外注探し選びのベストパートナーです。
本記事に掲載するシステム会社以外にも、最適な開発会社がご紹介可能です!
ご相談からご紹介までは完全無料。
まずはお気軽に、ご相談ください。 詳しくはこちら

 

初めてプロジェクト担当者になった方向け
プロが教える「IT基礎知識・用語集」プレゼント

システム開発「はじめの一歩」ITのプロから学ぶ基礎知識

この資料でわかること
・システム開発の流れ
・専門用語の解説
・開発手法によるメリット・デメリット
・失敗を防ぐコツ

 

■システム開発に関連した記事

 

希望ぴったりの外注先がラクして見つかる
soudan_banner

人気記事

関連記事

関連特集

offer_banner
即戦力のシステム開発会社を探すなら発注ナビロゴ
発注ナビは、システム開発に特化した
発注先選定支援サービスです。
紹介実績
22000
対応社数
6000
対応
テクノロジー
319
紹介達成数
92%
システム開発の発注先探しで
こんなお悩みありませんか?
checkbox
なかなかいい外注業者
見つからない。
checkbox
ITの知識がなくて
発注内容をまとめられない。
checkbox
忙しくて外注業者を探す
時間がない
悩んでいる人物
発注ナビの主な特徴
IT案件に特化
IT案件に特化
日本最大級6000社以上のシステム開発・WEB制作会社が登録。IT専門だから細かい要望が伝わり、理想的なパートナーが見つかる。
ITへの不安を徹底サポート
ITへの不安を徹底サポート
専門コンシェルジュがしっかりヒアリングするので、IT知識に不安があっても、まだ要件が固まっていなくても大丈夫。
完全無料・最短翌日紹介
完全無料・最短翌日紹介
コンシェルジュに発注内容を話すだけで最短翌日に開発会社をご紹介。しかも完全無料・成約手数料も無し。
さらに
東証プライム上場
「アイティメディア株式会社」
グループが運営
ご相談内容は一般公開しないため、クローズド案件でも安心。
ご紹介企業は第三者調査機関にて信用情報・事業継続性を確認済です。

発注先探しの
ご相談フォーム

発注ナビは貴社の発注先探しを
徹底的にサポートします。
お気軽にご相談下さい。
必須
必須
必須
■必要な機能・課題■ご予算■スケジュールなど
■企画書やRFPの添付が可能です(10MBまで)

会員登録には、
発注ナビ 利用規約  及び 個人情報の取扱い 
「当社からのメール受信」への同意が必要です。