====== 設計書の作り方 ======

日経SYSTEMSを定期購読しているのですが、2007/11号の特集が「意図が伝わる　設計書の作り方」でした。

===== 1.想定外の解釈はむしろ当然一つの誤解が手戻りを招く ===== 
  * "行間"はいらない、価値ある情報もノイズに
  * こんな設計書はいらない　3点 \\  1. 全体像が分からない \\ 2. 標準が書かれていない \\ 3. 設計変更の理由がどこにもない

===== 2.読み手を混乱させる元凶は情報の不足、余計な内容、表現のミス =====
  * 情報の不足対策 \\ クラス図の表記法を守る、擬似コードまで記述する、読み手ごとに不足を確認する
  * 余計な内容対策 \\ 読み手に必要な情報のみ記述する、図や表を使って単語で表現する \\ 運用設計を１カ所に切り出す
  * 表現のミス対策 \\ 「ローマ字」や「以上」を使わない、場面ごとに「標準」を示す、\\ 用語集以外の単語を使わせない

===== 3.機能要件設計書だけで20種類、役割を知り、書き方をつかむ =====
  * 画面設計 \\ 画面の構造は物理的・論理的に示す
  * 業務プロセス \\ シナリオにボタン名やタブ名を書かない
  * データ設計 \\ マスタ系と更新系を明確に分ける

===== 参照:設計に関すること =====
  * [[http://www.ipa.go.jp/sec/softwareengineering/reports/20080710.html|発注者ビューガイドライン]]
  * [[http://itpro.nikkeibp.co.jp/article/COLUMN/20060829/246616/|意図が伝わる設計書作成の心得【第4回】]]
  * [[http://www.st.rim.or.jp/~k-kazuma/SD/SD611.html|設計とは何かを正しく理解する]]
  * [[http://homepage2.nifty.com/cat-chy/cp/specification.html|仕様書の書き方]]
  * [[http://iwatam-server.dyndns.org/software/devintro/deathmarch/deathmarch/x131.html|仕様書と設計書]]
  * [[http://www.kaimei.org/note/mag/siyou.html|技術者のための仕様書の読み方と書き方]]
  * [[http://satoshi.blogs.com/life/2004/09/post.html|日本語とオブジェクト指向]]
  * [[http://www.thinkit.co.jp/free/project/4/7/1.html|結合テストと総合テスト]]