システムを作成するときに必要になる要件定義ですが、実際に何を書けばいいのか?どう書けばいいのかを正しく知っている人は少ないのではないでしょうか?

今回は、要件定義のテンプレートや進め方、サンプルなどを紹介します。

要件定義書テンプレート(サンプル付)

要件定義書のサンプルテンプレートを紹介します。要件定義書は進めるプロジェクトによって実際に記載する項目はことなるので、フォーマットのサンプルとして必要部分を参考にしてください。

エクセル版

エクセル版の要件定義書のサンプルテンプレートです。表紙と目次、各項目のフレームだけが使用できます。エクセルの場合、図や表を作成するのは容易ですが、目次を作成するのが大変なのでワードと併用するといいでしょう。

要件定義書のエクセルテンプレート01(表紙) 要件定義書のエクセルテンプレート01(目次)要件定義書のエクセルテンプレート01(フレーム)
要件定義書のテンプレート(エクセル)

ワード版

ワードで作成した要件定義書のサンプルテンプレートです。表紙と目次、各項目のタイトルが記載されています。実際の書き方はないので、要件定義書のサンプルなどを参考にして作成する必要があります。

ワードでは、画面レイアウトや一覧表を書くのが難しいのでエクセルと併用するのが効率的でしょう。

要件定義書のエクセルテンプレート02(表紙) 要件定義書のエクセルテンプレート02(目次) 要件定義書のエクセルテンプレート02(項目)
要件定義書のテンプレート(ワード)

 

要件定義とは

要件定義とは、システムを作成したい企業(ユーザー企業)からヒアリングしてシステム化すべき機能を確定していく作業です。

ユーザー企業は、システムの専門家ではないのでシステムを作成したいが、どのように実現したらいいかはわかりません。

そのため、システムを開発会社のSEがユーザー企業の経営者や情報システムの担当者、実際に業務を行っている担当者などから、

システム化の目的
システム化の予算
システム化の要件
業務フロー

といったシステムを作るために決めるべきことををまとめます。

業務を細分化して、システム化の要件が揃えば、完成までに「どのぐらいの期間がかかるのか」「どのぐらいの予算が必要なのか」「完成したシステムの全体像」といったことがわかるようになります。

要件定義書とは

要件定義書は、要件定義で確定させた内容を文書にしたものです。この段階では、まだ細かい設計は行いません。あくまでもユーザー企業の要件をまとめたものです。

要件定義書を作成することで、システムの全体図、システム化の目的や方針、方式、対象業務やシステムの役割などが明確になるという利点があります。

要件定義の成果物

要件定義を行って作成される成果物は、どのようなシステムを作成するかで変わってきます。しかし、一般的にどの要件定義でも記載される項目について紹介します。

要件定義で作成される成果物一覧

業務要件
システム化の背景
システム化の目的
システム化の範囲
現行の業務フロー
システム化後の業務フロー

機能要件
システム全体像
外部連携の有無・方式
外部システム関連図
画面一覧
画面レイアウト
帳票一覧
帳票概要
バッチ処理一覧
データ一覧
コード定義
テーブル一覧
テーブル定義書

非機能要件
システム方式
システムの規模
性能
拡張性
移行性
継続性
セキュリティ環境
引継ぎ
教育
運用
保守

以上が要件定義に記載されることのある成果物ですが、これらをすべて要件定義に盛り込まなければいけないわけではありません。

最終的な目的は、希望した通りのシステムが完成することです。システムができる最低限のことを決めておけば、システム化は達成できるのです。

要件定義の進め方

要件定義の進め方は、まずシステムを導入するユーザー企業の導入計画から始まります。そこから、システム化で解決したい目標、現状の業務の洗い出しや整理というように具体的な要件定義の作成と進んでいきます。

1.システム化の検討(ユーザー)
2.ベンダーの選定(ユーザー)
3.ヒアリング(開発者)
4.要件定義書の作成(開発者)
5.要件定義書の提出、承認(開発者・ユーザー)

1.システム化の検討(ユーザー)

要件定義を進めるために、最初に行うことはシステム化の検討からです。

そもそも、システム化をする意味があるのか?、予算、スケジュール、ユーザー側の担当はだれかといったことをベンダーを選定して要件定義を進めてもらう前に決めておかないといけません。

これを怠ってしまうと、実際にヒアリングの段階で決めることになり無駄な時間ばかり掛かるということになってしまいます。

ITに精通している企業ならRFPを作成しておいてある程度の概要を作成しておくと、先にRFPをベンダーに提出し、ヒアリングの際に大きく時間短縮ができて効率がよいです。

しかしRFPの作成は情報システム部やIT系企業でもないと難しい面もあるので通常はなくてもかまいません。

ベンダーの選定(ユーザー)

システムを外部に委託するか、社内で作成するかも含めてシステム化を実際に行うのは誰かを決めなけれなばなりません。ベンダーを選定するなら、自社か外部か、依頼する基準、何社から選ぶかを決めておくとスムーズでしょう。

特に付き合いのあるシステム開発企業がない場合、ベンダーの選定は難しいのですが時間があるなら、いくつかの企業から相見積をとって価格だけでないサービスや提供範囲などを比較します。

ヒアリング(開発者)

要件定義書を作成するためにユーザー企業にヒアリングを行います。

ユーザー企業がシステム化について、まったく何もわからないというのはよくあることなので、開発者は要件定義に必要な項目を先に提出しておいて、ヒアリングの段階で質問と詳細を確認するという流れの方が効率がいいです。

要件を定義(開発者)

ユーザー企業からヒアリングした内容を元に、要件を整理しながら要件定義書を作成します。

ユーザー企業がシステム化はしたいけど、ざっくりとしたイメージしかないという場合も多いので、ヒアリング時にいかに多くの要望や課題、問題を引き出せるかが開発者の力量にかかってきます。

要件定義書に盛り込む内容は、ヒアリングで引き出した内容を元に必要なものを整理します。また、やりたいことと予算や期限が合わないということも頻繁に起きるので、どこまでが必須なのか、どこを妥協するかといったすり合わせも大切になってきます。

要件を提出・承認(開発者・ユーザー)

要件定義が完成したら、ユーザー企業に提出して内容を確認してもらいます。ユーザー企業の担当者は、忙しかったりシステムについてよくわからないので、要件定義書をあまり精査せずに承認するということもあります。

その場合、高い確率で後で問題になることになりますので、要件定義書は文書をただ渡すだけでなく一緒に確認することが望ましいです。

要件定義と基本設計の違い

要件定義と基本設計は、システム開発プロセスの異なるフェーズで、それぞれ異なる目的と成果物を持っています。

要件定義
要件定義のフェーズでは、開発するシステムやソフトウェアが満たす要件や機能、性能、制約条件などを明確にします。この段階では、クライアントや利用者のニーズを詳細に収集し、それらを文書化してシステムが達成すべき目標を定義します。要件定義の主な成果物は要件定義書です。

基本設計
基本設計のフェーズでは、要件定義で明らかにされた要件を基にして、システムの全体構造やデータ構造、重要な機能の動作原理などを設計します。この段階での目的は、システムの枠組みを作り、各部分の関係やデータの流れを定義することです。

二つの違い

目的の違い
要件定義は「何を実現するか」に焦点を当て、基本設計は「どのように実現するか」に焦点を当てます。

成果物の違い
要件定義の成果物は要件定義書であり、システムの要件や目標を記述します。基本設計の成果物は基本設計書であり、システムの構造や設計に関する詳細を記述します。

対象の違い
要件定義はクライアントや利用者のニーズに基づくもので、基本設計は要件定義をもとにした技術的な解決策に関するものです。

要件定義と基本設計は、システム開発を成功に導くために不可欠な連続したステップであり、それぞれがシステム開発の異なる側面を担っています。

要件定義書の参考リンク

総務省のパッケージソフトを開発する際の要件定義書の必要項目を記載したPDF文書です。一般的な要件定義書の項目がすべて記載されているので特に官公庁向けに必要な項目がわかります。書き方のサンプルもあるので、学習用にもいいでしょう。
総務省:パッケージソフトに対する要件定義書のサンプル

経済産業省の予算管理システムの機能要件定義書のサンプルです。
経済産業省:予算管理システムの要件定義書