問23
頻出度★★☆
ソフトウェアライフサイクルを, 企画, 要件定義, 開発, 運用のプロセスに区分したとき, 要件定義プロセスで明確にする項目はどれか。
平成25年度 春期 ITパスポート試験 問23
ストラテジ系システム企画 › 要件定義
この問題の解説と、これまでの解答の記録です。
解説
問 23
不正解ア
「システムを開発する目的」を明確にするのは、要件定義プロセスの前段にある企画プロセスである。企画プロセスでは、経営上の課題やニーズを踏まえてシステム化の構想・計画を立て、何のためにシステムをつくるのかという目的や適用範囲、投資対効果、全体スケジュールなどを定める。要件定義プロセスは、そこで定まった目的を出発点として、利害関係者の具体的な要求事項を洗い出す段階なので、目的そのものは要件定義で初めて決める項目ではない。
不正解イ
「ソフトウェア構成品目ごとの機能と能力」を明確にするのは、要件定義プロセスの後にくる開発プロセス (ソフトウェア要件定義・ソフトウェア方式設計) である。構成品目という単位はシステムを実現する側の分割であり、利用者側の要望を技術的な単位に割り付けた結果として初めて決まる。要件定義プロセスの段階では、まだ製品をどのような部品に分けて実装するかは定まっていないので、この項目は要件定義の成果物にはならない。
不正解ウ
「データベースの構造」は、開発プロセスの中の設計工程 (ソフトウェア詳細設計・データベース設計) で決める内部仕様である。どのようなテーブルや項目でデータを保持するかは実装方式の選択であり、利害関係者が求めるのは「どんな情報を扱いたいか」という業務上の要求までである。要件定義プロセスでこうした内部構造まで決めてしまうと、実現手段を先に固定することになり、要求を明確にするという本来の目的から外れてしまう。
- エ
正解 正解はエ「利害関係者のニーズと要望事項」。共通フレームでは、ソフトウェアライフサイクルを 企画 → 要件定義 → 開発 → 運用 の順に区分する。このうち要件定義プロセスは、企画プロセスで定めたシステム化の狙いを受けて、そのシステムに関わる利害関係者 (ステークホルダ = 経営者、業務部門の利用者、運用担当者、取引先など) が何を必要とし何を望んでいるのかを漏れなく識別し、業務要件として整理したうえで、関係者間で合意を得る段階である。つまり「どう作るか」ではなく「使う側にとって何が必要か」を確定させるのが要件定義プロセスの役割であり、明確にする項目は利害関係者のニーズと要望事項になる。ここで合意された要求事項が、後続の開発プロセスでシステム要件・ソフトウェア要件へと具体化されていく。
ここがポイント
- 共通フレームのソフトウェアライフサイクルは 企画 → 要件定義 → 開発 → 運用 (保守) の順に進む。企画プロセスは「なぜつくるか」(経営上のニーズ、システム化の目的・構想・計画)、要件定義プロセスは「使う側にとって何が必要か」(利害関係者のニーズと要望事項の識別、業務要件定義、要件の合意)、開発プロセスは「どうつくるか」(システム要件定義・方式設計、ソフトウェア要件定義・詳細設計、実装、テスト)、運用プロセスは「どう使い続けるか」を担当する。
- 要件定義プロセスの中心は利害関係者 (ステークホルダ) の識別と要求事項の合意である。経営者・利用部門・運用担当者・取引先など立場の異なる関係者の要望を漏れなく引き出し、相反する要望は調整して合意文書にまとめる。ここで要求が曖昧なまま開発に進むと、後工程での手戻りが大きくなるため、実現手段 (構成品目、データベース構造など) は持ち込まず、あくまで「何が必要か」に絞って明確化する点が要点である。
用語