エンベデッドシステムスペシャリスト 2015年 午前2 問20
問題文
共通フレームによれば、システム要件の評価タスクにおいて見極めることはどれか。
選択肢
ア:システム要件とシステム方式との間に一貫性があるかどうか。
イ:システム要件とシステム方式との関連が追跡できるかどうか。
ウ:システム要件を満たすシステム方式設計が実現可能かどうか。(正解)
エ:ソフトウェア品目が割り当てられたシステム要件を満たすかどうか。
🔒 解説は解答すると表示されます
システム要件の評価【午前2解説】
正解の理由
システム要件の評価では、定義されたシステム要件を満たすシステム方式設計が実現可能かどうかを見極めます。
したがって、システム要件を満たすシステム方式設計が実現可能かを問うウが正解です。単に要件と設計の関係を確認するのではなく、要件を実現できる設計になっているかを評価する点が重要です。
解法ステップ
- 問われている対象が「システム要件の評価」であることを確認します。
- 「評価」で見極めるのは、システム要件を満たす方式設計を実現できるかどうかだと整理します。
- 実現可能性を直接述べている選択肢を選びます。
選択肢別の誤答解説
- ア:システム要件とシステム方式との一貫性を確認する内容です。一貫性の確認と、要件を満たす設計が実現可能かどうかの評価は異なります。
- イ:システム要件とシステム方式との関連を追跡できるかを確認する内容です。追跡可能性は、要件と設計の対応関係を管理する観点です。
- ウ:システム要件を満たすシステム方式設計が実現可能かを確認する内容であり、システム要件の評価に該当します。
- エ:ソフトウェア品目が割り当てられたシステム要件を満たすかを確認する内容です。システム全体の方式設計ではなく、ソフトウェア品目の要件充足に焦点があります。
よくある誤解
- 「一貫性があるか」と「要件を満たす設計を実現できるか」を同じ意味だと考えてしまうことがあります。一貫性があっても、実現可能とは限りません。
- 「追跡できるか」は要件と設計の対応関係を確認する観点であり、要件の実現可能性を評価することとは別です。
- 「システム要件」と「ソフトウェア品目に割り当てられた要件」を混同しないようにしましょう。対象となる範囲が異なります。
補足コラム
要件に対する評価では、何を評価対象としているかに注目すると整理しやすくなります。システム要件の評価では、システム方式設計が要件を実現できるかを見ます。一方、ソフトウェア品目に割り当てられた要件については、そのソフトウェア品目が要件を満たすかが評価の焦点になります。
FAQ
Q. 一貫性があるなら、要件を満たせると考えてよいですか?
A. いいえ。一貫性は、要件と方式の間に矛盾がないことを指します。要件を実際に実現できるかどうかは、別途評価が必要です。
A. いいえ。一貫性は、要件と方式の間に矛盾がないことを指します。要件を実際に実現できるかどうかは、別途評価が必要です。
Q. 追跡可能性は何のために確認しますか?
A. 要件が設計などにどのように反映されたかをたどり、対応漏れや変更時の影響を把握するためです。
A. 要件が設計などにどのように反映されたかをたどり、対応漏れや変更時の影響を把握するためです。
関連キーワード: 共通フレーム、システム要件、システム方式設計、実現可能性、要件追跡性

\ せっかくなら /
エンベデッドシステムスペシャリストを
クイズ形式で学習しませんか?
クイズ画面へ遷移する→
すぐに利用可能!

