要件定義書と要求仕様書の違い

システム開発プロジェクトに加わると、「要件定義書」や「要求定義書」、時には「要求仕様書」といった言葉を聞く機会が増えます。では、「要件定義書」や「要求仕様書」は何の目的で作成されているのでしょう。両者の違いは何でしょうか？

システムエンジニアを目指す方は、それらの目的や意味、違いをしっかり押さえておく必要があります。ここでは「要件定義書」と「要求仕様書」の違いを題材として、システム開発の基本について解説していきます。

システム側であるシステム開発担当者が作成する「要件定義書」には、次の2つの側面があります。

1.クライアント側からの要求事項をとりまとめた「要求仕様書」の内容を実現するために、システムに必要な機能と実装方法を取りまとめたシステム仕様書 2.開発システムに求められている機能について、プログラムの機能・データベース・通信などを含めて定義した仕様書

「要件定義書」は、システム開発における基本設計や詳細設計のベースとなり、「クライアントの要求に応えるための羅針盤」と言えます。「要件定義書」には「機能要件」に加え、「非機能要件」としてシステムの性能・信頼性・拡張性・セキュリティなどを記述します。

機能要件とは？非機能要件との違いや書き方をわかりやすく解説

「要求仕様書」には次の2つの側面があります。

1.クライアントの要求、希望などを記述した仕様書 2.クライアントの要求や希望の中でも、システム開発で必要なものを示した仕様書

要求定義は「発注側として何を実現したいのか」を明らかにすることです。この漠然とした要求を、システム開発で実現する内容に落とし込み、ドキュメントにしたものが要求仕様書です。要求仕様書の作成主体はあくまでもクライアント側ですが、クライアント側に作成スキルがないケースでは、開発者側が作成するケースがあります。

これまでシステム開発の主流だった「ウォーターフォールモデル」では、クライアント側の「要求定義」を「要件定義書」で実現手段に置き換えて表現し、基本設計や詳細設計に引き継いでシステム開発を進めていました。

一方、最近主流の「アジャイルモデル」では、開発工程の境界が曖昧で、実際にシステムを作りながら、クライアント側の確認を取り、「ここはこうしてほしい」という要求を仕様書に記述していきます。アジャイルモデルではこれが「要求仕様書」であり、「要件定義」として表現を変えながら開発を進めていきます。

以上を整理すると、クライアント側の「ここはこうしてほしい」という要求定義を示したものが「要求仕様書」であり、システムに求められる機能、その実装方法を整理したものが「要件定義書」です。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

「要件定義書」と「要求仕様書」についてそれぞれ解説しましたが、他に「要求定義書」と呼ばれるものを用いることがあります。どちらも名称が似ていますが、「要件定義書」は正式に書くと「システム要件定義書」であり、「要求定義書」は「業務要求定義書」の略です。

クライアント側の要望内容を取りまとめた「要求仕様書」と呼ばれるものもありますので、それぞれの違いを押さえておきましょう。

■要件定義書 クライアント側の要望に沿い、「システムに対する要望内容はこれでよろしいですね」とクライアント側の合意、承認を得るためのもので「システム側」が作成します。

■要求定義書 システムに求める詳細の仕様や機能などをシステム側に伝える文書です。開発システムに対するオーダーが記載されており、「クライアント側」が作成します。

■要求仕様書 クライアント側の要望内容を書き留めたもので、本来はクライアント側が作成すべきものですが、システム側が作成するケースが多くあります。要求仕様書がシステム開発に必要な内容をすべて満たしていれば、要件定義書の代用となることもあります。

開発工程モデル

システム開発のプロセスにはさまざまなモデルがありますが、代表的な開発工程モデルである「ウォーターフォールモデル」と「アジャイルモデル」について改めて解説します。

「ウォーターフォールモデル」ではクライアント側は自らの思い、希望をRFP「Request for Proposal」（提案要請書）として表現し、システム側はその思いや希望を「要件定義書」に記述し、クライアント側の確認を取っていました。

一方、アジャイルモデルでは、都度「要求仕様書」の形でクライアント側の要求を記述します。つまりは、「要求仕様書」はアジャイルモデルにてよく利用される仕様書とも言えます。

RFP(提案依頼書)を作成するメリット、デメリットと活用方法について

RFPとRFIとの違いとは？エンジニアがシステム開発に活用するコツ

「ウォーターフォール」（Water Fall）は「滝」のことです。滝のように上から下に向かって流れるイメージの通り、「ウォーターフォール」は工程を細かく分けて、上流工程から下流工程へと順番に進めていく開発手法です。

ウォーターフォールモデルのメリットは、1つの工程が完了した後に次の工程に進むため、状況の把握や進捗管理が比較的行いやすい点です。そのため、品質をある程度担保できるのもメリットの1つです。

一方でデメリットは、システムに不具合が発見されると、そのリカバリーに時間やコストを要する点です。さらに要件定義や基本設計まで遡って修正する必要が生じると、大幅な納期遅延が発生し、多大なコスト増となります。

ウォーターフォールモデルおいては、途中で不具合が発生すると、以降の工程に進めないことから、スピードが求められるシステム開発には不向きと言われます。

「アジャイル」（agile）は「俊敏」を意味する英語で、スピードを優先するプロジェクトに適した開発工程モデルです。「アジャイルモデル」では、作るシステムの概要が決まったらすぐに開発工程に入り、機能ごとに「計画→設計→実装→テスト」のサイクルを繰り返しながら開発を進めます。

ウォーターフォールモデルでは後戻りがないという前提で工程が進められますが、アジャイルでは後戻りを前提として工程が進められるため、設計工程では詳細は決めず、全体を作る中で必要に応じて修正が行われます。

アジャイルモデルのメリットは開発スピードの速さですが、工程の進捗、状況の把握が難しく、管理しにくいのがデメリットです。

アジャイル開発のメリット・デメリットや代表的な手法について解説！

要件定義書についてより詳しく

要件定義書の作成には、開発プロジェクトのリーダーやディレクター、エンジニアなどのプロジェクトを指揮する人が中心となり、開発プロジェクトを進める上で必要な項目を列挙していきます。それらの内容を「要件定義書」に落とし込んで、関係者に周知徹底を図ります。では、この要件定義書について、より詳しく見ていきましょう。

要件定義と基本設計は混同されがちですが、工程は異なります。基本設計は要件定義をより明瞭化するフェーズに当たります。具体的にはアウトプットとして、業務フロー図・機能一覧・画面遷移・画面レイアウト・インタフェース一覧などの実際のシステムの根幹部分の仕様を決定するのが基本設計フェーズです。

要件定義書はシステム開発において要となる重要なドキュメントですが、その内容についてはシステムの特性や規模、企業などによってまちまちです。ここでは必要最低限の内容について記載していきますので、テンプレート的なものやサンプルが必要な方は以下のサイトを参照してください。

【参考】： IPA公式サイト_超上流から攻めるIT化の事例集：要件定義

1.システムに関する記載 要件定義書にはまず、どんなシステムを作るのかが分かるように、システム概要・システムの導入目的・業務フロー図などのシステム関する記載を行います。

システム概要では、業務要件は顧客視点で、システム要件は開発視点で記述します。

導入目的は、顧客目線で記述することにより、顧客要望が浮き出されます。このシステムによってどのような顧客要望が実現できるのかを説明します。

業務フロー図はシステム導入前と後の変化を分かるように意識します。このことで、システムの必要性がより客観的に理解しやすくなります。

2.機能要件に関する記載 機能要件はすなわちクライアントの要求内容そのもので、これがプロジェクトのゴールとなります。開発プロジェクトの初期段階で共有される機能要件は、システムのゴールについてクライアントと合意形成を行い、開発プロジェクト計画を承認してもらう上で重要なものとなります。あいまいさを払拭し、より鮮明で具体的であることが求められます。

3.非機能要件に関する記載 機能面以外の要件を非機能要件と言います。ここは、RFPに明記されていなければクライアントから具体的に示されることは少なく、最初は漠然としています。とは言えシステムの出来栄えに関わる重要な要件であり、クライアントの合意が必要です。

たとえば、システム稼働後に「レスポンスが遅い」「セキュリティに脆弱性が見つかった」などとして、時には損害賠償請求を受けることがあり得ます。

非機能要件は、機能要件と同様に重要で、機能要件が固まり次第非機能要件を決定します。非機能要件では、システムの性能、セキュリティや保守・運用サービスなどについて記載し、プロジェクトのゴールをより明確にしていきます。

プロジェクトの成否を左右する非機能要件の一覧について詳しく解説！

機能要件の書き方に強くなり、優秀なITエンジニアを目指そう

要求仕様書についてより詳しく

システム開発では大きな役割分担としてSE（システムエンジニア）が設計を行い、その設計書に基づいてプログラマーがプログラムを作成する形でシステム開発が進められます。要求仕様書にはシステム開発の全体の指示書的としての役割があります。

要求仕様書は特に定型フォーマットが決まっていませんが、システム設計書や仕様書が作成されることを踏まえて、システム設計に必要なことが細部まで記述されている必要があります。

【参考】：厳密な仕様記述入門（IPA）

システムエンジニア（SE）とは？仕事内容や年収、必要スキルを解説！

要求仕様書とは、クライアントがシステム開発側に対して開発を依頼する際のシステム要件を文章化したもので、要望や要求事項・予算・リリース目標などが主で、具体的な実現方法は書かれていません。クライアント側にシステム開発に強い担当者がいれば、要求仕様書はクライアント側で作成すべきですが、そうでない場合は、開発担当側の関与が必要になる場合があります。

要求仕様書に記述が必要な項目は、概ね以下の通りです。

1.システム化の目的 何のためにシステムを開発するのか、その効果はどの程度なのかを具体的に記載します。

2.基本方針 システム開発に関する基本方針を記載します。 設計方針やテスト方針などを記載します、

3.機能一覧 おおまかな機能について記載をします。詳細機能は詳細設計書などの仕様書に記載されるため、要求仕様書では機能のアウトラインを記載します。 

▪システムの用途：システムの利用シーンを想定して用途を記載  ▪対象のユーザー：対象となるユーザーと利用環境などを想定して記載 ▪ハードウェア構成：サーバ・ネットワーク・周辺機器などの実装仕様を記載 ▪ソフトウェア構成：必要なソフトウェア・OS・ミドルウェアなどの実装仕様を記載 ※実装仕様とはコンピュータ、ストレージデバイスなどの実際のハードウェアやオペレーティングシステムなどのこと ▪目標性能：達成すべきシステム性能を挙げる

要求仕様書に記載する機能一覧は、開発側及びクライアント側の両者に分かりやすく、図表などで示すなどの工夫をします。用語などにも注意し、クライアント側の担当者に理解しやすいレベルを意識しましょう。

4.その他 要件定義書に代わるものとして要求定義書を用いる場合には、開発体制・開発スケジュール・開発環境・開発予算などの項目も網羅します。

システムエンジニアの役割

ここまで、要件定義書と要求定義書、要求仕様書について解説してきました。システムの開発における要件定義とは、エンジニアがシステム構築のために定義する仕様のことであり、要求定義とはクライアントがシステム（エンジニア）に対して求める仕様の定義のことです。

要件定義はシステムの基本設計者や詳細設計書の元となり、要求定義はビジネスに関する基本設計や詳細設計、オペレーションなどが主となります。言葉が似ており、混同しやすいところですが、システムエンジニアはクライアントと開発側の橋渡し役でもありますので、その自覚を持ち、正しい知識を得た上でシステム開発を進めてください。

システムエンジニアがキャリアアップするのにおすすめの資格を解説！

システムエンジニアは文系者が向いている？理由やキャリアパスを解説！