設計資料とデザインレビュー

デザインレビューにあたって、評価項目にBD、FDとか書いてあるけど、略語の意味すらわからなかったので調べて頭を整理する
おもに設計プロセスと品質担保について

デザインレビューの要項にこんなん書いてある

要求仕様をもとにBDする
BDをもとにFDする

これなん

BD = 基本設計
FD = 機能設計
とのこと。
システム開発各段階の用語について - 桂乃屋

それぞれ何書くの

外部設計と内部設計だったら

  • 外部設計:システムの外と関わる部分
  • 内部設計:その内側を書く

という違いなのはわかるけど、じゃあ基本設計と機能設計(と詳細設計)ってなにか。

基本/詳細設計って呼び方やめませんか - Qiita
システム設計の流れ - Qiita

  • 基本設計はユーザから見て理解できるような内容
  • 機能設計は基本設計の一部
    • 機能設計はロジック、DB、バッチの設計など、各モジュールの外部仕様(= API単位の外部設計っぽい)
  • 詳細設計はその中に閉じた部分のより詳細な設計=内部設計で良さそう

要求仕様をもとにBDする
BDをもとにFDする

input: 要求仕様 → output: 外部仕様書
input: 外部仕様書 → output: 内部設計資料

これをうちで作ってるもので言うと
要求仕様 = サービス仕様書
外部仕様書 =

  • コンポ図(外部システムとの関連を表現)
  • 外部システムのIFの項目と内部データ項目の紐付け
  • 非機能要件

内部設計資料 =

  • クラス図
  • シーケンス図 とか

ドメインモデル
ドメインは外部と話すための言葉だけど、モデルで書いてることは内部か…

テスト設計も

BD仕様書をもとにSTする
FD仕様書をもとにFTする

外部設計を担保するST
内部設計を担保するFT

STは外部システムとの結合を確認しなければいけない
というかそこの確認さえできてれば良いよね
結合する部分について各ユースケースに対応するin/outのデータが網羅できていればOKではないか

結局デザインレビューはなにをみるのか

サービス仕様→外部仕様書→内部設計
外部仕様書→ST
内部設計→FT
このロジックが飛んでいないか、抜け漏れがないかを見てもらえればよいのでは、と、おもいます。
(これはサービス仕様が頭に入っていて、内部設計を理解できる人に見てもらうのが良さそうですね)
結局ただのV字モデルのはなしっぽい うーん