最終更新日：2026年8月8日
fe system-development requirements-definition non-functional-requirements
まず結論
機能要件は、システムに「何をさせるか」を決める要件です。
一方、非機能要件は、その機能を「どのような品質・条件で実現するか」を決める要件です。
基本情報技術者試験では、次の切り分けが特に重要です。
- 「どんな処理をするか」→ 機能要件
- 「性能・品質・セキュリティ・運用など」→ 非機能要件
さらに上位には、そもそも業務として何を実現したいのかを示す 業務要件 があります。
直感的な説明
たとえば、会社で「商品の注文を受け付けるシステム」を作るとします。
このとき、
顧客が商品を選び、注文できるようにする
というのは 機能要件 です。
一方で、
100人が同時にアクセスしても、3秒以内に画面を表示する
というのは 非機能要件 です。
つまり、
何ができるか が機能要件
どのくらい良く・安全に・安定してできるか が非機能要件
と考えると整理しやすくなります。
定義・仕組み
要求を大きく分けると、次の3段階で考えると分かりやすいです。
業務要件
業務として「何を実現したいか」を定めます。
例：
- 注文処理を効率化したい
- 在庫切れを減らしたい
- 顧客対応を迅速にしたい
機能要件
業務要件を実現するために、システムに必要な機能を定めます。
例：
- 注文を登録する
- 在庫数を表示する
- 売上データを検索する
- 顧客情報を更新する
非機能要件
機能以外の品質や制約条件を定めます。
代表例は次のとおりです。
- 性能：応答時間、処理件数
- 可用性：稼働率、停止時間
- セキュリティ：認証、アクセス制御
- 運用：バックアップ、監視、障害対応
- 保守性：変更や修正のしやすさ
- 技術条件：使用するOS、データベース、開発環境など
試験では、問題文に「品質」「技術」「運用」といった言葉が出てきたら、まず非機能要件を疑うとよいでしょう。
どんな場面で使う？
要件定義では、利用者や業務部門から「こういうシステムが欲しい」という要求を整理していきます。
このとき機能だけを決めても、十分なシステムにはなりません。
たとえば注文機能が存在していても、
- 画面表示に30秒かかる
- 障害ですぐ止まる
- 誰でも顧客情報を閲覧できる
という状態では、実務では使いにくいシステムです。
そのため、
機能要件で「できること」を決め、非機能要件で「使える品質」を決める
という考え方が重要です。
よくある誤解・混同
「業務で必要なこと」は全部機能要件？
そうとは限りません。
「受注を登録できるようにする」は機能要件ですが、
「受注画面を2秒以内で表示する」は非機能要件です。
同じ業務に関係していても、処理そのものなのか、品質・条件なのかで切り分けます。
「品質要件」は機能要件？
非機能要件です。
基本情報技術者試験では、
- 品質
- 性能
- 信頼性
- セキュリティ
- 運用
- 技術条件
といったキーワードは、非機能要件を判断する手掛かりになります。
「パッケージ製品が使えるか確認する」は非機能要件？
パッケージの適合性確認は、導入製品を評価する作業です。
「非機能要件を定義すること」そのものとは異なるため、選択肢では切り分けて考えます。
まとめ（試験直前用）
試験では、次の3段階で整理すると迷いにくくなります。
- 業務で何を実現したい？ → 業務要件
- システムに何をさせる？ → 機能要件
- どの品質・条件で実現する？ → 非機能要件
特に、
品質・性能・セキュリティ・運用・技術条件
が出てきたら、非機能要件を第一候補にします。
今回のような問題では、
「業務要件の実現に必要な品質要件・技術要件・運用要件を明確にする」
という記述が、非機能要件定義に当たります。