ITパスポート試験 / 平成26年度 春期 ITパスポート試験 公開問題 / 問26
certification-simodake-work

平成26年度 春期 ITパスポート試験 公開問題 問26 解説 要件定義の検証

ソフトウェアライフサイクルを, 企画, 要件定義, 開発, 運用のプロセスに分け たとき, 要件定義プロセスの段階で確認又は検証するものはどれか。

  1. ア システム要件とソフトウェア要件の一貫性と追跡可能性
  2. イ ソフトウェア要件に関するソフトウェア設計の実現可能性
  3. ウ ユーザや顧客のニーズ及び要望から見た業務要件の妥当性 ✓ 正答
  4. エ 割り振られた要件を満たすソフトウェア品目の実現可能性

解説

正解へのアプローチ

要件定義プロセスの最優先事項は「何を作るか」ではなく「なぜそれを作るのか」という目的の明確化です。ユーザーのニーズと合致しているかを確認する「妥当性」が、このフェーズの役割です。他の選択肢は、要件定義の後の「設計」や「開発」プロセスで行う検証作業を指しています。

ソフトウェアライフサイクルと要件定義の役割

ソフトウェア開発は、ゼロから完成品を作るわけではなく、いくつかの工程に分かれます。この一連の流れをソフトウェアライフサイクル(SLCP)と呼びます。

要件定義は、開発プロセスの初期段階です。ここでは、まだシステムが形になっていない状態で「誰が、何のために、どのようなシステムを求めているか」を定義します。もしこの段階でユーザーのニーズを取り違えてしまうと、後の工程でどれほど高度な技術を駆使して開発しても、完成したシステムは「使えないもの」になってしまいます。そのため、要件定義では、技術的な実現可能性よりも、業務上の目的が正しく捉えられているかという「妥当性」が問われます。

プロセスごとの役割の違い

なぜ他の選択肢が不適切なのか、工程の順序で考えると理解しやすくなります。

・ア:システム要件とソフトウェア要件の一貫性と追跡可能性 これは「システム要件定義」や「ソフトウェア要件定義」の内部で行われる整合性チェックです。要件定義の中でも、より詳細な仕様策定の段階で重要になります。

・イ:ソフトウェア要件に関するソフトウェア設計の実現可能性 これは「設計」プロセスで行うべき検証です。要件が固まった後、それを実際にプログラミング可能な形に落とし込めるかを検討する段階です。

・エ:割り振られた要件を満たすソフトウェア品目の実現可能性 これも「開発・実装」プロセスに近い視点です。設計された機能を実際に部品(モジュール)として作成できるかを確認する段階です。

つまり、選択肢イやエは、要件が確定した後の「技術的な実現」に焦点が当てられています。対して、選択肢ウの「妥当性」は、システムがビジネス上の課題を解決できるかという、プロジェクトの成功を左右する最も上流の確認作業です。

実務で活用する視点

この知識は、実際のシステム開発だけでなく、日常的な業務改善やプロジェクト管理にも応用できます。新しいツールを導入する際、まず考えるべきは「ツールの機能(仕様)」ではなく「そもそも現在のどんな業務負荷を解消したいのか(要件)」です。

「高機能なツールだから」という理由だけで選ぶと、現場の実態に合わず結局使われないという失敗がよく起こります。ITパスポートでこの項目を学ぶ意図は、技術者であっても「道具」そのものを見る前に、まずは「解決すべき本質的な課題」に目を向ける姿勢を養うことにあります。

参考リンク

学習の記録にははてなブックマーク!

気づいたこと・覚えたことをコメントにメモしよう