ITパスポート 2014年 春期 問43

システム要件の評価基準【ITパスポート 解説】

正解の理由

• 要件定義は「正しいものを作るか（妥当性）」を決める作業です。
• 発注者のニーズとの整合性を確認することは、要件が“本当に必要なもの”かを検証する行為です。 そのため、要件の評価基準として最も適切なのは イ です。

• 要件（requirement）：システムに求められる機能や性能などの条件。
• 発注者のニーズ：業務上の目的や問題、欲しい機能など利用者側の要求。
• バリデーション（Validation：妥当性確認）＝「正しいシステムを作っているか（利用者のニーズに合っているか）」を確かめること。
• ベリフィケーション（Verification：検証）＝「仕様どおりに作っているか」を確かめること。

解法ステップ

1. 問題文を読む：「システム要件を評価する基準」とあるので、要件を評価（良し悪しを判断）する基準を選ぶ必要があると理解する。
2. 「要件の目的」を思い出す：要件は「何を作るべきか」を示す。評価は「それが目的（ニーズ）を満たすか」を確認すること。
3. 選択肢と照らし合わせる：
   • 発注者のニーズとの整合性は「つくるものが目的に合っているか」を直接判断できる → 適切。
   • 他の選択肢は設計やテストの観点であり、要件評価の主要基準ではない → 不適切。
4. 結論：発注者のニーズとの整合性（イ）を選ぶ。

選択肢別の誤答解説

• ア: システム結合テストの結果との整合性
  システム結合テストは複数のモジュールやサブシステムをつなげて動きを確認するテストです。これは要件が実装されているか（ベリフィケーション）や、結合に問題がないかを確認する段階の話であり、要件そのものが発注者のニーズに合っているかを評価する基準ではありません。
• イ: システムの発注者のニーズとの整合性
  正解。要件評価の核心は「それが利用者の目的を満たすかどうか」であり、発注者のニーズとの一致を見ます。要件が具体的で測定可能であれば、発注者が満足するかどうかを判断しやすくなります。
• ウ: 使用する設計手法の適切性
  設計手法（たとえばオブジェクト指向設計やウォーターフォール開発など）は実装・設計のやり方に関する判断です。要件の善し悪し（ニーズを満たすか）を直接評価する項目ではありません。設計手法は要件を満たすための手段です。
• エ: テストケースの網羅性
  テストケースの網羅性は品質保証やテスト設計の基準です。要件が正しいかどうか（発注者のニーズに合っているか）を見るには使えません。網羅性は「作ったものをきちんと検査できるか」を示す指標です。

よくある誤解

1. 「テストでうまく動けば要件は正しい」と考える誤解
   テストで動作することは「仕様どおりに作られている（ベリフィケーション）」ことを示しますが、発注者の本当に求めている機能かどうか（バリデーション）は別問題です。動いてもニーズを満たしていないと意味がありません。
2. 「設計手法が正しければ要件も正しい」と混同する誤解
   良い設計手法は実装を効率化しますが、最初の要件が間違っていればどんな手法でも目的を達成できません。要件の評価は、手法とは独立して行うべきです。
3. 「網羅的なテストケースがあれば評価済み」と考える誤解
   テスト網羅性は検証の質を上げますが、評価の基準そのもの（要件が妥当か）を示す指標ではありません。

補足コラム

• 明確性（曖昧な表現がないか）
• 一貫性（互いに矛盾する要件がないか）
• 完全性（必要な要件が漏れていないか）
• 実現可能性（現実的に実装可能か）
• 検証可能性（要件がテストやレビューで確認できるか）
  これらは「要件が発注者のニーズに合っているか」を判断する際の補助となります。特に「検証可能性」は、要件をニーズに照らして確認する際に重要です。

• 発注者（利用者）に「受け入れ基準（受入条件）」を明確にしてもらうと、ニーズとの整合性を評価しやすくなります。受入基準は「これが満たされれば受け取る」という具体的な条件です。
• 要件定義の段階で、ユーザーストーリーや業務フロー図を使うと、ニーズとの整合性を視覚的に確認できます。

FAQ