こんばんは、小谷田です。今日はUSDM形式の要求仕様書が良いというお話です。

USDMって？

　Eureka Boxさんから引用させて頂きます。

　清水さんが書かれたこちらの本に詳しく書いてあります。私はこちらの本を読みUSDMを知りました。

　さて話を戻します。Eureka Boxさんの文の中にUSDMとは「要求仕様を定義するための技法」とあります。

要求仕様って？

　私なりの言葉で言うと『システムとしてのあるべき姿(要求)を細かく定義したもの』です。

　要求とはECで言うと「買い物かごが欲しい」、そちらにまつわる仕様は「買い物かごには商品を20個まで入れることができる」「その場で買わない場合はユーザーが消すまで買い物かごの中に商品を持っておく」などです。

　清水さんの本では要求仕様とはイコール『要件定義』と同義として紹介されています。開発をされている方は要件定義という言葉の方が馴染みがあるかもしれません。

USDMのポイント

　フォーマットやメリデメは上記Eureka Boxさんのページに記載がありますので、今回は私がサマリーしたポイントをご紹介します。

• いきなり仕様を考えず、上位概念である要求に立ち戻って要求を考える。そうすると思いつかなかった仕様が見えてくることもある

• 要求の理由を考える。なぜその要求が出てきたのか。理由から仕様が導き出されることもある

• 要求は文章で書く。その文章の動詞が仕様である。なので要求が仕様の範囲を決める

• 仕様は、その仕様を見てプログラマーがソースをかけるレベルまで落とし込んで書く。ある意味手順書に近い

• 条件やパターンなどは＂＜タイトル＞＂で分けて見やすく書く

　これらがポイントだと思います。

機能仕様書と要求仕様書の違い

　機能仕様書は「このボタンを押すとこうなる」など最終的な動きを書くもの、要求仕様書はその最終的な動きを導き出すための過程を表現するもの、という違いがあります。

　ざっくりの例です。

• 最終的な動き(機能仕様)
  「★を押すと表示している商品がブックマークに登録される」

• そこまでの過程(要求仕様)
  「★がタップされたら、その商品の品番、画像URL、商品URL、★がタップされた日時をDBのブックマークテーブルに登録する」

　みたいな感じです。

USDMで書いてみた感想

　上記のポイントを意識して書くと、細かいところまで思考が行き渡るようになり、より詳細な仕様を書くことができるようになりました。

　それまでは機能仕様(最終的な動き)を書いていたのですが、そうするとエンジニアさんがその過程を読み取る必要があり、意図が正しく伝えられず実装や試験フェーズで手戻りが発生する、というケースもありました。

　USDMは上記ポイントで書いた通りある意味プログラムの手順書なので、書くために必要な情報や条件をあらかじめ深く考えることができます。っというか考えないと書けません。

　その分検討に時間がかかりますが、開発や試験の後工程も含めて考えた時には全体的に効率は良くなりますのでメリット大です。

　開発に携わっている皆さま、良ければお試しください。

　以上『USDMの要求仕様書が良い！』でした！