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

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

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

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

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

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

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

上司がドキュメントしかみないしドキュメントをみて判断をするからドキュメント自体は必要なのはわかる。
でも必要最小限にしたい、20以上のフォルダの中にそれぞれ10～50のファイルがあってさらに1冊印刷するだけで数百ページになったりするものもある。
いくらなんでも過剰だとおもうし、保守なんてできないと思う（メンテしてることにしてるだけ）。
しかもどこの現場にいっても設計書のフォーマットが違ってどう読めばいいのか慣れが必要なんだよ
テーブルだけで300以上あるシステムとかだとDB設計書やSQLだけで恐ろしい量になったりするのもわかるけどさ

なにが必要な情報でなにが不要なのか日本中で統一して欲しいし、教科書てきなものも必要だと思う

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

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

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

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

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

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