全部要件定義で突っ込めばよくない？
インプットアウトプット、DBとか環境設定、処理の概要くらいはみたいけどほとんど使われない設計書を大量生産するのってアホみたい。

現場でも実はソース書いてから設計書つくりましたみたいなことが多いし、客も設計書なんかみてないし、保守のSEも設計書よりも問い合わせではコード見て判断する方が多いし、バグ改修でも設計書みながらバグ改修するやつなんていないでしょ。

だれの為に作られてだれの為にメンテしてるの？日本以外のITの進んだ国でも同じことをやっているのだろうか？

5分でかけるコードのために1ヶ月かけて資料と検証をしているようなものだ。

ソースみたり検索しただけじゃ直ぐにわからない情報をパパッとわかるようにまとめたものは必要だと思うけど、過剰すぎて誰も使ってない求めてない情報まで一生懸命メンテしてない？

まとめ
今みたいな詳細設計書はいらないと思う

IT先進国のアメリカでもエクセルで大量に設計書を作っているのかだれか教えてください。

どこの現場いってもそんなもんだよ
マトリクス式で全ての結果にDBと画像の証拠をExcelに貼り付けさせるような時間のかかるテストを要求するところもあるし殆ど時間くれないとこもある(;´д｀)

工程
要件定義　　-　　基本設計（外部設計）-詳細設計（内部設計）-実装
↓　　　　　　　　↓　　　　　　　　　↓　　　　　　　　　↓
システムテスト　　結合テスト　　　　　単体テスト　　　　　プログラムテスト

的なものを勝手にイメージしてるんだけどPS（プログラムテスト）なんてどこも存在しないから
プログラムテストと単体テストを一緒にやるかんじなるのかな？
単体テストは修正したロジックの分岐を全て試すべき！
とかいわれる
詳細設計で決めたこと全部満たしてるかと修正したロジックの分岐を全部通してみる（そのときにデッドロジックに気づいたりもする）
あとは境界値と異常値の確認くらいかな？
結合テストでは修正とは関係なくてもデータパターンを一通り試したり、あとは要件定義とか外部設計で決められたこと全部満たしてるかとかそんな感じかな？

現場の顔伺いながら自己流でやってきてるから参考にならないかも(^_^;)

１つの画面を5日で作るのと20日で作るの、お金になるのは後者。だから書類は多ければ多いほどいい。
SIERなら常識。

テストで大事なのはステップ数と件数だから、全部同じ人がやらないと調整しにくいだろ？
バグが多ければテスト項目から削ったり設計書を直したり、少なければバグが出るテスト項目増やしたりして対応できる。

自分だけ、そのときの自分にしかわからないプログラムを書くやつが多いから、詳細設計書はなおさら必要なんだよな。

設計書を書かせるとおかしな設計であることが一目瞭然となる。

ドキュメンテーションが苦手なやつは、プログラムを日本語にしたようなのを詳細設計書にするからなあ。

プログラムに詳細設計書の言葉をコメントとして残さないのも多いし、日本人は能力が低い人間をコーダーにしているからこうなる。

詳細設計書を書くことに意味がある。詳細設計書を省くと実装者の自由になってしまって、仕様まで変ってしまう。

外国は仕様書をたくさん作ってから作らせるが、それでも全然違うものができあがって、勝手な仕様を製品仕様として認めるしかなくなる。

マイクロソフト製品が事前の話とまったく違うのはこのせい。

詳細設計なんてまともにやらずに客先常駐で雇って外部設計ベースで都度都度説明しながらPGPTやらせるのが大半だけど
外部設計の矛盾をPGで吸収するか差し戻して設計やりなおしってのが死ぬほど効率悪いよね

まあ詳細設計とまともなレビューがあってPG前に設計修正するフェーズある案件見たことないけどさ