非機能要件とは？機能要件・業務要件との違い【基本情報技術者試験】

まず結論

非機能要件とは、システムが「何をするか」ではなく、どの程度の品質で、どのような条件・基準・方法で実現するかを定める要件です。

FE試験では、次の切り分けが重要です。

何ができるか
→ 機能要件

どのくらい速く、安定して、安全に使えるか
→ 非機能要件

どの技術・標準・運用条件で実現するか
→ 非機能要件

非機能要件には、性能や可用性だけでなく、次のような項目も含まれます。

技術要件
運用・操作要件
移行要件
付帯作業

何をするかが機能要件、品質・制約・開発方法・運用条件が非機能要件。

英語でイメージすると、What does it do? が機能要件、How well? / Under what conditions? が非機能要件です。

直感的な説明

オンラインショップを例に考えます。

商品を検索できる
→ 機能要件

検索結果を2秒以内に表示する
→ 非機能要件

「商品検索」という処理そのものは機能です。

一方で、「2秒以内」「同時に1,000人まで利用可能」「障害時も停止しにくい」といった条件は、機能の品質や制約を表します。

ここで、試験で迷いやすい例も見ておきましょう。

要求	分類	見分けるポイント
在庫がなければ警告メッセージを表示する	機能要件	「表示する」という具体的な動作
注文情報を登録する	機能要件	「登録する」という具体的な動作
画面を2秒以内に表示する	非機能要件	応答時間という品質水準
障害発生から2時間以内に復旧する	非機能要件	復旧時間という品質水準

「警告」「安全」といった言葉だけで非機能要件と決めないことが大切です。要求の中心が、具体的な動作なのか、品質や水準なのかを見ます。

さらに、次のような条件も非機能要件です。

開発言語はJavaを使用する
コーディング規約を定める
24時間監視する
旧システムからデータを移行する
利用者教育を実施する

つまり、非機能要件は、利用者が感じる品質だけでなく、開発・運用・移行をどのように行うかという条件も含みます。

定義・仕組み

機能要件

機能要件は、システムが実現する処理や機能を定めます。

例：

商品を検索する
注文を登録する
売上レポートを出力する
利用者を認証する
条件に応じて警告を表示する
他システムとデータを送受信する

判断の中心は、システムが何をするかです。

非機能要件

非機能要件は、システムの品質や制約条件、開発・運用・移行の方法を定めます。

例：

画面を2秒以内に表示する
24時間365日利用できる
利用者数の増加に対応できる
障害時に30分以内で復旧する
通信時に一定のセキュリティ水準を満たす
開発言語や開発標準を定める
監視方法やバックアップ方法を定める
移行時期や移行手順を定める
利用者教育を実施する

判断の中心は、どのような品質・条件・方法で実現するかです。

業務要件

業務要件は、業務そのものの進め方や役割を定めます。

例：

誰が承認するか
どの部署が入力するか
どの手順で処理するか
責任や権限をどう分けるか

業務をどう進めるか
→ 業務要件

システム化方針

システム化方針は、経営上・業務上の課題を踏まえ、なぜシステム化するのか、何を目指すのかを定めます。

例：

受注処理時間を短縮する
顧客満足度を向上させる
経営情報を迅速に把握する
業務コストを削減する

なぜシステム化するか
→ システム化方針

非機能要件は品質要件だけではない

非機能要件というと、性能や信頼性などの品質要件だけを思い浮かべやすいですが、それだけではありません。

分類	主な内容	例
品質要件	システムの品質	性能、信頼性、使用性、保守性
技術要件	実現方法や開発上の制約	開発言語、開発標準、システム構成
運用・操作要件	運用や監視の条件	運用手順、監視方法、バックアップ
移行要件	新システムへの移行条件	移行対象、移行手順、移行時期
付帯作業	導入に伴う作業	環境設定、利用者教育、運用支援

代表的な品質要件

項目	意味	例
性能	処理速度や処理量	応答時間2秒以内
可用性	必要なときに使える度合い	稼働率99.9%
拡張性	利用者やデータ増加への対応	サーバー追加が可能
運用性	監視や日常運用のしやすさ	監視方法や運用手順を定める
保守性	修正や改善のしやすさ	モジュール化しやすい構成にする
移行性	新環境への移しやすさ	データ移行手順を整備
セキュリティ	情報を守る強さ	必要なセキュリティ水準を定める

公式の出題範囲やシラバスは、IPA：基本情報技術者試験から確認できます。

科目Aでどう出る？

科目Aでは、説明文がどの種類の要件に当たるかを問われます。

判断の順番は次のとおりです。

業務の手順や責任か
システムの具体的な動作か
システムの品質や水準か
開発・運用・移行の条件か
経営上の目的や成果か

対応は次のようになります。

問題文の特徴	選ぶもの
業務手順、組織、責任、権限	業務要件
利用者の操作、処理内容、情報の流れ	機能要件
性能、可用性、保守性などの品質水準	非機能要件
開発言語、開発標準、運用、移行、教育	非機能要件
経営課題、成果、目標	システム化方針

「動作」か「水準」かで切る

機能要件では、次のような具体的な動作が中心になります。

入力する
登録する
計算する
表示する
検索する
通知する
承認する
出力する

非機能要件では、次のような品質の水準や条件が中心になります。

○秒以内
○件／秒以上
稼働率○％以上
○時間以内に復旧
○年間保存
指定された環境で動作

たとえば、次の二つは似ていますが、見る場所が違います。

異常を検知したら警告を表示する
→ 「警告を表示する」という動作
→ 機能要件

障害発生から2時間以内に復旧する
→ 「2時間以内」という復旧水準
→ 非機能要件

目的が安全性や信頼性に関係していても、要求の中心が具体的なシステム動作なら機能要件と判断できます。

数値があれば非機能要件、とは限らない

数値が出てきても、その数値が処理の条件なのか、品質の水準なのかを見ます。

注文数が10個を超えたら確認画面を表示する
→ 10個は処理を分岐する条件
→ 機能要件

確認画面を1秒以内に表示する
→ 1秒以内は応答時間の水準
→ 非機能要件

数字だけを手掛かりにすると、ひっかけに弱くなるので注意します。

開発基準・標準はなぜ非機能要件か

「システム開発で利用する言語に合わせた開発基準や標準を作成する」という内容は、システムの機能そのものではありません。

何を実現するか
→ 機能要件

どの言語・標準・方法で作るか
→ 技術要件
→ 非機能要件

そのため、開発言語、コーディング規約、開発環境などは非機能要件に分類されます。

インタフェースとの切り分け

他システムとの情報授受を定義する場合は、システムが提供する接続機能や方式設計に関係します。

どのデータを送受信するか
→ 機能・インタフェースの定義

どの通信方式や技術標準を使うか
→ 非機能要件

同じ「インタフェース」でも、何を定めているかで分類が変わります。

どんな場面で使う？

非機能要件は、システム開発の早い段階で明確にします。

例えば、同じ「注文登録機能」でも、次の条件によって設計は大きく変わります。

1日100件だけ処理する

1秒間に1,000件処理する

また、障害時の許容停止時間が5分なのか、翌日まで復旧すればよいのかでも、必要な設備や費用は変わります。

開発方法でも同じです。

使用言語を自由に選べる

使用言語と開発標準が指定されている

では、設計や開発体制が変わります。

非機能要件が曖昧だと、機能は完成していても、次の問題が起きます。

処理が遅い
利用者が増えると停止する
障害から復旧できない
運用担当者が監視できない
セキュリティが不足する
開発ルールが部門ごとにばらつく
データ移行が予定どおり進まない
利用者が操作方法を理解できない

そのため、測定・確認できる形で定めることが重要です。

速く表示する
→ 曖昧

通常時は2秒以内に表示する
→ 測定可能

よくある誤解・混同

誤解1：非機能要件は重要ではない

「非機能」という言葉から、重要ではない要件だと誤解しやすいですが、そうではありません。

性能や可用性が不足すると、機能が正しくても実用になりません。

誤解2：非機能要件は品質要件だけ

誤りです。

性能や信頼性だけでなく、開発言語、開発標準、運用、移行、教育なども非機能要件に含まれます。

品質
技術上の制約
運用条件
移行条件
付帯作業
→ 非機能要件

誤解3：「警告」「安全」「セキュリティ」が出たら非機能要件

単語だけでは判断できません。

不正な操作を検知したら警告を表示する
→ 「表示する」という具体的な動作
→ 機能要件

一定のセキュリティ水準を満たす
→ 品質・制約の要求
→ 非機能要件

何のための要求かより、何を要求しているかを見るのがポイントです。

誤解4：可用性と機能性は同じ

必要な機能を備えている
→ 機能性

必要なときに停止せず使える
→ 可用性

機能が存在していても、システムが停止していれば利用できません。

誤解5：性能は処理速度だけ

性能には、応答時間だけでなく、処理件数、同時接続数、データ量なども含まれます。

誤解6：開発言語は機能要件

誤りです。

利用者が使う機能ではなく、開発方法を制約する条件なので、技術要件として非機能要件に分類されます。

誤解7：曖昧な表現でも要件になる

「高速」「十分な安全性」「停止しにくい」だけでは評価できません。

数値や条件を付けて、確認できる形にします。

稼働率99.9%以上
障害発生から30分以内に復旧
同時接続1,000人に対応

確認問題（基本情報技術者試験対策）

次のうち、非機能要件に該当するものはどれか。

ア. 在庫が不足している場合に警告メッセージを表示する
イ. 障害発生から2時間以内にサービスを復旧する
ウ. 注文内容を登録して確認画面を表示する
エ. 承認された注文だけを出荷対象として登録する

▶ クリックして答えと解説を見る（ここを開く）

正解：イ

「2時間以内」は、システムの復旧時間という品質水準を定めているため、非機能要件です。

ア：「警告メッセージを表示する」という具体的な動作 → 機能要件
イ：「2時間以内に復旧」という水準 → 非機能要件
ウ：「登録する・表示する」という具体的な動作 → 機能要件
エ：「出荷対象として登録する」という具体的な動作 → 機能要件

この問題では、「表示・登録」のような動作と、「○時間以内」のような品質水準を切り分けるのがポイントです。

まとめ（試験直前用）

何ができるか、何をするか → 機能要件
どの程度の品質で動くか → 非機能要件
「表示・登録・通知」など具体的な動作 → まず機能要件を疑う
「○秒以内・稼働率・復旧時間」など品質水準 → 非機能要件を疑う
開発言語・開発標準などの技術要件 → 非機能要件
運用・監視・バックアップ、移行条件、利用者教育 → 非機能要件
業務の手順・責任・権限 → 業務要件
経営上の目的・成果 → システム化方針

試験中は、次の一文で切り分けます。

動作の内容は機能、動作の品質・水準・制約は非機能。

🔗 関連記事

🏠 基本情報技術者トップに戻る