要件定義書サンプル・書き方

要件定義書は、要件定義工程の最終的な成果物となるが、書き方がピンと来ない人も多いだろう。

そこで、今回は要件定義書の書き方を説明する。

はじめに

要件定義は、システム化構想の結果を受けて、「どんな業務にしたいのか検討し、その業務を実現するために必要なシステムを整理する」工程である。

ゆえに、要件定義書には「業務要件」と「システム要件（機能と非機能）」の２つを書けばよく、具体的な記載内容は決められていない。

とはいえ、担当者の能力で記載内容が変わるようでは、システム品質に差が出てしまうことから、記載内容やテンプレートを整備している企業も多い。

まずは自社ルールを確認してみる良いだろう。

※当サイトでは、情報処理推進機構（以下、IPA）や行政機関の資料を参考に記載している。

なお、要件定義書を書き上げるまでの途中成果物として作成する資料については、下記をご覧いただきたい。

要件定義工程の成果物一覧

2019年6月4日

要件定義書のサンプル

私が参考にした要件定義書のサンプルを紹介する。

下記の資料は、調達仕様書（競争入札の際に発行するシステム仕様を記載した文書）だが、業務要件・機能要件・非機能要件が正確にまとめられているので、とても参考になる。

国土交通省『建設キャリアアップシステム 要件定義書』

厚生労働省『毎月勤労統計調査オンラインシステムの更改及び運用・保守に係る業務一式 要件定義書』

厚生労働省『厚生労働省情報提供システムの更改整備及び運用・保守業務一式 要件定義書』

また、IPAが作成した下記資料も、要件の書き方や記入例が詳しく説明されていて参考になる。

IPA『システム開発調達仕様書（ひな形）』

要件定義書の目次

それでは、ここからは要件定義書の書き方を説明していく。

プロジェクトの特性にもよるが、要件定義書には下記のような内容を記載する。

書くことが多すぎて嫌になるかもしれないが、過去のプロジェクトから書ける内容も多いため、ゼロから全てを書き上げる必要はない。

関連記事：要件定義工程の進め方

では、さっそく、要件定義書の書き方について、下記３つに分けて説明していこう。

1.業務要件の定義
2.機能要件の定義
3.非機能要件の定義

業務要件

業務要件には、主に下記６つを記載する。
　1-1.業務概要
　1-2.規模
　1-3.時期・時間
　1-4.場所
　1-5.管理すべき指標
　1-6.システム化範囲

業務概要

業務の概要では、下記の４つを記載する。
　１）背景と目的
　２）用語の定義
　３）業務の概要
　４）現行システム概要

１）背景と目的

システム化が必要な背景と目的を簡潔に記載する。

これらは要件定義より前の「企画」の段階で整理されているはずなので、企画段階の資料をもとに書くと良いだろう。

なお、背景と目的がピンとこない人は下記のように考える理解しやすい。

２）用語の定義

システム化対象業務にて使用する専門的な用語の説明を記載する。

用語の数が多い場合は、別紙を添付しても良い。

３）業務の概要

システム化対象の業務の概要を記載する。

概要を記載したうえで、現新の業務フローや業務処理定義書を載せると良いだろう。

４）現行システム概要

システム化対象業務が利用している現行システムの概要を記載する。

構成図や一覧表を載せると良い。（後述の「システム化範囲」と合わせて書く場合もある）

規模

システム化対象業務の組織数や利用者数といった業務の規模を記載する。

業務フローに対して、How-many（どれぐらい？）の観点で整理すると良いだろう。

なお、ハードウェア・ディスク量・アクセス数といったシステム面の規模については、「非機能要件の規模要件」に記載するため、ここには記載しない。

時期・時間

システム化対象業務の実施時期や業務時間などを記載する。

業務フローに対して、When（いつ？）の観点で整理すると良いだろう。

場所

システム化対象業務が関係する場所や組織について概要を記載する。

業務フローに対して、Where（どこで？どこに？）の観点で整理すると良いだろう。

管理すべき指標

システム化対象業務にて、管理すべき指標を記載する。

重要業績指標（KPI）で考えるとイメージしやすい。

KIPの例については、下記のサイトが参考になる。

>> 財務視点のKPI
>> 顧客視点のKPI
>> 業務プロセス視点のKPI
>> 学習と成長視点のKPI

システム化範囲

対象業務のシステム化範囲を明確に記載する。

文章だけだとどうしても伝わりづらいので、「1-1.業務概要」の業務フローや現行システムと合わせて記載すると良いだろう。

機能要件

機能要件には、主に下記５つを記載する。
　2-1.システム機能要件
　2-2.画面要件
　2-3.帳票要件
　2-4.情報・データ要件
　2-5.外部インターフェース要件

システム機能要件

今回開発するシステム機能について、機能一覧や機能構成図に全体像をまとめる。

見積りに影響するような難易度の高い機能については、詳細な説明を記載しよう。（別紙でも良い）

ここには開発する機能を全て列挙するため、運用保守や移行に関係する機能も含めること。

画面要件

画面要件では、画面一覧／画面遷移図／画面レイアウトなどに加えて、具体的な画面イメージを記載する。

帳票要件

画面要件と同じく、帳票一覧／帳票レイアウトなどに加えて、具体的な帳票イメージを記載する。

情報・データ要件

保管するデータ項目の一覧やデータ量の想定件数を記載する。

ER図などを用いて表現することも多い。

外部インターフェース要件

今回開発するシステムと処理連携やデータの授受を行う他システムを一覧にまとめる。

データ連携手法の選定する際には、下記の記事が参考になる。

>> システム間連携のアーキテクチャ、4つの基本パターンと正しい適用のポイント徹底解説

非機能要件

非機能要件には、主に下記５つを記載する。
　3-1.ユーザビリティ及びアクセシビリティ要件
　3-2.システム方式要件
　3-3.規模要件
　3-4.性能要件
　3-5.信頼性要件
　3-6.拡張性要件
　3-7.上位互換性要件
　3-8.継続性要件
　3-9.情報セキュリティ要件
　3-10.情報システム稼働環境要件
　3-11.テスト要件
　3-12.移行要件
　3-13.引継ぎ要件
　3-14.教育要件
　3-15.運用要件
　3-16.保守要件

ユーザビリティ及びアクセシビリティ要件

システム利用者の種類や特性

今回開発するシステムの利用者について、ITリテラシーの水準を記載する。

利用者のITリテラシーが低い場合は、画面構成や操作方法をよりシンプルにする必要があるだろう。

ユーザビリティ要件

前述のシステム利用者の特性を受けて、今回開発システムに求める”使いやすさ”を記載する。

アクセシビリティ要件

前述のシステム利用者の特性を受けて、今回開発システムに求める”利用しやすさ”を記載する。

ユーザビリティ要件と意味合いが似ているが、こちらは高齢者や障害者、多国籍の利用者でも支障なく利用できるような要件を記載する場合が多い。

システム方式要件

システム構成の方針、全体構成図、開発方式や手法などについて記載する。

システム構成の方針

システム全体構成

プラットフォーム（ネットワーク、ハードウェア、OS ・ミドルウェア）の構成を記載する。

開発方式や開発手法

開発方式や開発手法の指定がある場合は記載する。

規模要件

システム化において必要な機器数やデータ量、処理件数などを記載する。

性能要件

システムの応答時間（主にオンライン機能）について記載する。

信頼性要件

可用性と完全性について記載する。

拡張性要件

利用者やデータ量の増加といった「性能の拡張性」や、「システム機能の拡張」における要件を記載する。

上位互換性要件

OSやソフトウェアのバージョンアップにおける要件を記載する。

継続性要件

「信頼性要件の可用性」と同じ意味合いだが、こちらは大規模災害時における復旧目標時間や、データのバックアップについて記載する。

予備システムを別拠点に準備しておき、災害発生時に切り替える…というような冗長性具体的に書く場合もある。

情報セキュリティ要件

開発するシステムが満たすべきセキュリティの要件を記載する。具体的には、

情報システム稼働環境要件

システム稼働環境における要件を記載する。

上記に加えて、サーバー等の設置における立地や拠点条件を記載する。

※構成図は、「3-2.システム方式要件」のシステム全体構成に記載をしていれば省略して良い。

（参考）農林水産省『各種構成図』

テスト要件

システムの品質を担保するために必要なテストの種類や目的、方法、実施内容、範囲、報告書等の要件を記載する。

単体テスト、結合テスト、総合テスト、受入テスト（運用テスト）について、それぞれ記載すると良いだろう。

（受入テストは、ユーザ企業側のテストになるので、ベンダー企業の支援内容について記載する）

移行要件

システム移行に関する下記のような要件を記載する。

引継ぎ要件

システム開発企業と、システム運用企業が異なる場合は、運用企業への引継ぎ要件を記載する。

引き継ぎ内容やドキュメントを記載することが多いが、トレーニングが必要となる場合は、対象者・スケジュール・実施場所なども記載しよう。

教育要件

システム利用者への操作教育について、下記のような観点で記載する。

運用要件

定常運用、随時運用、障害時運用などのシステム運用における要件を記載する。

例えば、下記のような観点で記載する。（必要なツールも記載すること）

保守要件

プログラムだけでなくハードウェア等も含めた、システムの保守における要件を記載する。

さいごに

今回は、要件定義書の書き方を紹介してきた。

冒頭にも述べたが、ここに紹介した書き方は一例であるため、プロジェクトの特性に応じて書く内容を変えることになると思う。

この記事が参考になれば幸いだ。

要件定義工程の関連記事はこちら。

要件定義工程の成果物一覧

2019年6月4日

要件定義工程の進め方

2019年6月2日

【結論】要件定義の目的は「プロジェクトの失敗を減らすこと」

2019年6月2日

要件定義書サンプル・書き方

2019年6月2日

機能要件・非機能要件の書き方【サンプル有り】

2018年8月17日

参考文献

IPA『ユーザのための要件定義ガイド』

IPA『経営者が参画する要求品質の確保』

IPA『システム開発調達仕様書（ひな形）』

国土交通省『建設キャリアアップシステム 要件定義書』

厚生労働省『毎月勤労統計調査オンラインシステムの更改及び運用・保守に係る業務一式 要件定義書』

厚生労働省『厚生労働省情報提供システムの更改整備及び運用・保守業務一式 要件定義書』

農林水産省『各種構成図』

ITL(株)『バランス・スコアカードnavi』