情報セキュリティマネジメント 2017年 春期 午前（科目A） 問49
問題文
受注管理システムにおける要件のうち、非機能要件に該当するものはどれか。
選択肢
ア：顧客から注文を受け付けるとき、与信残金額を計算し、結果がマイナスになった場合は、入力画面に警告メッセージを表示できること
イ：受注管理システムの稼働率を決められた水準に維持するために、障害発生時は半日以内に回復できること（正解）
ウ：受注を処理するとき、在庫切れの商品であることが分かるように担当者に警告メッセージを出力できること
エ：商品の出荷は、顧客から受けた注文情報を受注担当者がシステムに入力し、営業管理者が受注承認入力を行ったものに限ること
🔒 解説は解答すると表示されます
非機能要件【情報セキュリティマネジメント解説】
正解の理由
選択肢のうち、システムに「どのような機能を持つか」ではなく「どのような品質や運用レベルを満たすか」を表しているのが、イの「障害発生時は半日以内に回復できること」です。これは可用性（稼働率）や復旧時間に関する要求で、性能・信頼性・運用性といった非機能要件（品質要件）に該当します。
具体的には、イはRTO（Recovery Time Objective：目標復旧時間）という形式で表される要件です。RTOは「障害発生からどの程度までなら業務を停止してよいか」という目標値です。これに対し、MTTR（Mean Time To Repair：平均修復時間）は実際にかかった修復時間を平均した実績値で、RTO（目標）とは概念が異なります。RTOは設計・契約で決める目標、MTTRは運用で計測する指標だと覚えてください。
解法ステップ
- 要件が「何をするか（What）」を示しているか、「どのようにあるべきか（How well / Quality）」を示しているかを見分ける。
- 「○○できる」や「入力画面に表示する」などは機能（Functional）。
- 「稼働率」「半日以内に回復」などは品質・運用（Non-functional）。
- 選択肢ごとに、対象が具体的な動作か品質かを当てはめる。
- 品質なら非機能要件と判断する。
具体適用例：
- ア・ウ・エ：業務上の振る舞いや承認フロー、画面出力といった「何をするか」を定義 → 機能要件
- イ：復旧時間という「どの程度の可用性を保つか」を定義 → 非機能要件
選択肢別の誤答解説
- ア: 顧客注文時に与信残金額を計算し、結果を画面に表示するという具体的な処理（ビジネスロジック＋UI）です。機能要件に該当します。
- イ: 障害時の復旧時間目標を示すため、非機能要件です（RTOの記述）。
- ウ: 在庫切れを知らせる警告メッセージの出力は、業務処理の一部（機能）です。
- エ: 出荷の承認フローを限定するのは業務ルール（ビジネスプロセス）で、やはり機能要件（業務制約）に含まれます。
よくある誤解
- RTOとMTTRを同じものと考える
- RTO（Recovery Time Objective：目標復旧時間）は「目標」。MTTR（Mean Time To Repair：平均修復時間）は「実績の平均」。要件ではRTOを指定し、運用でMTTRを改善・計測します。
- 「表示する」「警告する」などユーザーへのメッセージは非機能だと思い込む
- 表示やメッセージ出力はユーザーへの具体的な動作で、通常は機能要件です。見た目（可用性や応答性）に関する条件が付く場合のみ非機能になることがあります。
- 業務ルール（承認フロー）は非機能だと誤解する
- 業務フローや承認制御は「業務機能」の定義に該当します。運用手順や責任分担の指定は非機能に近いが、フロー自体は機能要件として扱います。
補足コラム
非機能要件の代表例と職場での扱い方（短く）
- 可用性（Availability）：システムが使える割合や復旧時間（例：稼働率99.9%、RTO＝4時間）。SLA（Service Level Agreement：サービス水準合意）に明記し、監視と定期テストで検証します。
- 性能（Performance）：応答時間や処理スループット。負荷試験で確認します。
- 保守性（Maintainability）：修正やアップデートのしやすさ。保守担当や手順を決めます。
- セキュリティ：認証、アクセス制御、ログ管理など。攻撃に対する耐性や監査要件を定めます。
職場イメージ：イのような非機能要件は、SLAや運用設計書、災害復旧（DR）計画に落とし込みます。担当者（運用チーム・ベンダー）は定期的に復旧テストを行い、MTTRを計測してRTOを満たすか確認します。
FAQ
Q1: 「半日」とだけ書いてある要件は有効ですか？
A1: あいまいです。設計・運用で誤解が生じないように、時間は「8時間以内」など具体的にし、計測開始点（障害検知時／障害発生日など）も明記してください。
A1: あいまいです。設計・運用で誤解が生じないように、時間は「8時間以内」など具体的にし、計測開始点（障害検知時／障害発生日など）も明記してください。
Q2: RTOはどうやって検証しますか？
A2: 災害復旧訓練やフェイルオーバーテストで実際に復旧作業を行い、所要時間を計測します。これにより実績（MTTR）を得て、RTO達成を確認します。
A2: 災害復旧訓練やフェイルオーバーテストで実際に復旧作業を行い、所要時間を計測します。これにより実績（MTTR）を得て、RTO達成を確認します。
Q3: 要件が機能と非機能を混ぜている場合は？
A3: 分離して書きます。例えば「自動でバックアップを取る（機能）」と「バックアップからの復旧を2時間以内に完了する（非機能/RTO）」のように、目的と品質を分けるとテストや契約で扱いやすくなります。
A3: 分離して書きます。例えば「自動でバックアップを取る（機能）」と「バックアップからの復旧を2時間以内に完了する（非機能/RTO）」のように、目的と品質を分けるとテストや契約で扱いやすくなります。
関連キーワード: 非機能要件、可用性、RTO（Recovery Time Objective：目標復旧時間）、MTTR（Mean Time To Repair：平均修復時間）、SLA、運用設計、復旧試験
\ せっかくなら /
情報セキュリティマネジメントを
クイズ形式で学習しませんか？
クイズ画面へ遷移する→
すぐに利用可能！