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

○○管理簿から、項目△△に替えて項目✖✖を追加する。

現在データ抽出の際に使用している○○マスタには、✖✖の項目がないため、新たに●●マスタを読み込み、△△に替えて○○管理簿に✖✖を出力する。

何を開発するのかについての内容を記載します。 ※コード単位の修正内容や新規内容など詳細については、「詳細設計書（各仕様書）」に記載されますので、要求仕様書内にはアウトラインのみの機能に留めて記載するようにします。 システム用途、対象ユーザー、ハードウェア構成、ソフトウェア構成、目標性能、制限事項　なども合わせて記載する。※ハードウェア構成、ソフトウェア構成やユーザーとシステムの関連図なども提示するとわかりやすい。 例）　・クライアントＡ社から受信したＢデータより作成された○○マスタと✖✖マスタの2つを読み込む。 　　　・読み込んだホストデータとマスタデータより○○管理簿のデータ生成を行う。 　　　・上記中間データより帳票出力を行い、他データとの連携を行う。 ここでは、通常の仕様書レベルまでの記載はしない（コーディングレベルまでは書かない）が、各プログラム（または処理毎）に分けて処理すべきことを書いた方が、プログラム毎に書けばそのまま指示書としても使えるので、このあと設計、プログラミングに入る人にわかりやすい。私のいた開発会社では、プログラム名等を洗い出して一覧にして、各プログラム毎に対応内容について記載しなければなりませんでした。

設計、仕様書作成、プログラミング、単体テスト、結合テストに分けて、それぞれの開発期間がわかるように示す。 矢印等の一覧で期間を表すなど、どの作業がどの程度の期間かかるのかをクライアント側にすぐにわかるようにすると良い。また、ユーザー確認テストの時期やリリース時期なども合わせて表示するとクライアント側も今後の計画を立てやすいので出来れば合わせて書いた方が良い。 （例） 3月　　　　　　　　　　4月　　　　　　　　　5月　　　　　　　　6月　　 設計　→ 　　　　仕様書作成　→　 　　　　　　　　　　　　プログラミング　→ 　　　　　　　　　　　　　　　　　　　　　　　テスト　→　　検証期間　　リリース

開発期間、必要な人数、など根拠をつけて算出する。 通常は、工程毎にどのくらいの費用がかかると提示する。 （例） 設計　　　　　０．3人月 プログラミング０．2人月 単体テスト　　０．３人月 結合テスト　　０．２人月 　　　　計　　１．０人月

ホストＢを使用して開発テストを実施。結合テスト終了後、開発環境で、ユーザー最終確認を行う。　　 ※実際は、環境に合わせて、利用する機材等含めてもっと詳細に記載する。

～～の場合は、✖✖の項目は抽出されない。 ある条件下では、出力されないことなどを記載。問題がある場合は、代替案も表示するとクライアント側も納得しやすい。

出典: 技術書をアイマスクにする新米プログラマー｜無料の写真素材はフリー素材のぱくたそ

システム開発においては、クライアントの要望を形にして開発側との合意を得るためや、その後その要求仕様書をもとに設計、プログラミングを行う指示書的役割のためにも要求仕様書の作成は必要ですが、ソフトウェア開発においては、その形態から要求仕様書が必ずしも必要ではないという考え方もあります。 通常のシステム開発では、ユーザーからの要望で開発方針が決められ、それに沿って要求仕様書が作られて、開発に移行していきますが、ソフトウェアの開発については、あらかじめ要求仕様書を作成したとしても、開発段階やテスト段階で当初の思惑と内容が変わっていくことが多々あります。 そのため、要求仕様書を事細かにきっちりと作ったとしても、後に修正を余儀なくされることがほとんどのため、あまり意味がないということです。但し、ソフトウェア開発の場合でも、要求仕様書を作成して、開発方針や目的を決めて開発要求者と開発担当者で意思確認するという点では意味があるといえます。ただ、通常のシステム開発の要求仕様書同様に詳細に記載したとしても、途中で方向性が変わっていくため、おおまかな方針や方向性確認にとどめておいた方が開発面でも縛られたり後戻りせずに済むことが多いです。