問26
頻出度★★☆
ソフトウェアライフサイクルを, 企画, 要件定義, 開発, 運用のプロセスに分けたとき, 要件定義プロセスの段階で確認又は検証するものはどれか。
平成26年度 春期 ITパスポート試験 問26
ストラテジ系システム企画 › 要件定義
この問題の解説と、これまでの解答の記録です。
解説
問 26
不正解ア
「システム要件とソフトウェア要件の一貫性と追跡可能性」は、開発プロセスの中で行う確認である。開発プロセスでは、まずシステム要件を定義し、それをハードウェア・ソフトウェア・手作業などに割り振ってソフトウェア要件を定義する。その際に、上位のシステム要件が漏れなく下位のソフトウェア要件に反映され、どのソフトウェア要件がどのシステム要件に対応するのかを追跡できるかを検証する。要件定義プロセスの段階ではシステム要件もソフトウェア要件もまだ作られていないので、確認しようがない。
不正解イ
「ソフトウェア要件に関するソフトウェア設計の実現可能性」は、開発プロセスのソフトウェア設計 (方式設計・詳細設計) の段階で行う確認である。決まったソフトウェア要件に対して、その設計で本当に実現できるか、性能や制約を満たせるかを検証する作業であり、業務要件を固める要件定義プロセスよりずっと後の話である。
- ウ
正解 ソフトウェアライフサイクルを「企画 → 要件定義 → 開発 → 運用」と並べたとき、要件定義プロセスは、企画プロセスで決めたシステム化の方針を受けて、利用者や顧客が業務上何を実現したいのかを引き出し、それを『業務要件』としてまとめ、関係者間で合意する段階である。この段階ではまだシステムの中身 (システム要件・ソフトウェア要件・設計) は決まっておらず、確認・検証すべきなのは「定義した業務要件が、本当にユーザや顧客のニーズ及び要望に合っているか」という妥当性 (バリデーション) である。ここで要件を取り違えると、後工程でいくら正確に作っても『欲しかったものと違う』システムになり、手戻りのコストが最も大きくなる。したがって、要件定義プロセスの段階で確認又は検証するものとして正しいのは「ウ ユーザや顧客のニーズ及び要望から見た業務要件の妥当性」である。
不正解エ
「割り振られた要件を満たすソフトウェア品目の実現可能性」も開発プロセスの確認事項である。『割り振られた要件』という言い方自体が、システム要件をソフトウェアなどの構成要素へ配分し終えた後であることを示しており、その配分結果でソフトウェア品目 (作るソフトウェアの単位) が実現できるかを見る検証である。ユーザや顧客の要望と業務要件を突き合わせる要件定義プロセスの確認内容ではない。
ここがポイント
- 共通フレームのソフトウェアライフサイクルでは、企画プロセス (システム化構想・計画) → 要件定義プロセス (業務要件の定義と合意) → 開発プロセス (システム要件定義・ソフトウェア要件定義・設計・実装・テスト) → 運用プロセス の順に進む。どのプロセスで何を確認するかは、その時点で存在する成果物が何かで判断できる。
- 要件定義プロセスで確認・検証するのは『業務要件がユーザや顧客のニーズ及び要望に照らして妥当か』という妥当性確認 (バリデーション)。システム要件・ソフトウェア要件・設計を対象にした一貫性/追跡可能性/実現可能性の検証は、すべて開発プロセスに属する。
用語