要件定義とは？

要件定義の意味

利用者や発注者が業務上何を実現したいか（業務要件・機能要件・非機能要件）を明らかにし、システムに求められる要件として文書化する工程。システム化計画を受けて開発プロセスの最上流で行われ、この段階のずれが手戻りの大きな原因になる。

要件定義の具体例

「受発注業務を自動化したい」という依頼をもとに業務担当者へのヒアリングを重ね、「在庫が10個を切ったら自動的にアラートを出す」といった機能要件と、必要な入出力データ・処理内容・応答時間や可用性などの非機能要件を要件定義書としてまとめる。

要件定義は試験でどう引っ掛けられる？

決めるのは利用者（発注者）側が「何を求めるか」であって、どう実現するか（設計）ではない。ベンダー任せにしてよい工程でもない。業務要件・機能要件・非機能要件の区別も頻出で、性能・可用性・セキュリティは非機能要件。要件定義の不備は下流工程での手戻りにつながり、修正コストは工程が進むほど大きくなる。

要件定義と関連する用語

• 業務要件・機能要件・非機能要件
• 外部設計（概要設計）
• ウォーターフォールモデル

要件定義が出た過去問

• 要件定義プロセスに含まれる作業はどれか。

  正解：システム利用者のニーズの整理

  要点：要件定義は利用者のニーズを整理し要求としてまとめる工程

  要件定義プロセスは、システムに何を求めるかを明らかにする工程であり、利用者や関係者のニーズを収集・整理して合意することが中心となる。これより前の企画プロセスで投資対効果の検討やシステム化計画の策定を行い、これより後の開発プロセスで設計を進めるという位置付けである。

  出典：平成21年度 秋期 ITパスポート試験 問19（IPA）

• 現行システムの使用を開始してから10年が経過し、その間に業務内容も変化してきた。そこで、全面的に現行システムを開発し直すことになった。開発者が、システム要求の分…

  正解：システム要件は、システム利用部門と共同でレビューを行う。

  要点：要件は利用部門と共同レビューし合意して確定する

  要件定義では、実際に業務を担う利用部門の要求を正しく反映できているかが成否を分ける。そのため開発者が一方的に決めるのではなく、まとめた要件を利用部門と一緒にレビューし、認識の食い違いを早い段階で解消して合意を得る進め方が適切である。現行の操作手順をそのまま踏襲すると、変化した業務に合わないシステムになりかねない。

  出典：平成21年度 秋期 ITパスポート試験 問29（IPA）

• あるシステムの開発において、システムを24時間連続稼働させることになった。稼働時間について利用部門と取決めを行う工程はどれか。

  正解：システム要件定義

  要点：稼働時間などの要件はシステム要件定義で利用部門と合意

  稼働時間や応答性能、可用性といった、システムが満たすべき条件は、開発に入る前のシステム要件定義で利用部門と合意しておく必要がある。後工程の設計やテストは、この段階で定めた要件を実現し検証する工程であり、要件そのものを取り決める場ではない。

  出典：平成21年度 秋期 ITパスポート試験 問32（IPA）

• ソフトウェア要件として明確に規定すべきものはどれか。

  正解：データ定義

  要点：ソフトウェア要件では機能とともにデータ定義を明確化する

  ソフトウェア要件定義では、そのソフトウェアが備えるべき機能や、扱うデータの項目・意味・関連といったデータ定義を明確にする。抽象的な目標や、実装方法にあたる内部設計、開発環境の仕様は、それぞれ別の工程で扱う事柄である。

  出典：平成21年度 秋期 ITパスポート試験 問37（IPA）

• システム開発における要件定義プロセスを説明したものはどれか。

  正解：新たに構築する業務、システムの仕様、及びシステム化の範囲と機能を明確にし、それらをシステム取得者側の利害関係者間で合意する。

  要点：要件定義は必要な機能と範囲を決め関係者間で合意する工程

  要件定義プロセスは、企画で定めた方針を受けて、新しい業務の姿やシステムに求める機能・性能、システム化の範囲を具体化し、それを利用部門や経営層など取得者側の利害関係者の間で合意する工程である。方針と実現計画の策定は企画プロセス、方式設計や構築は開発プロセス、要件どおりかの確認はテストにあたる。

  出典：平成21年度 春期 ITパスポート試験 問25（IPA）