要件定義書のテンプレート(Word・PDF)を無料で配布しています。システムを作る・入れかえるときに、目的・現状の課題・対象範囲、業務要件、機能要件、非機能要件(性能・セキュリティなど)、スケジュールをまとめる書類です。灰色の文字で各項目の書き方と例が入っているので、はじめて要件定義をする人でも、上から順にうめていけば形になります。表紙と変更履歴の欄つき。
目次
要件定義書のダウンロード
要件定義書とは
要件定義書は、「何のために・何を・どこまで作るか」を、発注する側と作る側(開発会社や社内のシステム担当)で決めて、文書にしたものです。ここで決めたことが、設計・開発・テストの基準になります。あいまいなまま進めると、「頼んだものとちがう」「費用や期間がふくらむ」といった失敗につながります。
要件定義書の主な項目
| 章 | 書くこと |
|---|---|
| はじめに | 目的・背景・現状の課題・対象範囲(やること/やらないこと) |
| 業務要件 | システムを入れたあとの業務の流れ、利用者と人数 |
| 機能要件 | 必要な機能の一覧と優先度 |
| 非機能要件 | 性能・可用性(止まらないこと)・セキュリティ・バックアップ・運用保守・移行 |
| 外部とのつながり | ほかのシステムとのデータのやりとり |
| 制約・前提 | 予算・使う機器・守る決まり |
| スケジュール・用語集 | 主な日程、社内の言葉の意味 |
伝わる要件定義書のコツ
- 「やらないこと」も書く:範囲の外を書いておくと、あとで「それも入っていると思っていた」という食いちがいを防げます。
- 数字で書く:「速く」ではなく「3秒以内」、「たくさん」ではなく「同時に30人」のように書きます。
- 優先度をつける:全部を必須にすると、予算や期間に収まりません。必須・あれば望ましい・将来、に分けます。
- 使う人に確かめる:現場の担当者に読んでもらい、業務の流れに抜けがないか確かめます。
- 変更履歴を残す:決めたことを変えたら、版・日付・内容を表紙の表に書きます。
要件定義の進め方
- 現状の業務と課題を聞き取る(担当者へのヒアリング)
- 目的と範囲を決める
- 業務の流れを決める(業務フローを作ると整理しやすい)
- 機能・非機能の要件を書き出し、優先度をつける
- 関係者で読み合わせ、承認をもらう
よくある質問
RFP(提案依頼書)とのちがいは?
RFPは、開発会社などに「こういうものを提案してください」と依頼する書類です。要件の概要と、提案の条件・日程を書きます。要件定義書は、作るものをくわしく決めた書類で、ふつうは会社が決まってから、いっしょに作ります。RFPは提案依頼書テンプレートで作れます。
小さな案件でも必要ですか?
小さな改修でも、目的・範囲・やらないことの3つを1枚にまとめておくだけで、食いちがいが大きく減ります。