要件定義とは？基本情報技術者試験の重要用語解説！

更新日：2021年4月26日

システムを作り上げる上では、「何を作るか」を明確化する工程が大切となります。要件定義工程では、システム開発の最上流工程として「何を作るか」を発注者と受注者間で合意することが最大の目的となります。

要件定義工程でシステム像を明確化することで、後工程での手戻りを最小限とすることができるため、要件定義について理解することは良いシステムを作るための近道となります。

この記事では、基本情報技術者試験で問われる要件定義のポイントについて解説を行います。

要件定義とは
要件定義で行うこと
業務のモデル化手法
まとめ

要件定義とは

要件定義とは、発注者の要求を整理し、ドキュメント化する作業を指します。要件定義工程は、システム開発のスタート地点であり、重要ポイントでもあります。要件定義で決定した内容は、基本的にそれ以降の工程では変更しないため、要件定義のタイミングで作り上げるべきシステムについて明確にする必要があります。

要件定義では、発注者の求めているシステムを明らかにするために、モデル化手法などを用いて要求を可視化します。可視化した内容は要件定義書としてまとめ、発注者と受注者で合意し、要件定義工程をクローズします。

要件定義で行うこと

要件定義では、主にシステム化の目標やスコープの定義、システムの機能要件と非機能要件の整理を行います。

システム化の目標やスコープを定義する

いきなりシステムに求める機能を整理するのではなく、要件定義工程の最初にシステム化の目標や今回開発するシステムのスコープについて定義します。そもそも何のためにシステム化を行うのか、そしてシステム化で実現しようとしている効果は何なのかを明確化することで、それ以降の工程における方向性のブレを減らすことが大切です。

また、システム化の対象とする業務範囲をシステム化のスコープとして定義します。要件定義を進めていくと、どうしてもあれもこれもと欲張りになってしまいがちです。今回のシステム化で対象とする業務をあらかじめ定めておくことで、システムの肥大化をさけるようにします。

例えば、今回開発するシステムが銀行で利用するATMであれば、以下のように目標やスコープなどを定めます。

システムの目標	ATMを20XX年3月までに開発する ATMは全100店舗へ導入する
システムの効果	顧客の利便性向上　および　窓口対応の負荷低減
スコープ	１．入出金業務２．通帳記入業務３．明細発行業務・・・

システムの機能要件を整理する

システム化の目標やスコープを明らかにしたら、続いてシステムの機能要件を整理します。システムの機能要件とは、対象とする業務とシステム処理内容、作成する帳票、保持するデータなどを意味します。

ATMの例では、以下のような機能が必要となるでしょう。このように、必要な機能を過不足なく洗い出して整理します。

機能名	機能概要
入金機能	紙幣、現金の入金ができること紙幣は一度に10枚まで投入できること
出金機能	紙幣にて出金ができること紙幣は、顧客の出金額に応じて枚数が最小になるように最適な組み合わせとすること
残高表示	顧客の預金残高を表示できること
通帳記帳	通帳の記帳ができること通帳の記帳欄がなくなった場合は、自動で新しい通帳を発行できること
・・・	・・・

システムの非機能要件を整理する

システムの非機能要件とは、システムの機能以外のすべての要件を指します。機能要件と比較して、非機能要件はシステムに寄った内容となるためイメージするのが難しいかもしれません。

システムの機能以外の要件として具体的には、セキュリティに対する要件や運用・保守に関する要件、システムに求める信頼性や可用性、システムの稼働時間などを非機能要件として定める必要があります。

ATMの例では、以下のような要素を定めることになるでしょう。

項目	要件
セキュリティレベル	顧客の金銭を扱うため最高レベルのセキュリティとする
運用・保守	ハードウェアの定期的な修理・交換を行う　など
信頼性	年間停止時間を1時間以内とする　など
システムの稼働時間	平日24時間、休日9:00-18:00
・・・	・・・

業務のモデル化手法

それでは、具体的に要件定義を行うためにはどのような手法を用いればよいのでしょうか。

システム化の対象となる業務は、たいていの場合そのままでは捉えどころがなく、どのような切り口でシステム化を行えばよいか判断することは難しいです。そこで、要件定義を行う上では、業務をモデル化してシステム化しやすいように可視化することが必要です。

以下では、業務のモデル化手法について紹介します。

ユースケース図

ユースケース図は、業務におけるシステムの利用場面を洗い出し、利用者（アクター）とシステムの機能の対応関係を示したものです。

システムには必ず利用者がいます。どの利用者が何の機能を利用するかを整理することで、システムの利用パターンを明らかにすることができます。

ATMの例では、アクターは「顧客」「従業員」「メンテナンススタッフ」等となるでしょう。例えば顧客のアクターであれば入金や出金を行いますし、メンテナンススタッフであればATM内の保管金額の確認や紙幣・硬貨の抜き取りなどを行うことになります。

データフロー図

データフロー図はデータの流れに注目したドキュメントで、業務においてどのようにデータが処理されていくかを示したものです。一般的に業務手順を考える際には、やることをベースに段取りを組み立てると思いますが、システムにおいては、データの取り扱いが重要です。データフロー図はシステム開発ならではのモデル化手法といえます。

ATMの例では、顧客が持っているカードや通帳の情報をATMが読み込み、裏側にあるサーバへと連携した上で残高や出金可能額をATMに返却し、画面表示を行うというデータの流れとなります。これらのデータの流れを各機能に対して整理することで、システム像を理解することができます。

E-R図

E-R図は、業務で取り扱うデータをまとまりごとにテーブルとして表現したうえで、各テーブル間の関係性を示したものです。E-R図はあまり聞きなれない言葉かもしれませんが、システムの世界においては重要です。E-R図は、データベース設計の第一歩となります。現実世界で取り扱っているデータをシステムでも取り扱えるように変換するのがE-R図作成の肝です。

ATMの例では、以下のような情報を整理する必要があるでしょう。顧客は複数の口座を持つ可能性がありますが、このような場合E-R図では顧客と口座は「1-N」の関係であると表現します。

テーブル名	データ項目
顧客	氏名住所連絡先・・・
口座	口座番号残高・・・
入出金履歴	口座番号日付入出金額・・・
・・・	・・・

状態遷移図

状態遷移図は、システムの状態が処理の進行に応じてどのように変化していくかを示したものです。

システムが処理を行う際には、ステータスを意識することが大切です。まだ準備ができていないのに処理を実行してしまったり、処理の実行が終わっているのに継続処理を実施しなかったりすると、システムは正しく動作しません。状態遷移図は、システムが持つステータスを明らかにし、どのようなトリガーでステータスが変遷していくかを可視化するために用います。

ATMの例であれば、以下のようなステータスが考えられるでしょう。

ステータス名	概要	遷移条件
待機状態	顧客の操作を待っている状態	顧客が操作を開始したら「カード挿入待ち」へ
カード挿入待ち	顧客がカードを挿入するのを待っている状態	顧客がカードを挿入したら「暗証番号入力待ち」へ
暗証番号入力待ち	顧客が暗証番号を入力するのを待っている状態	客が暗証番号を入力したら「認証」へ
認証	顧客の口座番号と暗証番号が一致しているか確認中の状態	・・・

業務フロー図

業務フロー図は、業務がどのような順序で行われているか可視化し、どのタイミングでどのシステム機能を利用するか示したものです。

一般的に業務手順を考慮する際には、やることとその順番を段取りとしてまとめると思いますが、それを図で可視化したものが業務フロー図です。業務フロー図は、システムに精通していない人にとっても分かりやすい形式であるため、後述するヒアリングの際に業務担当者の方に業務フロー図の内容に誤りがないか、業務が網羅されているかなどを確認する用途としても有効です。