Red > Green > Refactor > Red

cycle is based on desire

仕様と設計の違い

f:id:mat5ukawa:20160817231309p:plain

将来どこかで誰かに

「仕様と設計を混同した時はこれ見といてね」と

言えることを念頭において書いた記事

「仕様」 と 「設計」 は別物

私なりの言葉で定義すると

仕様

= 作るものについて、満たされているべきことが定義されたもの

満たされているべきこととは「顧客が期待している結果」と「期待していない結果」のことだ

あなたが SE ならばこの定義について顧客と合意形成を取るべきだ

設計

= 仕様をどう実現するかが具体的に明確化されたもの

設計を基に SE と PG で意思疎通を図る

具体的な手段(モノ)として設計書がある


具体例を挙げるのでおおよその感覚を掴んでいただければ幸い

(突っ込み所は色々あると思うがスルーでお願いしたい)


例 - 顧客からのブログ Web アプリ作成依頼

あなたは SE だ(時には PG だったりする)

ある顧客から実現したいことについて依頼を貰った

依頼内容

弊社内で完結させる、ブログ Web アプリが欲しい
直近で (1) を実現してほしい

(1) タイトル・内容
    を投稿できる画面を作る

補足しておくと
  今考えている画面総数は 3 つ
    記事を投稿できる画面
    記事の一覧を表示する画面
    記事の内容を確認する画面
(資料を添付するので見ておいてください)

添付資料

f:id:mat5ukawa:20160817231232p:plain

顧客の依頼内容は「作るものがどうあるべきか」を示した「仕様」だ、「設計」ではない

「設計」はまだだ

あなたは「ご依頼を一度預かります」と伝え、依頼内容を確認する

「この依頼内容でシステムへ落とし込めるが、幾つか顧客が期待する結果を聞かないといけない」

と考えた

そう、入力制限がないことに違和感を覚え始めているはず

依頼内容を精査し、顧客に次の質問を持ちかけた

  • タイトルの文字数はいくつまで可能? (これは仕様だ)
  • タイトルは未入力を許してよい? (これも仕様だ)
  • 内容の文字数はいくつまで可能? (仕様だ)
  • 内容は未入力を許してよい? (これも)

その結果こうなった

(1) タイトル・内容
    を投稿できる画面を作る
(1) - 1
    タイトルは 255 文字まで
(1) - 2
    内容は 1,000 文字まで
(1) - 3
    タイトルのみ
    未入力、空白記号のみの入力で投稿はできないようにする

繰り返しになるが、これは「仕様」であり、実施していたのを仕様を決める行為だ

「設計」は一つもやっていない = 仕様をどう実現するかの具体化は、まだ何もやっていない

仕様を決めていた

f:id:mat5ukawa:20160817231450p:plain

ここからようやく「設計」だ

仕様で決まったことをどう実現するかを具体的に明確化しよう、ここから設計だ

あなたが 開発の設計者なら次の設計をするだろう

  • ユースケースを書いてユーザー視点の実行パターンを明確化する
  • ER 図を書いてテーブル連携の明確化する
  • (もう少しコード側に突っ込んで)
    文字数バリデーションを実行する手段を明確化する
    • FW が持っているバリデーションメソッドを使うか
    • form から POST された値をビジネスロジック内で
      length や size などミドルウェアのメソッドで文字数チェックし
      文字数を超えていれば 例外出力する処理とするか
  • 他、色々
  • (設計書には仕様の説明は書かない。仕様は自明である前提だ)

テストの設計者なら別のことをするかもしれない

仕様を決めた後に設計をする

f:id:mat5ukawa:20160817231527p:plain


蛇足

1

「ここからようやく「設計」だ」に関する項目が曖昧だが...

この辺り勉強中なので、色々わかり次第またの機会に

2

仕様を相談するくだりは

説明用ということでその内容を簡素(削った、という方が正確)にしたが

あなたなら顧客へ他に何を質問・相談するだろうか、考えてみてほしい

動機付けになった Web リソース

参考にした Web リソース