要約
1.設計書は「カレーライスの作り方」
2.材料（玉ねぎ・人参・じゃがいも・ルー）がINPUT
3.完成したものがOUTPUT
4.材料をどこで買ってくるか書いてあると嬉しい（売ってなかったらの場合は異常系）
5.手順が書いてあると嬉しい（材料を切る->炒める->水入れる->ルー入れる）
Q.どのくらいの細かさで書くんですか？
A.他の人が読むのが嫌にならないくらい（笑。
最低限INPUTとOUTPUTが無いといけません。
プログラムの作成・テスト実施が目的です。
あまり細かく書くとそれ自体が目的になるので注意。
Q.納品物でもなく自分で趣味として製造する場合でも書くんですか？
A.YESです。
すでに知っている処理・またはホビーで書いている場合でも
箇条書きくらいは書きます。
いきなり最初からコードを書き始めるとたいてい手戻りが発生します。
Q.書き直すことはありますか？
A.当然YESです。
実際に書いてるうちに設計が間違ってたということはよくあります。
設計書が納品物となっている場合や、お客にレビューしてもらっている場合は再レビュー。
そうなると面倒なんであまり細かく書かないほうが良いのかもしれません。
あ、プログラムだけ直して設計書を直さないのは後で地雷になります。切腹モノです。
Q.手順が思いつきません。どうしたらいいですか？
A.5W1H（いつ・どこで・誰が・何を・どうする・どのように）を思い出してください。
「何を」がINPUTで「どうする」がOUTPUT。
「どのように」は逐次処理とかSQLのJOINとかあるかもしれんけどそこは書かなくても分かる。
これはもう、プログラムと言うより国語の領域ではないでしょうか・・・。
弊社スタッフ2年目（そろそろ3年目）の悩み。
既存部分の修正や関数レベルでの製造は出来るのだけど、
自分で書くとなると、てんでダメなんだそうです。
引いてみると結構出てくる。
ざっくりわかる！プログラミングのためのフローチャートの書き方
しかし、なんというか・・・みんなむつかしく考えすぎじゃね？
カレーライスの作り方はみんな書けるでしょ？
箇条書きでやることを書いていくだけです。
もちろんカレー作ったことない人は書けないとは思うけどね・・・。
あれ？私長島監督みたいになってる？
「球がこうスッと来るだろ！」
「そこをグゥーッと構えて腰をガッとする！」
「あとはバッといってガーンと打つんだ！」
2021/02/17追記
「設計書 書き方」で検索してきてくれる人。
ありがとうございます！
上の説明じゃ、わからんという方のために補足。
まず、新人さんだと画面設計書を書くことが最初だと思う。
IPAの資料「機能要件の合意形成ガイド」がマジ良いので見てくれ！
画面下のほうの「ダウンロード」にある。デザインはさすがに風格（阿部寛み）を感じる。
しかし内容は良い。
p71（実ページはp19）「3.4.2確認のコツ」望ましい記述例(1)以下を正座して読んでほしい。
気をつける点がビシバシ書いてある。ステマじゃないよ。
・アクション実行後に画面表示が変更される箇所を明示する
・画面項目の入力例を示す
・可変長や繰り返し表示する画面部品は、長い場合を基準に設計書を作成する
・操作手順記述時に、入出力やアクションの詳細な説明を記述する
・画面の名称や識別IDが他の設計書と一致していることを確認しやすいように記述する
これだけを気をつけるだけでもだいぶん出来が違ってくるんじゃないかな。
あ、上の資料に書いてなかったけど画面設計書にはDBのフィールドと各画面項目の
対応表があるとうれしい。
googleスライドで作ったひな形です。
表がうまく表現できてないところが残念です。
改善点やリクエスト等あればお問い合わせからお願いします。
以上