要求仕様書とは？書き方と例・要件定義書との違い

何を作るのか、のおおまかな内容を記載します。 ※詳細については、「詳細設計書（各仕様書）」に記載されますので、要求仕様書内にはアウトラインのみの機能に留めて記載するようにします。 ・システム用途　　　システムが利用されるシーンを想定し記載。 ・対象ユーザー　　　システムを利用するユーザーと利用環境を想定して記載 ・ハードウェア構成　システムを構成するハード（サーバ、ネットワーク、その他周辺機器）を記載 ・ソフトウェア構成　システム運用に必要なソフトウェア（ＯＳ含む）を記載 ・目標性能　　　　　達成すべき性能を列挙する。 ・制限事項　　　　　システム利用にあたっての制限事項を記載する。 　　　　　　　　　　※できないこと全ては書けないが、想定されるシーンにおいて、特に気に留めておいて欲しい内容について記載する。 要求仕様書に記載する機能一覧は、クライアント側にもわかりやすいように表にしたり、図で別途添付するなど工夫が必要です。システム側では周知の事実であっても、クライアント側では全く知らないことも多々ありますので、この機能一覧では、クライアント側の担当者が理解できるような図や一覧を提示しなければなりません。 文章で記載することも必要ですが、一目みただけで、全体的な機能のうちここが修正される、または機能が追加される、ということがわかれば、納得しやすくなります。

開発規模に応じて、プロジェクトマネージャー、プログラマ、テスト実行者　等の役割をコンポーネント（部品）毎に担当者を記載する。開発途中から参加してもらうユーザーも必ず定義します。クライアントいは設計段階から仕様チェックをしていただくことが基本ですが、仕様確認だけでは不十分な場合もあるため、最終段階での手戻りをなくすためにも途中にユーザー確認を行うことは重要です。 例）○○　-　プロジェクトマネージャー 　　△△　-　プログラマ　（✖✖担当） 　　△△　-　プログラマ　（○○担当　2017.2以降参加） 　　■■　-　仕様適合検査担当

着手時期、開発期間、テスト期間、リリース時期、運用開始時期について定義します。リリース時期は、開発規模に応じて、フェーズ1、フェーズ2のように区切ることもあります。 リリース時期と運用開始可能な時期は必ずしも同じではないため、ユーザー側の立場にもたって、記載する必要があります。 また、開発スケジュールについては、ある程度の余裕をもったスケジュールをとるべきです。あまりにキツキツなスケジュールをとってしまうと、クライアント側からの出戻りやユーザー確認による修正が入った場合に納期が大きくずれ込むことになります。例え、クライアント側からの要求で遅れる場合でも、クライアント側はできるだけ最初の納期にこだわる場合もあります。そういったことも見込んで、余裕のあるスケジュールを組むことは重要です。 また、テストについても単体テストから結合テストと移行することになっていくと思いますが、予定外の不具合が発生したり、テスト環境が整わなかったり、など環境面の障害が発生することも考えられます。さらに、大規模のシステム開発の場合は、テスト遂行者が単体と結合で別でスムーズに進まないなどの人的遅延も有り得ます。 以上のことから、後々に問題が起きた場合のためにも、クライアントも納得できる程度の余裕をもったスケジュールを組むことを念頭において記載した方が良いでしょう。

どういった環境の元、開発、テストを行うかを記載します。また、他システムとの関連がある場合は、その内容についても記載します。（データ受け渡しが必要な場合　など） 元となるデータをクライアント側から受け取る場合などは、そのデータの受け渡し方法についても記載が必要です。テストデータとして前もってもらう場合も、日程を決めておくと後々スムーズに進めることができます。

開発に必要な予算を記載します。私がいた開発会社では、人月という言い方を使っていました。1人月＝1人が1月分として、1人月あたりいくらという契約となっていました。各開発会社によって、書き方は異なると思いますが、予算は必ず記載が必要です。 また、要求仕様書を書く場合に、予算の計算もしっかりと行わなければなりません。全体的な修正規模（または新規作成規模）、単体テストのケース量、結合テストの規模、ほかにも環境整備等に必要な人数、期間などを全て洗い出し、正確に算出しなければなりません。ここで予算的にあまりにキツイ見立てを立ててしまうと、やはり自らの首を絞めてしまうことになります。また、予算はクライアント側から払ってもらうものですので、余計に見積もっても、クライアント側からの信用を損ねてしまいます。正確な予算を見積もり、提示することは、後々の取引にもつながってきますので、慎重に算出した方がいいです。

出典: 明るいオフィスでコーディング中のエンジニア｜無料の写真素材はフリー素材のぱくたそ

情報システムを構築する場合、または修正する場合に「要件定義書」「要求定義書」という似たような名前のものを作成します。似ている名前ですが、その意味合いは全く違います。「要件定義書」とは、「システム要件定義」の略で、「要求定義書」とは、正確に言えば「業務要求定義」「ユーザー要求定義」の略です。 要求定義書とは、システムを使っている側（エンドユーザー）側からの要望を書き留めたドキュメントです。つまり、エンドユーザーが、開発の結果得る機能をまとめたものです。一方、要件定義書とは、システム設計者側から見た、ユーザーからの要望に応えるために追加・修正した機能を書き止めたドキュメントです。よって、要件定義書の内容＝クライアントに確認する成果物であるとも言えます。但し、要件定義書の認識については、各システム開発会社によって、解釈が微妙に違っている場合があります。おおまかに、システム設計側からみた開発成果が書かれていると考えればいいと思います。

出典: ://

要件定義書は、ユーザー側からの要望に沿って合意のもとに、ユーザーが承認しやすい内容で書く必要があります。そのため、ユーザーが出した希望に沿って書かれた要求仕様書を元に作成されます。但し、要求仕様書がしっかりとした内容で、全て満たされた内容だった場合は、特に要件定義書を書かなくても良い場合も有り得ます。各開発会社の方針にもよりますが、要件定義書については、必ずしも必要であるわけではない（要求仕様書と同様な扱いとしている場合もあります）ということを認識しておいていただきたいです。

システム開発においては、クライアントの要望を形にして開発側との合意を得るためにも要求仕様書の作成は必要ですが、ソフトウェア開発においては、その形態から要求仕様書が必ずしも必要であるか否かという問題があります。ソフトウェア開発における要求仕様書を作成する際の問題点を以下にまとめたので参考にしてください。

出典: タイピングする手元：人気の写真まとめ｜無料の写真素材はフリー素材のぱくたそ

ここでは、あるシステム開発をした場合を想定して、例示としての要求仕様書を書いてみます。背景や開発内容やその規模によって、もっと詳細なものになることもあるかと思いますが、ちょっとした参考として見てください。