機能要件と非機能要件について概要や違いを徹底解説！

システム開発における要件は大きく「機能要件」と「非機能要件」の二つに分類されます。

これらはシステムの構築においてどちらも不可欠ですが、その性質と役割は大きく異なります。

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

今回はそれぞれの特徴や定義内容について、詳しく解説していきます。

▼テスト計画・テスト設計についてはこちら▼

機能要件とは？

システム開発における機能要件とは、システムが「何をするか」を具体的に定義したものです。

これはユーザーがシステムを使って達成したい目的や、システムが提供するべき機能そのものを指します。

例えばオンラインストアであれば、「商品を検索できる」「商品をカートに追加できる」「クレジットカードで決済できる」といったものが機能要件にあたります。

これらはユーザーがシステムに「こうあってほしい」と期待する、直接的な動作や結果を示すものです。

機能要件はシステムの心臓部とも言える部分であり、要件定義の段階で「必ず搭載すべき機能」として明確にすることが非常に重要です。

この定義が曖昧だと、開発の途中で「こんな機能は必要なかった」「この機能は別の動きをするはずだった」といった認識のズレが生じ、手戻りやプロジェクトの遅延につながる可能性があります。

特にシステム開発未経験の新人エンジニアの場合、最初は機能要件と非機能要件の区別がつきにくいかもしれません。

しかし機能要件はユーザーにとっての「価値」を直接生み出す部分であると理解することで、その重要性を認識しやすくなります。

機能要件で定義すべき項目

機能要件を定義する際には、単に機能名を挙げるだけでなく、その機能がどのような目的で、どのように動作するのかを具体的に記述する必要があります。

定義すべき主な項目としては、以下のような点が挙げられます。

機能の名称と概要

その機能が何であり、どのような役割を果たすのかを簡潔に示します。

入力と出力

その機能を利用するために必要な情報（入力）と、機能が実行された結果として得られる情報（出力）を明確にします。

例えば「ログイン機能」であれば、「ユーザーIDとパスワードの入力」が入力であり、「ログイン成功のメッセージ表示」や「マイページへの遷移」が出力です。

処理内容

入力された情報に対して、システムがどのような処理を行うのかを具体的に記述します。

どのような条件で、どのような計算が行われ、どのようなデータが更新されるのかなどを詳細に定義します。

正常系と異常系

機能が正しく動作した場合（正常系）と、エラーが発生した場合（異常系）のそれぞれについて、システムの挙動を定義します。

例えばパスワードを間違えた場合のメッセージ表示や、システムエラーが発生した場合の対応などです。

関連するデータ

その機能が利用するデータベースのテーブルや、参照するマスターデータなど、関連するデータを明確にします。

これらの項目を具体的に定義することで、開発者、テスター、そして顧客の間で機能に対する共通認識を持つことができ、後の開発工程での認識齟齬を減らすことができます。

機能要件の注意点とコツ

機能要件を定義する上でいくつか注意すべき点と、より効果的に定義するためのコツがあります。

曖昧な表現を避ける

まず最も重要な注意点として、曖昧な表現を避けることが挙げられます。

「〜できるはず」「〜と思われる」といったあいまいな言葉ではなく、「ユーザーは商品一覧画面で、商品名、価格、在庫状況を確認できる」のように、誰が読んでも同じように解釈できる具体的な言葉で記述することが重要です。

ユーザー視点を忘れない

機能要件は、システムがユーザーに対してどのような価値を提供するのかを示すものです。

そのため開発側の都合だけでなく、実際にシステムを使うユーザーが何を求めているのかを深く理解し、その視点から機能を定義することが成功の鍵となります。

実現可能性を考慮する

理想的な機能をすべて盛り込もうとすると、開発コストや期間が膨大になる可能性があります。

そのためビジネス上の優先順位や技術的な実現可能性を考慮し、本当に必要な機能に絞り込む勇気も必要です。

関係者とのコミュニケーションを密にする

要件定義は一度行ったら終わりではありません。

顧客、開発者、テスターなど、プロジェクトに関わるすべてのメンバーと積極的に議論し、フィードバックを取り入れながら、要件を洗練していくプロセスが不可欠です。

システムテストの設計を担当する際に機能要件と非機能要件の区別が曖昧だと感じた場合でも、積極的に関係者に質問して疑問を解消していくことで理解が深まり、より質の高いテスト項目を作成できるようになります。

非機能要件とは？

システム開発において、非機能要件とは、システムが「どのように動くべきか」、つまりシステムの品質や性能、信頼性、運用しやすさなどを定義するものです。

これは直接的な機能とは異なり、システムの使いやすさや安定性、安全性を裏側から支える重要な要素です。

例えばオンラインストアであれば、「同時に1000人がアクセスしても応答速度が遅くならない」「システムに障害が発生してもすぐに復旧できる」「不正アクセスから顧客情報を守る」といったものが非機能要件にあたります。

これらはユーザーが意識しないところでシステムの「当たり前」を支え、快適な利用体験を提供する上で不可欠な要素です。

機能要件が「何をできるか」であるのに対し、非機能要件は「どれだけきちんと、安心して、使いやすくできるか」を示すと言えるでしょう。

システム開発に携わるエンジニアにとって、この非機能要件の理解と適切な定義は高品質なシステムを構築するために欠かせません。

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

非機能要件がなぜ重要なのかというと、それがシステムの「質」を決定づけるからです。

たとえ優れた機能が搭載されていても、システムが頻繁にダウンしたり処理が極端に遅かったりセキュリティが脆弱であれば、ユーザーは安心して利用できません。

結果として、システムに対する不満や不信感が募り、ビジネス上の損失につながる可能性もあります。

特に経験の浅いシステムエンジニアや品質保証エンジニアにとって、非機能要件は目に見えにくい特性であるため、その重要性を見落としがちかもしれません。

しかし非機能要件は、システムの信頼性やユーザビリティ、保守性といった、長期的な運用を考えた際に非常に大きな影響を与える要素です。

プロジェクトの早い段階で非機能要件を明確に定義し、テスト計画に組み込むことで、後からの大規模な改修や手戻りを防ぎ、プロジェクト全体の効率と品質を高めることができます。

システムの品質は、機能要件と非機能要件の両方が満たされて初めて保証されると言えるでしょう。

非機能要件で定義すべき項目

非機能要件は多岐にわたりますが、一般的には以下の六つの項目に分類され、それぞれについて具体的に定義する必要があります。

可用性

可用性とは、システムが障害などで停止することなく、継続して稼働できる能力です。

ここにはシステムが中断なく稼働できる能力である「稼働率」の目標値や、定期的なメンテナンスのスケジュール、予期せぬ障害が発生した場合の復旧方法と、それに要する時間の目標を定義します。

例えばAmazon EC2のようなクラウドサービスでは、99.99%といった高い稼働率が保証されており、これはシステムが1,000時間稼働する中で停止時間を1時間以内に抑えることを意味します。

システムテストでは、バックアップ体制の確立や障害発生時の回復手順が適切に機能するかを検証し、システムが利用者に常に提供できる状態にあることを確認します。

性能・拡張性

性能は、システムがどれだけのデータを処理し、どのくらいの速度で応答できるか、また同時に何人のユーザーが利用できるかといった、ソフトウェアが要求された条件のもとでどれだけ効率的かつ迅速に機能を実行する能力です。

例えば伝票照会画面の表示速度を通常時は3秒以内、ピーク時は5秒以内とする、といった具体的な数値目標が設定されます。

拡張性とは、将来的にシステムを利用するユーザー数が増加したり、新たな機能が追加されたりした場合に、システムの性能を落とすことなく柔軟に対応し、増強できる能力を指します。

テストではシステムが現在の業務量や将来的な負荷増大に対応できるかを検証し、ピーク時においても安定したパフォーマンスが維持されるかを確認します。

運用・保守性

運用・保守性とは、システムが導入された後に、安定して稼働し続けられるようにするための運用や、問題発生時の保守作業がどれだけ容易に行えるかを判断するための能力です。

これにはシステムの監視方法、バックアップの対象や取得頻度、障害発生時の復旧手順や体制、そして運用マニュアルの整備といった項目が含まれます。

異常時の対応方法だけでなく、定期的なメンテナンス時の稼働レベルや必要な人員、体制なども事前に取り決めておく必要があります。

システムテストではこれらの運用・保守に関わるサービスが適切に機能するか、またシステムの変更や修正が容易に行える設計になっているかを確認し、長期的なシステムの安定稼働を支える基盤を検証します。

移行性

移行性とは、異なる環境へ容易に移動・導入・適応できる能力を指します。

特にデータ移行の正確性や、移行作業に伴う業務の停止時間を最小限に抑えることが重要視されます。

具体的には、旧システムのマスターデータやトランザクションデータを新システムへ安全に移行するための期間、移行方法、移行に関わるリハーサルの実施計画などが定義されます。

システムテストでは現行システムの資産（データや設定など）が正しく新しいシステムに移行されるか、移行期間中の業務影響が許容範囲内であるかなどを検証します。

データ移行は移行作業において最も重要な要素の一つであり、そのテストはシステムの信頼性を保証するために不可欠です。

セキュリティ

セキュリティは情報システムが外部からの不正利用や不正アクセス、情報漏洩などの脅威から、いかに安全に保護されているかを判断する能力です。

これにはシステムのアクセス制限、不正なアクセスや操作の検知・監視方法、さらには万が一の事態に備えたログの保存や追跡機能、そしてシステムを運用する担当者への情報セキュリティ教育に関する要求が含まれます。

システムテストでは認証機能の堅牢性、不正アクセスに対する防御策、データ暗号化の有効性などを検証し、システムの機密性、完全性、可用性が確保されていることを確認します。

セキュリティ要件はシステムの信頼性を左右するため、非常に重要な項目です。

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

システム環境・エコロジーは、システムの設置場所や物理的な環境、そして環境負荷に関する要件です。

これにはシステムが設置されるサーバー室の耐震・免震対策、温度・湿度管理、電源供給に関する要件、また、システムの稼働に伴う消費電力や発熱量、廃棄物処理といったエコロジーに関する要求が含まれます。

環境に配慮した対策や、環境負荷を低減させるシステムの構成などが定義されることもあります。

システムテストではシステムが指定された環境下で正常に動作するか、またエコロジー要件を満たしているかを確認します。

これにより、システムの運用が物理的な制約や環境基準に適合していることを検証します。

非機能要件の注意点とコツ

非機能要件を定義する上での注意点とコツは、機能要件と同様に非常に重要です。

数値目標を具体的に設定する

機能要件と同様に、曖昧な表現を避けることが求められます。

非機能要件は抽象的になりがちなので、「速い」「安全」といった曖昧な表現ではなく、「応答速度は3秒以内」「稼働率は99.99%」のように、具体的な数値で目標を定めることで、テストの評価基準が明確になります。

初期段階での確認を念入りに

非機能要件はシステムの基盤に関わるため、後から変更しようとすると大規模な改修が必要となり、コストや期間が大幅に増加する可能性があります。

そのためプロジェクトの早い段階で顧客や関係者と十分に議論し、合意を得ておくことが不可欠です。

改善を視野に入れる

また現状維持の意識ではなく、常に改善を視野に入れるというコツもあります。

非機能要件は一度満たせば終わりではありません。

技術の進歩やビジネス環境の変化に対応するため、常にシステムの性能やセキュリティを改善していく視点を持つことが重要です。

過剰な要件定義に注意する

高い可用性や性能を求めすぎると、開発コストが跳ね上がり実現が困難になる場合があります。

ビジネスの優先順位と予算を考慮し、現実的で費用対効果の高い非機能要件を設定することが大切です。

まとめ

システム開発において、機能要件と非機能要件はどちらも高品質なシステムを構築するために不可欠な要素です。

機能要件が「システムが何をするか」という具体的な動作や提供サービスを定義するのに対し、非機能要件は「システムがどのように動作するか」という、その品質、性能、信頼性、運用性といった側面を定めます。

機能要件と非機能要件の違いを正確に理解し、それぞれの特性を踏まえた上でテスト計画に組み込むことは、システム開発における手戻りを減らし、効率的かつ高品質なプロジェクト遂行に繋がります。

特にシステムテストの設計を担当する際には、両者の区別を明確にし、網羅性の高いテスト項目を作成することが、最終的なシステム品質を大きく左右するでしょう！

QA業務効率化ならPractiTest

テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！

この記事の監修

Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。

記事制作：川上サトシ