アカウント名:
パスワード:
このコメントの人が、「仕様書」と「設計書」という言葉を混同して使っているのが気になりました。仕様書（外部仕様書、要件定義書）と設計書（詳細設計書）では、だいぶ意味が変わってくると思います。
あと、特定のポイントに関する仕様or設計（元コメのvalidation規則などの）は必要でしょうが、だからといって、プログラムの処理全体を網羅的に文書化することが必要かどうかは別問題でしょう。このあたりの認識の違いで、ソースのコメントで十分かどうかの意見が分かれたりしているのでは。
個人的には、仕様書は必要、設計書はテーブル設計書くらいは欲しいかな。
> 仕様書（外部仕様書、要件定義書）と設計書（詳細設計書）では、だいぶ意味が変わってくると思います。
そんなのはプロジェクト次第ですよ。しかも要件定義も請求書ベースにあるならば、仕様書に含めないですし、そのほか、画面仕様書、テスト仕様書などもあるでしょう。
> だからといって、プログラムの処理全体を網羅的に文書化することが必要かどうかは別問題でしょう。
そうですね。プロジェクト次第ですね。ソースレビューと議事録とレビュー書を納品することもありますし。
納品物としてはプロジェクト次第ではあるけど、作業工程としては、仕様と設計は分けて考えないと、責任分解や検収が難しくなる。一番困るのは、何を納品物とするかはプロジェクト次第なのに、無批判に前例踏襲されることだけど。
# COBOLを前提とした仕様書に合わせて、iOSアプリの仕様を書いても何の役にも立たない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
若いのう (スコア:4, 参考になる)
あと若いうちは「設計書なんかいらねぇ！」って言えるかもしれませんが、
年取ると（よぼよぼ・・）記憶力が衰えて１年前に自分の作ったものも忘れちゃう。
ヤングでもとある文字列の validation規則なんて聞いても答えられない。
なので仕様書は小さなプロジェクトでもまず「自分のために」書く。
役に立つ仕様書を速やかに書けないというのなら単に能力が不足しているだけで、それを棚に上げて仕様書という道具のせいにしちゃいけない。
Re: (スコア:3, 興味深い)
このコメントの人が、「仕様書」と「設計書」という言葉を混同して使っているのが気になりました。
仕様書（外部仕様書、要件定義書）と設計書（詳細設計書）では、だいぶ意味が変わってくると思います。
あと、特定のポイントに関する仕様or設計（元コメのvalidation規則などの）は必要でしょうが、
だからといって、プログラムの処理全体を網羅的に文書化することが必要かどうかは別問題でしょう。
このあたりの認識の違いで、ソースのコメントで十分かどうかの意見が分かれたりしているのでは。
個人的には、仕様書は必要、設計書はテーブル設計書くらいは欲しいかな。
Re:若いのう (スコア:0)
> 仕様書（外部仕様書、要件定義書）と設計書（詳細設計書）では、だいぶ意味が変わってくると思います。
そんなのはプロジェクト次第ですよ。
しかも要件定義も請求書ベースにあるならば、仕様書に含めないですし、
そのほか、画面仕様書、テスト仕様書などもあるでしょう。
> だからといって、プログラムの処理全体を網羅的に文書化することが必要かどうかは別問題でしょう。
そうですね。プロジェクト次第ですね。ソースレビューと議事録とレビュー書を納品することもありますし。
Re: (スコア:0)
納品物としてはプロジェクト次第ではあるけど、
作業工程としては、仕様と設計は分けて考えないと、責任分解や検収が難しくなる。
一番困るのは、何を納品物とするかはプロジェクト次第なのに、無批判に前例踏襲されることだけど。
# COBOLを前提とした仕様書に合わせて、iOSアプリの仕様を書いても何の役にも立たない