up:: Programming
Universal Specification Describing Manner。
万人に伝わる仕様を描写する作法。
表記法だけでない
TDDチックにいうならテスト以前、そもそもテストで満たしてほしい要求。そしてそこから導かれる仕様。これを伝えるための決まり。
仕様は要求に含まれる動詞と目的語から導かれる。
affordd_conference2015_tutorial.pdf
要求の開発は3つの要素がある。要求の発見、要求の表現、要求の洗練。
USDMはこのうち要求の表現を軸にしつつ、他にも少しはみ出る辺りをカバーするもの。
最近は要求の発見に注視しがち
その要求の表現をはっきりさせないと、要求からの仕様に抜けや漏れが生じる
あと形を決めとくと思考が楽
一般に要求まとめと仕様書は別文書
USDMでは要求と仕様を表現上で分ける
- 要求
- 目的
- 振る舞いで表現する
- 仕様
- 作る物の具体的な記述
- ソースコードへの直接変換
- 関係者間でSpecify（特定）できるもの
- 依頼者は完成イメージを特定
- 設計者は何を作るべきかを特定
- 検証者は何をどう確認すべきか特定
USDMは範囲や階層化を使用する
階層化はTodoアプリでよくあるサブタスク的概念、これで仕様が漏れにくい
範囲はクラス的概念、あるメインの要求すなわち振る舞いが求める変更の範囲をそのサブ要求とともに纏める。そのまま階層化できる。
大切な事、要求は 理由を付ける
別にいうなら背景、これは依頼者の出力や設計者の入力よりは変化しにくく、要求の意味を理解しやすくしてくれる
仕様は 要求（振る舞い）の中の動詞や目的語に存在する
全ての動詞と目的語を引き出し、動詞に対して使用グループを作成する。そのままプログラムになるくらいまでやること。
USDMで作成する要求仕様書
そのフォーム
要求一個に付き1つ作る
- キーワード
機能を示す用語や別名、メインネーム - 要求
実現してほしい振る舞い表現。ゴールの明確な記述。固有IDを振っておく。 - 理由
要求の理由 - 説明
動きの事例、前提事項、用語定義など
ソースコードのコメント - 仕様
実現すべき具体的な動きや制限
固有IDを要求と関連付けて振る - グループ
要求や仕様が多い場合、小さく分割して範囲を限定する - 仕様ラベル
要求と区別するためのラベル、固有ではない
□□□にしとくとステータス管理できて便利
要求仕様書と機能仕様書は別
要求仕様書は作るためのもの、機能仕様書は機能を説明するもの
前者は定義書に近く、後者は製品説明書に近い
でも定義だとspecify（特定）できないので仕様書
- USDMは要求表現の決まり事
- 要求は仕様を生む。仕様はプログラムになる
- 要求は理由が必要
- 仕様は要求の動詞や目的語から作る
要求は機能や性能、作り方に対する品質も含む
why - ビジネス要求
what - 要求開発技法（表現ではない）
how - システム要求
システム要求がUSDMの想定
その中でハードウェアソフトウェアなどもあるが、それらにもそれぞれUSDMが使える
というか分けて使ってシステム→サブシステム→ハードソフトと深めていくのが想定
USDM表記におけるキーワード
- 動詞に着目
- 範囲を明確化
- 理由を明記
- 詳細化の為の階層化
- 範囲を狭めるための分割
- 範囲を狭め、粒度を調整するためのグループ
動詞
振る舞いに含まれる動詞と目的語を全て表現する
タイトルや名詞＋するだけでは要求として曖昧
範囲
どっから何処までを対象に作るか
理由
要求と必ずセット
目的ではない、それは要求になるので
特定の動詞への理由だったり
必要かつ有効な仕様
設計上の工夫
非機能要求が理由になることも
要求の洗練
思い込み、不純な要求の排除
階層化
抽象度が高いなら階層化で下げる
時系列で並べると分かりやすい、ユースケースシナリオ
深すぎると読みにくい、2階層までが理想
グループも併用
深くなる場合は別レベルの要求が紛れてるかも
分割
ルールは4つで明確、これは明確じゃないと漏れる
- 時系列分割
- 構成（機能）分割
- 状態分割
- 共通（部分）分割
階層化はこのひとつ
グループ
分割した要求を分かりやすいように共通項でグループ化
グループ名は目的語を意識、名詞で記述
一応<>で括ると決まっている
グループ分けにも分割基準を用いる
仕様
設計者は実現可能性を、評価者は検証可能性を仕様から見る
品質要求も仕様を決める
さっきまでのは要求
仕様は動詞単位で作り、グループとしてまとめる
隙間を作らない
よく詳細化しすぎるが、specify（特定）できるレベルまでにする
何をどのように、と悩むならそれは仕様書たりえない
これは開発者のレベルにもよるので、それぞれに合わせてそれぞれの要求部分を作る
仕様にも理由や説明を付けることがある
要求からわかるならいらない
ソースコードにはしない
仕様から要求を修正することがある
書いてる間に思いついて適当に追加しちゃう奴
仕様と要求が理由を共有していない状態
対応
- 仕様が収まる要求を探す
- 要求と理由の表現を変え、仕様を受け入れる
- 新たに要求と理由を設定して移動
要求への新規追加
要求の変更
要求の新規追加
これは全然悪いことじゃない
むしろ仕様の欠如に気づくことがあるのでよい
依頼者の要求と要求仕様の混在
依頼者のあげる具体的な例（具体的なふるまい）、これは仕様になる
要求がないのに仕様だけ置かれる、あげた仕様は実際は別の要求に含まれるなどなど
いったん仕様に直接書いてインタビューで要求と理由を探す
つまり仕様から要求を立てるというのはよくあること
日頃から練習しろ
仕様禁止事項
-
コピペ
読みにくい
代わりに表や図やチャートを使うなどしてコピペを消す -
否定表現
条件分岐は逆側をしっかり記述 -
等
具体的に列挙する
暫定仕様
最後が詰め切れないときは、それと分かってることを明示して暫定で進めるという方法
期限を決め、それでも分からないなら分からないと明記、かつ若田ていることを全て明記
あとから決まったら要件管理で対応
認定仕様
まだ要求だけど、動詞の時点で既に仕様として使えるケース
これは認定しようとして容認する、spec効くからヨシ
この下に仕様を展開しないよというマーク
- 要求
- 動詞
- 仕様
- 範囲
- 理由
- 階層
- 分割
- グループ
- 動詞
- 仕様からの要求
- 禁止事項
- コピペ
- 片道条件分岐
- 等
- 暫定仕様
- わかってることを明記
- 暫定であることを明記
- 認定仕様
- 仕様にできる要求
画面仕様
画面の為にUSDMを使う、画面仕様書
画面遷移図、画面構成
画面共通要求仕様、個別画面の要求の方向性
個別画面要求仕様、個別画面ごとの要求と仕様
画面遷移図
状態の一種
状態遷移の4つの要素、画面状態、遷移、イベント、アクションで正確に表現
これは操作システム設計所の構成要素、イメージだけでは使えないのでしっかり作る
全体を俯瞰できるように、出来る限り1ページで
多いなら階層化