要求仕様書の書き方
ユーザー要求仕様書
作成目的
システムの要求事項を導き出して発注者と内容を合意し、一つの業務単位として価値を持って遂行できる業務を導き出して業務内容を記述します。
作成方法
様式の表を用いて当該項目に記述し、理解しやすく具体的な言語表現を用いる。 機能的要求事項と非機能要求事項をグルーピングし、別表として作成する。
項目説明
例）現金入出金システム
要件ID
要件別で唯一のIDを付与
要件名
導出された要求事項を要約できる名称を記入
区分
導出された要求事項を機能 / 性能 / 品質 / インタフェース / データ / 運用 / 制約事項の中から選択して記載します。
要件説明
ユーザー要件を具体的かつ詳細に記述します。
重要度
その要件のシステム全体の実装の側面での重要度を記述します。 （上、中、下）
備考
項目には含まれませんが、考慮すべき事項があれば記述します。
画面定義書
テーブル明細書
API明細書
APIを定義する際、Webアプリケーションは通常、RESTfulなAPIを定義して実装します。
RESTfulなもののためには、リソース（Resources）とURIについて簡単に知っておく必要があります。
リソースは、メディア、DB データなど、すべてのリソースを意味します。 つまり、RESTfulなAPIとして通信する際に期待する結果値に該当するリソースの一体を意味します。
scheme:[//[user[:password]@host[:port]][/path][?query][#fragment]
scheme
httpまたはhttps を使用します。
user, password
データがあるサーバーにアクセスするために必要なIDとPASSWORD
host, port
サーバーのホストとポート番号
path
サーバーの詳細経路
query
pathにアクセスするための追加情報(パラメータ)
fragment
メインリソース内に存在するサブリソースにアクセスする際に識別するための情報
RESTfulなAPIとは、すべてのリソースに対して固有のURIを付与し、HTTP Methodを適切に使用してリソースを制御できる手段です。
この時、要請に対する応答はJSONやXMLのような事前定義された形式を使用して一貫した方法でやり取りします。
RESTAPIルール
HTTP Method
GET:Queryの「SELECT」に該当する。
POST:Queryの「INSERT」に該当する。
PUT:Queryの「UPDATE」に該当する。
DELETE:Queryの「DELETE」に該当する。
要求事項の定義がきちんと行われないと、このような状況が発生する可能性があります。
Discussion