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




要件定義書の書き方

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

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

はじめに

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

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

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

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

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

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

要件定義工程の成果物

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

2019年6月4日

要件定義書のサンプル

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

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

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

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

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

 

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

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

要件定義書の目次

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

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

 

要件定義書の目次(例)

1.業務要件の定義
1-1.業務概要
1-2.規模
1-3.時期・時間
1-4.場所
1-5.管理すべき指標
1-6.システム化範囲

2.機能要件の定義
2-1.システム機能要件
2-2.画面要件
2-3.帳票要件
2-4.情報・データ要件
2-5.外部インターフェース要件

3.非機能要件の定義
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.保守要件

 

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

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

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

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

業務要件

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

業務概要

業務の概要では、下記の4つを記載する。
 1)背景と目的
 2)用語の定義
 3)業務の概要
 4)現行システム概要

1)背景と目的

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

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

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

背景:なぜシステム化が必要なのか?
目的:システム化に何を期待するのか?

2)用語の定義

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

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

3)業務の概要

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

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

4)現行システム概要

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

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

・ハードウェア構成
・ネットワーク構成
・ミドルウェア構成
・システム機能一覧(画面や帳票)
・データ一覧(テーブルやファイル)
・外部インターフェース一覧
など

規模

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

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

・組織
・利用者
・注文
・取り扱いの製品
・在庫
・端末
・プリンタ
など

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

時期・時間

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

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

例)
 業務時期:月初から第三営業日までに実施
 業務時間:9時〜17時

場所

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

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

管理すべき指標

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

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

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

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

システム化範囲

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

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

機能要件

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

システム機能要件

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

システム機能一覧の項目(例)
・機能名
・機能種別(画面、帳票、バッチ等)
・処理概要
・利用者
など

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

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

画面要件

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

帳票要件

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

情報・データ要件

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

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

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

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

システム機能一覧の項目(例)
・外部インターフェース名
・外部インターフェース概要
・連携方式(バッチorオンライン)
・送受信区分
・相手先システム
・送受信タイミング
・送受信条件(ファイル転送等)
など

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

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

非機能要件

非機能要件には、主に下記5つを記載する。
 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リテラシーが低い場合は、画面構成や操作方法をよりシンプルにする必要があるだろう。

ユーザビリティ要件

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

ユーザービリティの項目(例)
・画面構成
・操作のしやすさ、分かりやすさ
・指示や状態の分かりやすさ
・エラーの防止と処理
・ヘルプ(ヘルプ情報やマニュアルなどの参照)

 

アクセシビリティ要件

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

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

アクセシビリティ要件の項目(例)
・機能へのアクセスのしやすさ
・指示や状態の分かりやすさ
・言語対応

システム方式要件

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

システム構成の方針

システム方式の項目(例)
・システムアーキテクチャ
 メインフレーム、Webサーバ、など

・アプリケーションプログラムの設計方式
 コンポーネント(ソフトウェア機能を特定単位で分割したまとまり)の再利用、など

・ソフトウェア製品の活用方式
 広く流通し、利用実績のあるものを活用する、など

・システム基盤の方針
 データ量や利用者の増加(拡張性)について書く場合が多い。
 具体的な基盤を指定する場合もある。

システム全体構成

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

開発方式や開発手法

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

・開発方式
 スクラッチ開発、パッケージを使った開発、など

・開発手法(例)
 ウォーターフォール、プロトタイピング、スパイラル、アジャイルなど

規模要件

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

・機器数
 サーバー、クライアント端末、ディスク、プリンタなど

・データ量
 テーブル毎のデータ量
 「2-4.情報・データ要件」に記載をしていれば、そちらを参照と書けばOK。

・処理件数
 システム機能毎にピーク時の処理件数を記載する。

性能要件

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

信頼性要件

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

・可用性
 「使いたいときに使えるか」の指標。一般的には稼働率を記載する。

・完全性
 「データの欠損や不整合がないこと」の指標。
 機器の破損への対策、ログの取得など、定性的な書き方となることが多い。

拡張性要件

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

上位互換性要件

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

継続性要件

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

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

情報セキュリティ要件

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

・利用者等の認証
 例:ユーザーIDやパスワードによる認証

・権限管理
 例:アカウントの登録・更新・停止・削除など

・アクセス管理
 例:利用者の職務に応じて利用機能を制限

・ログ管理
 例:システムの利用記録・検索など

・暗号化機能
 例:不正アクセス防止や情報漏洩対策

・不正プログラム対策
 例:ウィルス感染防止の対策

・通信の制御
 例:不正な通信データの遮断
など

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

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

・ハードウェア構成図
・ソフトウェア構成図
・ネットワーク構成図

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

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

(参考)農林水産省『各種構成図』

テスト要件

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

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

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

移行要件

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

・移行スケジュール
・プログラム移行
・初期データ登録
・既存システムからのデータ移行
・役割分担
など

引継ぎ要件

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

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

教育要件

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

・教育対象者
・教育の内容
・教育の実施時期
・教育の方法
・教材
・教育対象者数

運用要件

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

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

・運転管理/監視
 システム稼働監視、障害時の対応、報告内容や報告頻度

・運用実績の評価と改善
 運用業務の内容や工数、報告内容や報告頻度

・システム操作
 バックアップやアカウントの管理、ウィルスチェック

・運用サポート
 操作研修や問い合わせ対応

・業務運用支援
 データ作成支援や問い合わせ対応

・システムの現況確認
 各種管理台帳の提出

保守要件

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

・プログラム
 保守の受付/対応時間

・ハードウェア
 保守の受付/対応時間

・ソフトウェア製品
 保守の受付/対応時間

・データ保守実績の評価と改善
 保守業務の内容や工数、報告内容や報告頻度

さいごに

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

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

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

 

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

要件定義工程の成果物

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

2019年6月4日
要件定義の進め方

要件定義工程の進め方

2019年6月2日
要件定義の目的

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

2019年6月2日
要件定義書の書き方

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

2019年6月2日
機能要件と非機能要件の書き方〜サンプル付き

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

2018年8月17日

参考文献

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

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

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

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

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

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

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

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






コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA