ソフトウェアライフサイクルを，企画，要件定義，開発，運用のプロセスに区分したとき，要件定義プロセスで明確にする項目はどれか。

エ利害関係者のニーズと要望事項

平成25年度春期 ITパスポート試験公開問題問23 解説要件定義プロセス

要件定義プロセスとは、システム開発の「入り口」にあたります。このプロセスでは、技術的な設計に入る前に「誰が何のためにシステムを欲しがっているのか」を整理する必要があります。したがって、正解は利害関係者のニーズと要望事項を明確にするという点です。

システム開発は、家を建てる手順に似ています。いきなり設計図（開発プロセス）を書くのではなく、どのような家が必要かを話し合う段階が必要です。

企画プロセスでは、そもそもシステムを作る必要があるのか、予算はいくらか、どのような目的で投資するのかといった経営的な判断を行います。

要件定義プロセスでは、システムを使う人（顧客やエンドユーザー）が具体的にどのような機能を求めているのか、どのような課題を解決したいのかを聞き出し、文書にまとめます。

開発（設計・プログラミング）プロセスでは、要件定義で決まった内容に基づき、具体的なデータベースの構造や、機能の能力（レスポンスタイムなど）、詳細な画面仕様などを詰め、実際にプログラムを作成します。

運用プロセスでは、完成したシステムを現場で稼働させ、保守や改善を行います。

選択肢を「どのプロセスで行うべきか」という視点で分類すると、正解が見えてきます。

アの「システムを開発する目的」は、プロジェクトを開始する前の企画プロセスで行うべき事柄です。そもそも目的が曖昧なままでは、要件定義を始めることすらできません。

イの「ソフトウェア構成品目ごとの機能と能力」や、ウの「データベースの構造」は、要件定義で決めた「何を実現したいか」という要望を、技術的に「どう実現するか」に落とし込む開発プロセスの詳細設計フェーズで行う作業です。

このように、上流工程（企画・要件定義）から下流工程（開発・運用）へと、抽象的な事柄が徐々に具体的な設計に変わっていくのがシステム開発の基本構造です。

ITパスポート試験でこの範囲が出題される背景には、多くのシステム開発プロジェクトが「要件定義の不備」によって失敗するという現実があります。

現場では「利害関係者（ステークホルダー）の要望」を正しく聞き出せないまま開発を進め、後から「思っていたものと違う」とやり直しが発生するケースが非常に多いのです。この知識は、単なる暗記項目ではなく、プロジェクトが成功するために最も重要な「コミュニケーションのゴール」を理解しているかを問うものです。

実際にシステム開発の現場では、この要件定義書が、顧客と開発側の間で「これで間違いないですね」と合意をとるための重要な契約的意味合いを持つ書類となります。ここがブレると、後の工程でどれだけ高度な技術を使っても、プロジェクトの成功は望めません。