当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内（広告）を含みます。
『要求仕様書を作って』と言われたけれど、要件定義書と何が違うのか分からない。そんなモヤモヤを抱えたまま、打ち合わせに出ている方も多いはずです。
結論から言うと、要求仕様書は「システムに何をしてほしいか」を、作る人に伝わる形で書き出した書類です。要件定義書とは重なる部分が大きく、現場によっては同じ書類を指していることもあります。
この記事を読めば、言葉の違いと、要求仕様書に書く項目がひと通りつかめます。
要求仕様書とは？何を書く書類か
要求仕様書とは、システムやソフトウェアに求める機能・性能・制約などを、関係者が同じ意味で読めるように書いた書類です。英語では requirements specification と呼ばれます。
国際的な用語の規格 ISO/IEC/IEEE 24765:2010 では、requirements specification を「システムや部品に対する要求を定める文書」という意味で定義しています。中身には、機能や性能、外とのつなぎ方、設計上の制約などが入るとされています。
ソフトウェアに絞った書類は、SRS（Software Requirements Specification）と呼ばれます。昔からよく知られている手引きが、IEEE 830-1998 です。
IEEE 830-1998 はすでに置き換えられていて、後継は ISO/IEC/IEEE 29148 です。日本では JIS X 0166:2021 が、この規格の2018年版に対応しています。
JIS X 0166:2021 の目次には、要求の仕様が3種類並んでいます。
| 呼び方（略称） | 誰の目線の要求か |
|---|---|
| 利害関係者要件仕様（StRS） | 使う人・発注する人など、関係者が求めること |
| システム要件仕様（SyRS） | システム全体として満たすこと |
| ソフトウェア要件仕様（SRS） | ソフトウェアとして満たすこと |
つまり「要求仕様書」とひと口に言っても、誰の目線で書くかで中身が変わるんです。ここが大事なところです。
例えばこんな場面で使われる
社内の勤怠管理を新しくする時、総務の担当者が「残業申請をスマホから出せるようにしてほしい」と書き出す。これが要求の出発点です。
それを開発会社に渡して「この内容で見積もってください」と頼む時の書類を、要求仕様書と呼ぶ会社もあります。
要求・要件・仕様を3段で考える
「要求」はしてほしいこと、「要件」は実現すると決めたこと、「仕様」は作り方の約束です。この3段で考えると、書類の名前に振り回されなくなります。
『要求と要件って、結局同じじゃないの？』と感じますよね。実は、IPAの解説「要件定義とは？」でも、要求と要件の標準的な定義は無いと書かれています。
そのうえでIPAは、要求を「ビジネス要求」と「システム化要求」に分けています。そして要件は、要求を文書にして関係者と合意したもの、という説明です。
この記事では、次の3段に分けて考えてみますね。
| 段 | ひと言でいうと | 例（勤怠システム） | 決まる時期 |
|---|---|---|---|
| 要求 | してほしいこと | 残業申請をスマホから出したい | 企画・ヒアリングの時 |
| 要件 | 実現すると決めたこと | スマホのブラウザから申請と承認ができる | 要件定義で合意した時 |
| 仕様 | 作り方の約束 | 申請画面の入力項目、承認の順番、通知の出し方 | 設計の時 |
要求がそのまま要件になるとは限らない
要求はたくさん出ますが、全部を作るわけではありません。予算や期間と照らして、やる・やらないを決めたものが要件になります。
「スマホで申請したい」と「紙の申請も残したい」が両方出たら、どちらを残すか話し合いますよね。その合意の結果が、要件として書類に残るわけです。
要求を書き出しただけで「要件が決まった」と思い込むことです。合意していない要求は、あとで「それは頼んでいない」「それも入っていると思った」の食い違いになりやすいので、合意した日と相手を残しておきましょう。
要求仕様書と要件定義書の違い
要求仕様書は「求めること」を出す書類、要件定義書は「実現すると決めたこと」をまとめる書類と考えると分かりやすいです。ただ、現場ではほぼ同じ意味で使われることも多いです。
要求仕様書と要件定義書の違いは、上の3段のどこに重心があるかです。要求寄りなら要求仕様書、合意した要件寄りなら要件定義書、という呼び分けが多いですね。
- 発注側の「してほしいこと」が中心
- 開発会社に見積もりや提案を頼む時に渡すことがある
- まだ実現できるか決まっていない項目も入る
- 合意した「実現すること」が中心
- 開発の土台として、設計やテストの元になる
- 未確定な項目は、未確定だと明記して残す
デジタル庁のデジタル・ガバメント推進標準ガイドラインでは、要件定義書に業務要件、機能要件、非機能要件、システム方式の4つを書くとしています。未確定な要件はリスクになり得るので、その旨を要件定義書で明らかにする、という決まりもあります。
要件定義書の中身や作り方は、要件定義書とは？目的・書く内容・作る流れで詳しく紹介しています。
要求定義書と要件定義書の違いは？
『要求定義書という名前も見かけるけど？』という方もいますよね。要求定義書と要件定義書の違いも、考え方は同じです。
要求をまとめて定義した書類が要求定義書、合意した要件をまとめたのが要件定義書です。ただし、社内で呼び名がそろっていないことも多いので、受け取った書類の中身を見て判断するのが確実です。
もっと広く、要件定義書と仕様書全体の違いを知りたい方は、要件定義書と仕様書の違いも読んでみてください。
要求仕様書と機能仕様書の違いは？
要求仕様書は機能・性能・制約などをまとめて書く書類で、機能仕様書はそのうち「機能が何をするか」を細かく書く書類です。機能仕様書は、要求仕様書の一部として扱われることもあります。
ISO/IEC/IEEE 24765:2010 では、functional specification を「システムや部品が果たすべき機能を定める文書」としています。そして注記で、要求仕様の一部であることが多いと書いています。
要求仕様書と機能仕様書の違いを、範囲で比べてみましょう。
| 書類 | 範囲 | 書き方の細かさ |
|---|---|---|
| 要求仕様書 | 機能、性能、使いやすさ、セキュリティ、制約などの全体 | 「何を満たすか」が分かる程度 |
| 機能仕様書 | 機能ごとの入力・処理・出力・例外 | 作る人とテストする人が同じ動きを想像できる程度 |
例えば「残業申請を承認できる」は要求仕様書の1行です。機能仕様書では「承認ボタンを押したら、申請者に通知が届く。差し戻しの時は理由の入力を必須にする」まで書きます。
機能仕様書の書き方は、機能仕様書とは？書く項目と書き方でまとめています。
要求仕様書に書く項目と書き方
要求仕様書は「目的と範囲」「機能の要求」「機能以外の要求」「制約と前提」「未確定の事項」の順に書くと、抜けが少なくなります。
決まった様式はありませんが、デジタル庁の要件定義書の項目や、JIS X 0166 の考え方を参考にすると、次のような目次にまとまります。
| 章 | 書くこと | 書き方の例（架空） |
|---|---|---|
| 1 目的と範囲 | なぜ作るか、どこまでを対象にするか | 勤怠の申請と承認を紙からシステムへ移す。給与計算は対象外 |
| 2 業務の要求 | 今の業務の流れと困っていること | 申請書の回収に毎月時間がかかっている |
| 3 機能の要求 | システムにしてほしいこと | 残業・休暇の申請、上長の承認、差し戻し |
| 4 機能以外の要求 | 速さ、使いやすさ、セキュリティなど | 外出先のスマホからも使える。社外の人は見られない |
| 5 制約と前提 | 予算、期限、使える環境 | 今の社員番号をそのまま使う |
| 6 未確定の事項 | まだ決まっていないこと、決める人と期限 | 承認の段数は来月の部長会で決める |
機能以外の要求は抜けやすいところです。IPAの非機能要求グレード2018では、大項目を可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つに分けています。詳しくは非機能要件とは？をどうぞ。
伝わる書き方のコツ
1つの要求は1文で書き、「〜できること」で終えると読みやすくなります。「なるべく早く」「使いやすく」のような、人によって受け取り方が変わる言葉は避けましょう。
「画面はなるべく速く表示してほしい」
「申請一覧の画面は、ふだん使う時間帯に待たされないこと。目安は開発会社と相談して決める」
後ろの書き方なら、何を相談すればいいかがはっきりしますよね。
- 目的と、対象にしない範囲が書いてある
- 1つの要求が1文になっている
- 機能以外の要求（速さ・セキュリティなど）が抜けていない
- 決まっていない事項に、決める人と期限が書いてある
- 要求ごとに番号が振ってあり、あとで追える
外部の会社に提案を頼むなら、要求仕様書を土台にRFP（提案依頼書）を作る流れもあります。RFP（提案依頼書）とは？で、関係を確かめておくと安心です。
要求仕様書でよくある相談
相談で多いのは「要求と要件は同じか」「ヒアリングした内容をどの書類に書くか」の2つです。どちらも、書類の名前より「合意したかどうか」で考えると答えが出ます。
よく寄せられる相談を、内容をまとめた形で紹介します。
相談1：要求定義と要件定義は何が違う？
システム会社に入ったばかりで、上司に要件定義を勉強しておくよう言われた。調べると要求定義という言葉も出てきて、違いが分からない、という相談です。
先ほどの3段で考えると、要求定義は「してほしいこと」をまとめる作業です。要件定義は、それを実現すると決めて合意する作業ですね。
IPAの解説でも標準的な定義は無いとされているので、まずは職場でどう呼んでいるかを先輩に聞いてみてください。
相談2：ヒアリングした内容は要求仕様書？要件定義書？
お客さんへのヒアリングを元に書類を作る時、それを要求仕様書と呼ぶのか、要件定義書と呼ぶのか迷う、という相談もあります。
聞き取ったままの段階なら、要求をまとめた書類に近いです。お客さんと内容をすり合わせて合意したら、要件定義書として固めていく流れになります。
相談3：要件定義書と要求定義書は同じもの？
要件定義書と要求定義書は同じか別物か、というシンプルな相談も見かけます。
呼び方は会社やプロジェクトで違うので、同じ書類を指していることもあります。名前で迷ったら、表紙と目次を見て「合意した内容か」「出てきた要望の一覧か」を確かめてみてください。
要求をまとめる経験はどこで活きる？
要求仕様書を書く経験は、システム開発の上流工程そのものです。発注側でも開発側でも、評価されやすい経験になります。
IPAの「超上流から攻めるIT化の原理原則17ヶ条」には、「要件定義は発注者の責任である」という一文があります。発注側で要求をまとめる人も、開発側で聞き取って形にする人も、どちらも大事な役目なんです。
- 部署の要望を聞き取って一覧にした
- あいまいな要望を、確かめられる言葉に直した
- 決まっていない事項を、期限つきで管理した
今の職場で経験を積むのも、資格の勉強をしてから動くのも、もちろん正当な道です。そのうえで、要件定義や設計を任される仕事に進みたい方は、求人の仕事内容を比べてみると道が見えてきますよ。
IT・Webエンジニアの転職（PR）
仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる
要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。
無料ITエンジニアの求人を探す求人の条件・待遇は各求人票と応募先の案内でご確認ください。
よくある質問
要求仕様書とは何ですか？
システムやソフトウェアに求める機能・性能・制約などを、関係者が同じ意味で読めるように書いた書類です。英語では requirements specification、ソフトウェアに絞ると SRS と呼ばれます。
要求仕様書と要件定義書の違いは何ですか？
要求仕様書は「してほしいこと」を出す書類、要件定義書は「実現すると合意したこと」をまとめる書類と考えると分かりやすいです。現場によっては同じ意味で使われるので、中身で判断しましょう。
要求仕様書は誰が書きますか？
発注側が自分たちの要望をまとめて書くことが多いです。開発側が聞き取りをして書き、発注側が確かめる形もあります。
要求仕様書と機能仕様書はどう違いますか？
要求仕様書は機能・性能・制約など全体をまとめた書類で、機能仕様書は機能ごとの動きを細かく書いた書類です。機能仕様書は、要求仕様の一部として扱われることもあります。
まとめ
- 要求仕様書は、システムに求めることを伝わる形で書いた書類
- 要求はしてほしいこと、要件は決めたこと、仕様は作り方の約束
- 要件定義書とは重なりが大きく、合意の有無で考えると分かりやすい
- 機能仕様書は、要求のうち機能の動きを細かく書いた書類
- 未確定の事項は、決める人と期限を書いて残す
コメント