#未経験から詳細設計書を書くためのまとめ。
現在の会社に入って良かった点と言えば、詳細設計書の書き方を学べた所だ。
実際それをやったところでまだ、書いても書けてないと言われる所が関の山かもしれないが。
その会社で正しいと言える詳細設計書を書くための手順をこれから書いていく。
##詳細設計書を書くための手順1.執筆編
###①携わるシステムの全体図と詳細設計書を元に設計されてるスクリプトとの相関図を見る。
執筆の前にまずは理解分析が必要。
まずは詳細設計書を元に作られるスクリプトがどんな繋がりで動いているかの全体像が解らないと話にならない。
実際にシステムの全体を管理している端末や、相関図を記してある資料があるはずなのでそれを確認すること。
紙で確認したいのがやまやまだが、SESで来てるような社員だとプリンターを使わせてもらえないことが多い。
###②どういう経緯で詳細設計書を書く必要があるかを記述する資料をすべて読む。
上記の資料はたいてい検討項目資料・基本設計などと呼ばれることが多い。
どの検討資料がどの設計書に該当するかなど、会社の人はいちいち教えてくれない。
資料に相関図が書いてあるものもあれば書いてないものもある、有識者に確認するしかない。
確認する検討資料が多い場合は自分の中で整理して図を作る、WBSを作るなどでまとめること！
そこから詳細設計書を書くための軽いあらすじを各検討項目に書いていく。
##詳細設計書を書くための手順2.執筆編
###①現行で使用している詳細設計書を読んで、文法や言葉遣いを真似る。
詳細設計書は、プログラム処理を日本語に変換したものと考えたほうが良い。
だからと言って、思った通りに文章表現すると必ず間違いと言われる。
なので事前に現行で使用している詳細設計書を読んでどんな文法や言葉遣いが正しいか見る必要がある。
if文やリターンコードの受け取りなどその会社で、パターン化されてることが多いので
その会社ごとの仕様に合わせたほうが良い、そうしないと納得されないパターンが多い。
例としてリターンコードであれば、0だった場合と、それ以外の場合の処理を記述など、
誤りがなくかつ簡易的な文章表現が好まれる。
###②各プログラムの呼出し先、呼出し元を調査して、変更に伴う影響まで説明できるまで理解する。
仮にこのプログラムは使用しなくなったので、そのプログラムの呼出しを削除するだけの場合でも
そのプログラムの呼出し先、呼び出し元があるかないか？を調べ切って、影響の有無を説明できる所まで調査・理解
してから、設計書に記述しないと、上司やお客さんは納得しない。
ここは割り切って時間を割いて一つ一つ調査しよう！
###③一つの設計書でokを貰えたら他の設計書にもその仕様を適応する（水平展開）
一度完全にokを貰える設計書を一つ作ってからそれに似た設計書にも適応するよう水平展開すること。
ヘッダ情報の仕様は基本的に決まっているはずなので仕様理解の意識合わせをしてから書いていく。
あとはその一つの仕様を他の設計書にも適応すべくシステム名、機能名、前提条件、詳細機能、
細かく見るときりがないので抜けがないようにリストを作ってチェックすること！
###④下記に該当するか見直しをしよう！該当していたら、誤りがなくかつ簡易的な処理表現に変えよう。
[表現あいまい][用語未定義][用語多義][記述誤り][記述モレ]