問33
頻出度★★☆
次の記述のうち, 業務要件定義が曖昧なことが原因で起こり得る問題だけを全て挙げたものはどれか。 a 企画プロセスでシステム化構想がまとまらず, システム化の承認を得られない。 b コーディングのミスによって, システムが意図したものと違う動作をする。 c システムの開発中に仕様変更による手戻りが頻発する。 d システムを受け入れるための適切な受入れテストを設計できない。
令和6年度 ITパスポート試験 問33
ストラテジ系システム企画 › 要件定義
この問題の解説と、これまでの解答の記録です。
解説
問 33
不正解ア
a, b の組合せ。a は企画プロセスでシステム化構想がまとまらない問題だが、企画は業務要件定義より前の工程であり、要件定義の曖昧さが原因ではない。b はコーディングのミスという実装段階の不具合で、要件とは無関係。両方とも該当しないため誤り。
不正解イ
b, c の組合せ。c は要件の曖昧さが原因で正しいが、b はコーディングのミスによる動作不良であり、要件定義ではなくプログラミング工程の問題。該当しない b を含むため誤り。
不正解ウ
b, d の組合せ。d は要件の曖昧さが原因で正しいが、b はコーディングのミスという実装上の不具合で要件定義とは無関係。該当しない b を含むため誤り。
- エ
正解 正解は エ (c, d)。業務要件定義とは、業務側が「新システムにどんな業務・機能を実現してほしいか」を明確に定義する工程で、その後の設計・開発・テストすべての土台になる。c は、要件が曖昧だと仕様が固まらず、開発中に「やはりこうしてほしい」という仕様変更が後から多発し、作り直し (手戻り) が頻発する典型例なので原因に該当する。d の受入れテストは「要件どおりにできているか」を業務側が検証する作業なので、そもそも要件が曖昧だと合否を判定する基準を決められず、適切なテストを設計できない。よって業務要件定義の曖昧さが直接の原因となる問題は c と d だけであり、両方を過不足なく挙げた エ が正しい。
ここがポイント
- 業務要件定義は「業務側が必要とする機能・業務を明確化する工程」で、要件が曖昧だと下流の仕様変更による手戻りを招く。
- 受入れテストは要件に対する検証なので、要件が曖昧だと合否基準を定義できずテスト設計が破綻する。企画プロセスやコーディングのミスは別工程の問題で切り分ける。
用語