ITパスポート 2016年春期問55

問題文

情報システムの要件は、業務要件を実現するための機能を記述した機能要件と、性能や保守のしやすさなどについて記述した非機能要件に分類することができる。機能要件に該当するものはどれか。

🖊️ 解答を隠して解いてみる

ア：システムが取り扱う入出力データの種類（正解）

イ：システム障害発生時の許容復旧時間

ウ：システムの移行手順

エ：目標とするシステムの品質と開発コスト

🔒 解説は解答すると表示されます

選択肢の中で「システムが取り扱う入出力データの種類」は、システムが何を扱い、どんな処理を行うかを直接示すため、機能要件に該当します。機能要件とは「システムが何をするか」を記述する要件です。したがって、正答はアです。

（補足）機能要件＝「何をするか」。非機能要件＝「どうあるべきか（性能・品質・運用・制約など）」。この違いを常に意識してください。

短くまとめると、「〇〇を扱う（入力・出力・計算・表示）」なら機能要件。
「速度、可用性、保守、コスト、手順・運用」などは非機能要件（または運用/プロジェクト要件）です。

ア: システムが取り扱う入出力データの種類
- 解説：データの種類（例：顧客名、注文番号、金額）は「システムが何を扱うか」を示します。よって機能要件です。
イ: システム障害発生時の許容復旧時間
- 解説：「許容復旧時間」は可用性や復旧に関する性能・運用上の条件です。英語では Recovery Time Objective（RTO：復旧までに許容される時間）と呼ばれ、非機能要件に分類されます。
ウ: システムの移行手順
- 解説：移行手順は「どのように導入・切替えを行うか」という運用やプロジェクト計画上の文書です。要件定義上は運用要件や導入計画に近く、機能（システムが提供する機能）そのものではありません。従って機能要件ではありません。
エ: 目標とするシステムの品質と開発コスト
- 解説：品質（性能、信頼性、保守性など）はまさに非機能要件に含まれます。開発コストはプロジェクトの制約（ビジネス要件・予算）で、機能要件には該当しません。

「移行手順は機能だ」と思うミス
- 理由：移行手順はユーザーが使う機能ではなく、導入・運用の方法です。要件文書では運用要件や導入計画に書きます。
「品質やコストも機能に入る」と混同する
- 理由：機能は「できること」ですが、品質やコストは「どれくらいの性能・条件で」「どのくらいの費用で」実現するかという条件・制約です。分類を明確にすることが重要です。
「データの扱い＝ただの属性で重要でない」と見落とす
- 理由：入出力データは業務を実現する中心的要素です。どのデータを扱うかが不明確だと機能設計やテストができません。

覚え方のコツ：

機能要件（Functional Requirements）＝「What（何をするか）」。例：ログイン機能、注文登録、帳票出力。
非機能要件（Non-Functional Requirements）＝「How well／Constraints（どのように・どんな制約で）」。例：応答時間2秒以内、可用性99.9%、バックアップ方式、保守しやすさ。

業務要件（ビジネス上の要望）→ 機能要件（システムで実現する具体的な機能）→ 非機能要件（品質や運用の条件）という流れで要件定義を進めると整理しやすいです。要件定義書では「入出力データの一覧」を作ることが基本作業の一つです。

例：

Q1. 「画面レイアウトは機能要件ですか？」
A1. 画面レイアウト（どの項目を表示するか）は機能要件に近いです。ただし詳細なレイアウトは設計段階の成果物になります。要件段階では「顧客名・注文番号を表示する」といったレベルで書きます。

Q2. 「開発スケジュールはどちらに入りますか？」
A2. スケジュールはプロジェクト管理上の計画で、要件定義の対象ではなくプロジェクト要件／計画に含まれます。

Q3. 「性能（応答速度）はどの段階で決めるべきですか？」
A3. 早い段階で（要件定義フェーズ）決めるべきです。非機能要件として明記しないと、設計で性能不足が発覚して手戻りになります。

関連キーワード: 要件定義、機能要件、非機能要件、入出力データ、可用性、復旧時間（RTO）、運用要件、品質要件、要件分類

\ せっかくなら /

ITパスポートを
クイズ形式で学習しませんか？

すぐに利用可能！