Re:設計のレビューなんてやるだけ無駄。

(via http://d.hatena.ne.jp/JavaBlack/20061026#p1)
設計書とソースコードが1対1になるようなのは限りなく無駄だと思うけど
要件定義書についてはコンテキストによると思うんですけどね。

エンドユーザと開発側について

エンドユーザと開発側の目的レベルが一致している場合

要件定義書はなくても良いと思います。

エンドユーザが開発側の目的レベルが一致していない場合

要件定義書を作って合意すべき。ソフトウェアの正しい振る舞いを合意しないと目的が一致していないのでトラブる確率が高い。

開発側と保守側について

開発チームがそのまま保守を行う場合

ソフトウェアの正しい振る舞いを開発側が理解できていると考えてドキュメント化は不要

開発チームと保守チームが分離していて開発チームと保守チームが共にアジャイルに熟知している場合

「アジャイルソフトウェア開発の奥義」に載っているように受け入れ試験までも自動化にしてしまって
ソフトウェアの正しい振る舞いを保証できるしその文化は継続できそうなのでドキュメント化は不要

開発チームと保守チームが分離していて開発チームはアジャイルで保守チームは従来型の場合

要件定義書を作ることでソフトウェアの正しい振る舞いを明らかにしておかないと保守できないと思う。

保守しねーよ（あんのかこんなケース？）

ドキュメントいんねー（ｗ


というかドキュメントを作る場合にも「作って渡せば終わりでしょ」ではなく
コミュニケーションの１材料とすべきですけどね。