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

要件定義とは

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

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

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

目次

要件定義とは

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

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

要件定義で行うこと

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

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

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

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

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

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

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

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

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の例であれば、以下のようなステータスが考えられるでしょう。

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

業務フロー図

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

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

ヒアリング

業務をモデル化するためには、実際に業務を担当している担当者へのヒアリングを行い、結果を議事録としてまとめることが重要です。業務手順書などでは必ずしもすべての業務が網羅されているとは限りません。抜け漏れを防ぐためにもヒアリングが必要です。

ヒアリングでは、現行システムへの不満や改善案、新システムへの要望なども確認し、できるだけ多くの人のリクエストをシステム機能に取り入れ、要件定義内容の合意形成を図るとよいでしょう。

まとめ

この記事では、基本情報技術者試験を受けようとされている方に向けて、要件定義についての解説を行いました。要件定義は、受注者としてシステム企業に勤められている方はもちろんのこと、発注者側の方にとっても重要な工程となります。

システムに携わる以上、すべての人が知っておくべき工程ですので、試験対策としてはもちろん、実務においても要件定義について知っておくとよいでしょう。