問2
頻出度★★☆
証券業を営む A 社は, システムベンダの B 社に株式注文システム構築プロジェクトを委託している。当該プロジェクトの運用テストにおいて, A 社が定めている “株式注文時の責任者承認における例外ルール” を B 社が把握できていなかったことに起因する不良を発見した。ルールを明らかにするのはどの段階で行うべきであったか。
平成25年度 秋期 ITパスポート試験 問2
ストラテジ系システム企画 › 要件定義
この問題の解説と、これまでの解答の記録です。
解説
問 2
- ア
正解 正解は ア「業務要件の定義」。問題になっている「株式注文時の責任者承認における例外ルール」は、A 社が自社の業務として定めている運用上の決まりごとであり、システムに何を実装するか以前の「業務のあるべき姿」に属する情報である。共通フレームの流れでは、要件定義は (1) 業務要件の定義 → (2) システム要件の定義 → (3) ソフトウェア要件の定義 の順に上流から下流へ具体化される。業務のルール・体制・例外処理といった内容は最上流の業務要件定義で利用者側 (A 社) が明示し、ベンダ (B 社) と合意しておくべきものであり、ここで抜け落ちたために下流のシステム要件・ソフトウェア要件にも反映されず、最終段階の運用テストで不良として顕在化した。よって、この例外ルールを明らかにすべきだったのは業務要件の定義の段階である。
不正解イ
システムテスト要件の定義は、完成したシステムが要件どおり動くことをどう確認するか (テスト範囲・テストケース・合否基準) を決める工程である。テスト要件は業務要件やシステム要件を入力として作られるので、そもそも業務ルールが明らかになっていなければテスト要件にも現れない。この段階で気付くのは手遅れであり、ルールを「明らかにする」場ではない。
不正解ウ
システム要件の定義は、確定した業務要件を実現するためにシステム全体として備える機能・性能・インタフェースなどを決める工程である。前提となる業務ルールが与えられて初めて成立する下流工程であり、業務側の例外ルールそのものを掘り起こす場ではない。ここで初めて出てくるようでは、上流の業務要件定義での合意漏れである。
不正解エ
ソフトウェア要件の定義は、システム要件をさらに個々のソフトウェアに割り当て、画面・帳票・処理内容・データ構造などを詳細化する、要件定義の中でも最も下流の工程である。業務ルールはこの時点ではすでに確定していることが前提であり、承認の例外ルールという業務上の決まりを新たに明確化する段階としては不適切である。
ここがポイント
- 要件定義は「業務要件の定義 → システム要件の定義 → ソフトウェア要件の定義」と上流から下流へ具体化する。業務のルール・体制・例外処理は最上流の業務要件定義で利用者側が明示し、ベンダと合意する。
- 業務要件定義は発注者 (利用部門) が主体となって担う。ここでの漏れは下流工程すべてに波及し、運用テストなど終盤で不良として発覚するため、手戻りコストが最も大きくなる。
用語