問43
頻出度★★☆
システム要件定義において, システム要件を評価する基準として, 適切なものはどれか。
平成26年度 春期 ITパスポート試験 問43
ストラテジ系システム企画 › 要件定義
この問題の解説と、これまでの解答の記録です。
解説
問 43
不正解ア
システム結合テストは、要件定義・設計・プログラミングを経て作られたモジュールを組み合わせ、システムとして正しく動くかを確認する下流の工程である。要件定義を行う時点ではまだ実施されておらず結果も存在しないので、要件を評価する基準にはなり得ない。むしろ関係は逆で、システム要件が先にあり、それを満たしているかを後から確かめるのがテストの側である。
- イ
正解 正解はイ「システムの発注者のニーズとの整合性」。システム要件定義は、システム開発ライフサイクルの最も上流にあたる工程で、発注者や利用部門など利害関係者が業務上何を実現したいのかを引き出し、システムが備えるべき機能・性能・制約として整理し、最後に発注者と合意する作業である。ここで作られる要件は、以降の設計・プログラミング・テストすべての出発点になるため、要件そのものの良し悪しを測れるものさしは「後工程の成果物」ではなく「その要件の源である発注者のニーズ」しかない。発注者が本当に必要としていることと食い違った要件のまま先に進めば、設計もプログラムもテストも技術的には正しく作られたのに、完成したシステムが業務で使えないという最悪の手戻りになる。しかも要件の誤りは下流工程に進むほど修正コストが大きくなるため、要件定義の段階で発注者と内容を突き合わせ、抜け漏れや解釈違いがないかを確認して合意しておくことが重要である。したがって、システム要件を評価する基準として適切なのは発注者のニーズとの整合性であり、イが正しい。
不正解ウ
設計手法が適切かどうかは、要件を「どう実現するか」を決めるシステム設計工程での評価観点である。要件定義で決めるのは「何を実現するか」であり、実現方法を規定する段階ではない。設計手法がどれほど優れていても、元の要件が発注者のニーズと食い違っていれば意味がないため、要件そのものを評価する基準としては不適切である。
不正解エ
テストケースの網羅性は、テスト計画・テスト設計の品質を測る観点であり、テストすべき条件をどれだけ漏れなく洗い出せているかを表す。評価している対象がテストの十分性であって要件の妥当性ではない。加えてテストケースは確定した要件をもとに作るものなので、要件定義の段階でその網羅性を要件の判断基準にすることはできない。
ここがポイント
- システム要件定義は「何を実現するか」を決める最上流工程であり、発注者・利用部門など利害関係者のニーズを引き出して要件としてまとめ、発注者と合意する (要件の合意) ことがゴール。要件の妥当性を測る基準は発注者のニーズとの整合性である。
- 工程ごとに評価の観点が異なる点を区別する。要件定義=ニーズとの整合性、設計=実現方法や設計手法の適切性、テスト=テストケースの網羅性やテスト結果。上流の誤りは下流ほど修正コストが大きくなるため、要件定義段階での発注者との確認・合意が重要になる。
用語