要件定義書とは？中身と読み手別の見方、システム要件定義書との関係

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

要件定義書とは？ひとことで言うと「作るものの合意書」です

要件定義（RD：Requirements Definition）は、システム開発の最初のほうで「何を作るか」を決める工程です。

その工程の結果をまとめた文書が、要件定義書なんです。

「要求」と「要件」は同じではありません

要件定義書を読むときに、まず押さえておきたいのが「要求」と「要件」の違いです。

要求は、利用者や発注者の「こうしたい」「こうなってほしい」という声のことです。

要件は、その要求のうち、予算・期間・技術を踏まえて「システムで実現する」と合意したものです。

『要求を全部書けばいいのでは』と思うかもしれません。

実は、要求をそのまま並べただけの文書は、要件定義書としては足りないんです。

何を実現して、何は今回やらないのか、そこまで決めて初めて合意書として使えます。

なぜわざわざ文書にするの？

口頭で決めたことは、時間がたつと人によって覚え方がずれていきます。

例えばこんな会話、どこかで聞いたことがありませんか。

「月末の締め処理も自動になるって言いましたよね？」
「その話は聞いていますが、今回の範囲に入っていたかは記録がないんです」

こうしたすれ違いを防ぐために、決めたことを文字で残しておくわけです。

システム要件定義書・ソフトウェア要件定義書と、どう違うの？

「要件定義書」「システム要件定義書」「ソフトウェア要件定義書」と、似た名前が並んでいて混乱しますよね。

ここでは、IPA（独立行政法人情報処理推進機構）の「共通フレーム2013」という考え方を借りて説明します。

共通フレーム2013は、日本で広く使われている、開発の工程と言葉をそろえるための物差しです。

工程の並びで見ると位置がはっきりします

共通フレーム2013では、企画プロセスの次に要件定義プロセスがあり、そのあとにシステム要件定義、ソフトウェア要件定義と続きます。

要件定義プロセスは、利用者側の要件、つまり業務要件を決める工程です。

システム要件定義とソフトウェア要件定義は、それを開発側の技術的な要件に落としていく工程です。

小さな案件では、これらを一冊にまとめて「要件定義書」と呼ぶことも多いです。

大きなシステム開発の要件定義書では、業務側とシステム側で文書を分けることもあります。

ITの現場での呼び方は会社次第です

IT企業やSIer（システムインテグレーター）によって、同じ文書でも名前が違うことがあります。

『うちの会社の「要件定義資料」と、この記事の要件定義書は同じもの？』と迷ったら、名前より中身で比べてみてください。

業務の流れ、機能、非機能の要件、対象範囲が書いてあれば、役割としてはほぼ同じです。

RFPや要求仕様書とも混ざりやすいです

もう一つ混ざりやすいのが、RFP（提案依頼書）や要求仕様書です。

どれも「発注の前後に出てくる文書」なので、同じものだと思われがちなんです。

ざっくり言うと、要求仕様書は「こうしてほしい」、要件定義書は「こうすると決めた」、設計書は「こう作る」という順番です。

呼び方は会社によって揺れるので、社内の文書と照らし合わせるときは中身で確かめておきましょう。

違いを詳しく知りたい方は、要求仕様書と要件定義書の違いで比べています。

工程の違いをもっと詳しく知りたい方は、要件定義とは何かをまとめた記事もあわせて読んでみてください。

要件定義書には何が書いてある？よくある章立て

会社ごとに様式は違いますが、よく見かける章立てがあります。

初めて開く要件定義書でも、この並びを知っていれば迷いにくくなりますよ。

上の例はあくまで架空の題材です。

実際の章立ては案件の大きさで増えたり減ったりします。

機能要件と非機能要件は分けて書きます

機能要件は、システムが「何をするか」です。

非機能要件は、「どのくらいの品質で動くか」です。

『非機能って、何を書けばいいのか見当がつかない』という声はとても多いんです。

そんな時に頼りになるのが、IPAの「非機能要求グレード」です。

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

要件定義書と一緒に作る資料もあります

要件定義の工程で作るのは、要件定義書一冊だけとは限りません。

本文に全部を書き込むと読みにくくなるので、一覧や図は別の資料にして、要件定義書から参照する形がよく使われます。

こうした要件定義資料をまとめて「要件定義の成果物」と呼ぶこともあります。

成果物ごとの中身は、要件定義の成果物一覧でまとめています。

各章の具体的な書き方は、要件定義書の書き方で手順にしています。

読み手ごとに「どの章を見るか」は違います

要件定義書は分厚くなりがちなので、全員が最初から最後まで読むとは限りませんよね。

だからこそ、誰がどの章を見るのかを先に知っておくと、書く側も読む側も楽になります。

この表は、編集部が一般的な役割分担をもとにまとめたものです。

会社によっては一人が何役も兼ねることもあります。

読み手を意識すると、書き方が変わります

例えば、経営層が読む「背景・目的」に専門用語を並べても、意味が伝わりにくいですよね。

逆に、開発チームが読む機能要件に「使いやすくする」とだけ書いても、何を作ればいいか分かりません。

同じ要件でも、読み手で言い回しを変えます

一つの要件を、読み手に合わせて書き分けた例を見てみましょう。

題材は、架空の勤怠管理システムで「残業の申請を承認制にする」という要件です。

中身は同じでも、読む人が知りたい部分に焦点が当たっていますよね。

実際の要件定義書では、本文は開発チーム向けの書き方にして、背景・目的や概要の章で経営層向けの言い方を添える、という形がよく使われます。

レビューの場で役立つ使い方

レビューの会議では、読み手ごとに見てほしい章を先に伝えておくのがおすすめです。

「利用部門の方は業務要件の章を、情シスの方は運用の章を重点的に見てください」と一言添えるだけで、指摘の質がぐっと上がります。

良い要件定義書と、困る要件定義書はどこが違う？

要件の良し悪しには、国際規格の考え方が参考になります。

要求工学の国際規格 ISO/IEC/IEEE 29148 では、良い要件の性質として次のようなものがよく挙げられます。

『そこまで細かく書く時間はない』と感じた方もいるかもしれません。

ただ、ここを曖昧にすると、後の工程で確認や手戻りが増えてしまうことも。

要件定義書は、作った後も使われ続けます

要件定義書は、承認されたら引き出しにしまう文書ではないんです。

V字モデルという考え方では、左側の要件定義・設計と、右側のテストを対応させて見ます。

その中で、要件定義書の内容は、発注側が行う受入テストで「ちゃんと実現できたか」を確かめる基準になります。

何のソフトで作ればいいの？

要件定義書を作る道具に、決まりはありません。

文章が中心の章は文書作成ソフト、一覧が中心の機能要件や課題管理は表計算ソフト、業務フローは作図ツール、と使い分けている現場が多いです。

大事なのは、関係者全員が開いて読めて、最新版がどれか分かることです。

よくある相談に答えます

ここでは、要件定義書についてよく寄せられる相談を要約して、編集部の考えをお答えします。

機能要件と非機能要件まで書けているなら、中心部分はもうできています。

残りで抜けやすいのは、「対象範囲」「移行要件」「運用・保守要件」「未決事項」の4つです。

特に「今回やらないこと」を書いておくと、後から範囲が広がるのを防ぎやすくなります。

結論から言うと、会社や案件で決まっていることが多いので、まずは社内の過去の要件定義書を見せてもらうのが近道です。

決まりがない場合は、文章の章は文書作成ソフト、一覧は表計算ソフトにして、全体の目次から各ファイルへたどれるようにしておくと読みやすくなります。

はい、珍しいことではありません。

要件定義書に書いた要件は、受入テストやシステムテストで「できているか」を確かめる元になります。

一つずつの要件に「何をしたら合格か」を書き添えていくと、テストの観点が作りやすくなりますよ。

よくある質問

まとめ

実物の形を見てみたい方は、要件定義書の例とテンプレートで各章の記入例を確認してみてください。

あわせて読みたい

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

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

要件定義の成果物一覧と中身｜誰が承認していつ使うかの表つき