ITパスポート試験 ITパスポート 2013年 (平成25年 秋期) 問2: 証券業を営むA社は,システムベンダのB社に株式注文システム構築プロジェクトを委託している。当該プロジェクトの運用テストにおいて,A社が定めている"株式注文時の責

問題本文

証券業を営むA社は,システムベンダのB社に株式注文システム構築プロジェクトを委託している。当該プロジェクトの運用テストにおいて,A社が定めている"株式注文時の責任者承認における例外ルール"をB社が把握できていなかったことに起因する不良を発見した。ルールを明らかにするのはどの段階で行うべきであったか。

選択肢

• ア.業務要件の定義
• イ.システムテスト要件の定義
• ウ.システム要件の定義
• エ.ソフトウェア要件の定義

正解

ア. 業務要件の定義

解説

業務上の例外ルールなど,業務そのものをどう運営するかを示す要件は,最上流の業務要件定義(business requirements definition)で漏れなく明らかにする必要があります。業務要件定義は新システムによって解決すべき業務上の課題やルール,例外処理を明確化する工程で,これを下流工程で発覚させると手戻りコストが大きくなります。共通フレーム2007以降の枠組みでも,業務要件はシステム要件の前段に位置づけられ,業務側の決まりごとを最初に確定するのが原則です。本問の責任者承認の例外ルールは典型的な業務要件です。

選択肢ごとの解説

• ア.正解。業務要件の定義は業務の目的・遂行ルール・例外処理など業務側の決まりごとを洗い出す段階であり,株式注文の責任者承認の例外ルールはここで明確化すべき。下流で発覚すれば大幅な手戻りとなる典型的な要件漏れの例として頻出する。
• イ.システムテスト要件の定義はテストの方針・合否基準・テスト範囲を決める段階であり,業務ルール自体を初めて定義する場ではない。業務ルールはより上流の業務要件定義で明らかにされている前提で,それを検証するためのテスト要件を設計する段階。
• ウ.システム要件定義は業務要件を受けてシステムが満たすべき機能・性能・インタフェースを定める段階で,業務上のルール自体は前段の業務要件定義で明らかにされている前提。本問の業務側例外ルールはここで初めて出てくる対象ではなく,より上流の話。
• エ.ソフトウェア要件定義はシステム要件をさらにソフトウェア観点で具体化する段階であり,業務上の例外ルールを初めて確定する場ではない。最下流に近い工程で業務ルールの抜けが見つかること自体が本問の問題点であり,そもそも上流で確定すべきだった。