要件定義の進め方とテンプレート

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

今回は、要件定義に関する基本から、要件定義の進め方や書き方、サンプルなどを紹介します。

要件定義とは

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

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

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

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

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

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

要件定義書とは

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

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

要件定義の成果物

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

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

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

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

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

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

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

要件定義の進め方

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

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

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

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

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

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

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

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

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

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

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

ヒアリング(開発者)

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

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

要件を定義(開発者)

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

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

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

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

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

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

要件定義書のテンプレート

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

エクセル版

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

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

ワード版

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

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

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

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

要件定義と基本設計の違いは、抽象的か具体的かという点です。

要件定義は、ユーザーの要求を引き出し実装すべき機能を整理することが主目的なので、システム化の目的、現行の業務フローや画面レイアウトなども大まかに作成します。

さらに、要件定義では稼働率や応答時間、移行性、セキュリティといった環境に対する定義も盛り込みます。

一方で、基本設計では要件定義で確認したシステム化の概要を仕様に落とし込む作業が必要になります。つまり、ぼやっとした概要だけ作った要件定義をさらに細かく決めていくということです。

要件定義でざっくりした画面レイアウトを作成し、基本設計でさらに細かいレイアウトを作成したり、
共通化できるモジュールの設計や、具体的なデータの入出力処理などプログラムに落とすことを前提とした設計が必要になります。

Twitterでフォローしよう

おすすめの記事