要件定義書の例とテンプレート｜各章の記入例をそのまま使える形で

当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。

要件定義書の例を見る前に知っておきたいこと

要件定義書とは、システムで何を実現するかを、発注側と開発側で合意して書き残した文書です。

会社ごとに様式は違うので、「これが正解」という一つの形はないんです。

『じゃあ、何を見本にすればいいの？』と思いますよね。

この記事では、よく使われる章立てをもとに、編集部が架空の題材で記入例を書きました。

この記事の例で使う題材

記入例は、架空の「社内の会議室予約システムを新しく作る場合」で統一しています。

紙の予約表と表計算ソフトで管理している会議室の予約を、システムに置き換えるという想定です。

テンプレートを使う順番

テンプレートを手にしたら、いきなり上から埋めていくより、次の順で進めるほうが早く仕上がります。

先に目的と範囲を合わせておくと、後の章を書き直す手間が減るんです。

要件定義書そのものについて先に知りたい方は、要件定義書とはで中身と読み手ごとの見方を説明しています。

要件定義書のテンプレート早見表：各章に記入例を1行ずつ

よく使われる章立てに、架空の会議室予約システムの記入例を1行ずつ添えました。

上の表は、案件の規模にかかわらず使える基本形です。

章の名前は会社によって違うこともあるので、社内の呼び方に合わせて読み替えてください。

テンプレート本文の例：そのまま写して書き換えられる形

背景・目的の例

• 背景：本社の会議室は総務部が紙の予約表で管理しており、予約の重なりや確認の電話が日常的に起きている。
• 目的：社員が自分で空き状況を確かめて予約できるようにし、総務部の確認の手間を減らす。
• 期待する効果：予約の重なりを減らし、会議の準備にかかる手間を少なくする。

背景と目的は、それぞれ2〜3行で十分です。

効果の数字が決まっていない時は、無理に書かずに「何が良くなるか」だけ書いておきましょう。

対象範囲の例

• 対象とする：本社の会議室の予約、変更、取り消し、空き状況の確認
• 対象としない：社外の人の予約、備品の貸し出し、ほかの拠点の会議室
• 次の段階で検討する：予定表との連携

「対象としない」を書いておくと、レビューの場でのやり取りが早く片づきます。

例えば、こんな確認がその場で終わるんです。

「ほかの拠点の会議室も、今回まとめて入れられませんか？」
「今回は本社だけと範囲に書いてあるので、次の段階で検討しましょう」

現状の課題と目指す姿の例

As-IsとTo-Beを場面ごとに並べると、何が変わるのかが一目で伝わります。

利用部門の方がレビューで「自分の仕事がどう変わるか」を確かめやすくなるのもうれしいところです。

業務要件の例

業務要件は、主語のある短い文で書くのが大切です。

表にすると、抜けている項目に気づきやすくなりますよ。

移行要件と運用・保守要件の例

• 移行要件：稼働日より後の予約は、総務部が紙の予約表からシステムに登録し直す。登録が終わったら紙の予約表の受付を止める。
• 運用・保守要件：操作の問い合わせは総務部が受け付け、システムの不具合は情報システム部門が開発側に連絡する。
• 運用・保守要件：会議室の追加や名称の変更は、総務部が管理画面から行う。

小さなシステムでも、稼働した後に「誰に聞けばいいか」が書いてあると、現場が困りません。

用語集の例

社内で当たり前に使っている言葉ほど、開発チームには伝わらないことがあります。

意味が二通りに取れそうな言葉は、ここで一つに決めておきましょう。

未決事項の例

『未決事項を書くと、準備不足に見えないかな』と心配になる方もいるかもしれません。

実は逆で、決まっていないことを隠さずに書いてある要件定義書のほうが、関係者から信頼されやすいんです。

各章をもっと詳しく書く手順は、要件定義書の書き方で紹介しています。

システム要件定義書の例：機能要件と非機能要件

ここからは、システム要件定義書でよく使う一覧の例です。

業務側の要件定義書とまとめて一冊にしている場合は、機能要件と非機能要件の章にあたります。

機能一覧の例

「元になった業務要件」の列があると、なぜその機能が必要なのかを後からたどれます。

要求工学の国際規格 ISO/IEC/IEEE 29148 でも、良い要件の性質として「追跡できる」ことが挙げられているんです。

画面一覧の例

機能一覧ができたら、画面の一覧も作っておくと、利用部門が完成の姿を思い描きやすくなります。

『画面の細かい配置まで決めないといけないの？』と思うかもしれませんね。

要件定義の段階では、画面の数と、それぞれで何ができるかが分かれば十分です。

配置や項目の並びは、基本設計で詰めていきます。

非機能要件の例

非機能要件は、IPA（独立行政法人情報処理推進機構）の「非機能要求グレード」の大項目を見出しにすると書き漏れが減ります。

大項目は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つで、それぞれ0〜5の段階からレベルを選ぶ方式です。

この例では数字をあえて入れていません。

目標の数字は、現状を測ったうえで発注側と開発側で話し合って決めるのが基本だからです。

「朝はどのくらいの人が同時に予約しそうですか？」
「始業前に集中するので、まずは今の予約表の使われ方を調べてみます」

こうしたやり取りを経て、数字を埋めていきます。

テンプレートを自分の案件に合わせる時の注意

テンプレートは便利ですが、そのまま使うと案件に合わない部分も出てきますよね。

規模ごとの目安を表にしました。

書き換える前のチェック

版の管理も、テンプレートに入れておく

要件定義書は、レビューのたびに少しずつ書き換わっていきます。

表紙か冒頭に「版」「日付」「変えた内容」「変えた人」を書く欄を用意しておくと、どれが最新かで迷いません。

承認した後に変更が出た場合も、この欄に残しておけば、受入テストの時に「どの版の要件で確かめるか」がはっきりします。

一緒に用意しておきたい資料

要件定義書の本文だけでは伝えきれない部分は、別の資料にして参照します。

業務フロー図、画面一覧、帳票一覧、データ項目一覧、外部インターフェース一覧、課題管理表、議事録などがよく使われます。

どの資料が必要かは、要件定義の成果物一覧でまとめています。

例を読むときに見ておきたいところ

ほかの人が書いた要件定義書の例を読む時は、次の点に注目すると学びが多くなります。

• 背景・目的と、機能要件がつながっているか
• 「今回やらないこと」がどう書かれているか
• 非機能要件に、確かめ方が書いてあるか
• 未決事項に、担当と期限が書いてあるか

上手な例ほど、書いてある量より、つながりがはっきりしているんです。

よくある相談に答えます

要件定義書の例やテンプレートについて、よく寄せられる相談を要約してお答えします。

全体像の図は、まず「誰が使うか」と「何とつながるか」から描き始めると楽になります。

中央にシステムを置き、周りに利用者、ほかのシステム、扱うデータを並べて線でつなげば、最初の形としては十分です。

細かい構成は、基本設計や方式設計で詰めていくので、要件定義の段階では全体の関係が伝われば大丈夫です。

契約の形によって変わる、というのが答えになります。

受託開発では、要件定義を準委任契約、設計以降を請負契約に分けて結ぶ例もあります。

見積もりを取る時は、何人が、どのくらいの期間で、どの成果物を作るのか、内訳で比べてみてください。

いちばんの近道は、実際の要件定義書の例を読んで、自分の案件で書いてみることです。

公的な資料なら、IPAが2019年に公開した発注側向けの要件定義の手引きが、問題と解決のヒントをペアで説明していて読みやすいですよ。

IPAの公開ページから読むことができます。

よくある質問

まとめ

題材を一つに絞って、業務要件から非機能要件まで通しで書いた例は、要件定義の具体例で読めます。

あわせて読みたい

要件定義とは？意味をわかりやすく解説｜家づくりで見る全体像

要件定義書の書き方を手順で解説｜NG文の直し方と章ごとの記入例

要件定義の具体例｜備品の貸出管理システムで業務要件から非機能要件まで