Step.4 要件定義の全体像

要件定義は、業務要件、機能要件、非機能要件で構成され、各要件には多数の項目が定義されており、それぞれの内容は項目間で影響し合っています。

このＳｔｅｐでは、この要件定義全体の構造を説明した上で、要件定義全般にわたって気を付けるポイントを解説します。

構成要素を把握し要件を定義する

【標準ガイドライン関連箇所：第３編第５章第２節1)ア】

要件定義の内容は定義する項目が多数あるため、詳細を検討していく中で、どこかで同じ内容を検討してはいないか、本当に漏れがないか、と不安になってくることがあります。

まずは、要件定義の構造と定義する項目を俯瞰し、要件の上位に当たる、政策目的・実現する目標、達成すべきプロジェクト目標に沿って、何をどこで定義するのか、それぞれの項目がどのように関連しているかを理解しましょう。要件定義は、それぞれの項目の整合性を逐次取りながら定義することで、無駄なく、漏れなく、効率的に検討していくことができます。

• 図5-2

この実践ガイドブックの別紙として、業務要件、機能要件、非機能要件のそれぞれのひな形を用意しています。これを活用すれば、基本的な部分についての漏れをなくすことができます。

ただし、これらの要件定義を作成する時点では、全ての項目をきっちりと定義することが難しい場合もあります。未確定の項目は、後の工程で定義されることになります。このときに関連する項目に変更がある場合があるため、関連する項目の変更漏れがないように、未確定の項目の関係性がわかるようにしておくことが大切です。

また、定義書が一通り作成された後、以下の観点で最終確認を行うことで、定義漏れを防ぐことができます。

• 表5-2

要件定義内容を確認する観点

• 様式例5-1

要件定義書のひな形

機能の優先順位は改善後の業務で判断する

【標準ガイドライン関連箇所：第３編第５章第２節1)イ】

要件定義で検討する機能は、必ずしも全てを実現できるわけではありません。予算やスケジュールの関係から、実現する機能を絞らなければならないことはよくあります。

機能の実現要否を検討する際には、政策目的やプロジェクト目標との関係、費用対効果等の観点を主眼として優先順位を判断していきます。また、機能を代替する方法（業務担当者の手作業や運用・保守作業にする等）も合わせて検討します。

• 図5-3

機能の優先順位付けの考え方

一貫性をもった論理的な記載とする

【標準ガイドライン関連箇所：第３編第５章第２節】

要件定義の内容を記した文書は、ＰＪＭＯと事業者がサービス・業務や情報システムの目指すべき姿を共有するとともに、事業者との契約上の合意文書となる重要なものであるため、誤った定義や曖昧な定義が行われると、後続の工程に重大な影響を与えます。

そのため、要件定義の内容は、次に示す点を参考に、正確で一貫性のある記載となるようにしましょう。

• 曖昧な用語や一般的な意味と異なる使い方をしている用語等は、プロジェクト関係者間の認識そごを防止するため、用語の定義及び機能を定義する粒度や深さについて統一する。

• 要件定義書の「業務要件定義」のインプットであるサービス・業務企画の内容とも整合の取れた区分、順番で機能を記載する。業務の単位ごとに記載する場合も、共通処理機能を識別できるように整理する等、機能数を把握できるように記載する。

• 機能の説明は、箇条書き等にして簡潔に記載する。既存のサービス・業務や情報システムの変更を行う際の要件定義では、追加・変更となる要件が明確になるよう、変更箇所の記載ルールを定めて記載を統一する。

要件定義書は継続的にメンテナンスする

【標準ガイドライン関連箇所：第３編第５章第２節】

要件定義が確定した後、設計・開発等を実施していく中で、要件定義の内容に漏れや誤りを発覚することはよくあります。これらは、プロジェクト管理要領の変更管理及び事業者との取り決めに従って管理されますが、要件定義書自体の修正が行われないことが多々あります。要件定義書は、プロジェクト関係者に情報システムの要件を正確に伝達するためのものであるため、変更が発生した際は常に最新化を行いましょう。

また、要件定義書の情報は、後工程である設計・開発において、設計情報のインプットとなる以外にも、各種テストのインプット情報にも、運用開始後における継続的なサービス・業務改善活動の基礎情報としても利用されます。しかし、メンテナンスという名の下、内容が変質したり、事業者側に有利な内容に変わってしまったりすることがあるため注意し、継続的な維持・管理を心掛けてください。