社内向けのWEBアプリケーションを構築します。JAVAで1年程度のプロジェクトです。

２を選びます。（１を採用している会社の方が多い気がしますが）

理由としては、「基本」と「詳細」という言葉ではそれぞれの役割分担が分かりにくいという点です。

どこからどこまでが基本で、どこからが詳細なのかが人によってまちまちになり、意識に齟齬が生じそうです。

「外部」「内部」と分けることで、「外部設計ではJavaシステムの外側、つまり画面やDB設計などを設計する」という意図が明確になります。

イメージですが、「基本設計」という言葉を使っているところではDB設計がよく漏れている気がします。

２を選びます。

入力する内容と手段・インターフェイス（画面構成やチェックなど）、出力の方法（検索・一覧・帳票など）をユーザを交えたレビューを繰り返しながらつめていく方が、あとからぶれにくい要件定義と外部設計ができてくると思います。

実現しないといけない要件と画面や帳票のイメージが固まっていれば、実装方法を含めた内部の設計もやりやすいし、外部設計がぶれにくければ手戻りも少なくてすむことが多いように思います。何をテストすれば良いかもわかりやすいですし。

僕はDB設計を内部設計のフェーズで行います。

ある程度実装手段によってDB設計は影響を受けやすいためです。

経験上、基本〜詳細〜という分け方は、品質管理の名の下に膨大な設計過程の資料を残すためにあるような気がします。

明確な回答になはならないかもしれませんが、参考にしてください。

１と２のフェーズの分け方を考えられていますが、それって本当に違った考え方のものなのでしょうか？

基本設計って何ですか？

どういう情報が入って、どういう成果物を作るフェーズですか？

同じように詳細設計、外部設計、内部設計はどうお考えですか？

これって、各会社（個人）やお客様によって違うと思います。

基本設計＝外部設計という考えをもった会社も多いと思います。

どう考えるかによって成果物も変わってくると思います。（DB設計がどのフェーズに入るかという問題も）

以上のようなこともありますが、基本的に呼び方が違うだけで、システムの構築手順としては、

１．要件を明確にする

２．要件を実現するシステムの動作を明確にする

３．システムの動作を実現する手法を明確にする

４．コーディング

といった流れがあると思います。

どう呼ぶかはあまり気にせず、目的を実現するためのステップを順に考え、同時にお客様の要望，会社での流儀を取り入れていけば、自然と各フェーズでやるべきことと成果物は決まると思います。

どちらかと言えば、私は１．派ですね。

外部設計という言葉を使っているところほど、画面や帳票などユーザから見えるところ（外部？）だけ定義して終わらせているように思います。

もしくは、どちらでもない案ですが、JIS X 0160 の言葉の定義に従い、

（ソフトウェア）要求分析

（ソフトウェア）方式設計

（ソフトウェア）詳細設計

と呼ぶのも公的規格準拠という面からは良いかと思います。私の会社では（お堅めの会社なので）そうしています。

まぁ、こんなのはただの方言みたいなものなので、なんでもよいというのが私の本音です。そのフェーズでどのような成果物を確定するのか、を決めることが大切だと思います。

どちらか、と問われば２を選びます。

要件定義・・・システムのコンセプトや、大まかなイメージを定義

外部設計・・・画面・帳票レイアウト等、「何を」の観点で詳細に設計

内部設計・・・外部設計を受けて、「どうやって」の観点で実現方法を設計

のように進めるのが良いと思います。

個人的には、

・「何を」「どうやって」を明確にわけて考える。

・作成する成果物（中間成果物を含む）と、それをイン／アウトプットする

　プロセス（作業）のフローを考え、全員で共有する。

が重要だと思っています。

特に後者は

http://homepage3.nifty.com/koha_hp/process/Proc.Index.html

で紹介されているPFD(プロセスフローダイアグラム）を書くと効果的です。

その目的も明確にならないままになんとなく成果物（設計書など）を作っている

プロジェクトが多いですが、PFDを書くことで、その成果物がどの工程の

インプットになるのか、成果物に何をアウトプットしなければならないのか、

より具体的に言えば「ドキュメントの作成目的は何で、どういったことを

記述しなければならないのか」が明確になります。

基本設計や、外部設計、内部設計と言う定義にこだわるのではなく、

役に立つシステムを作る為には、どういう工程を踏んで、各工程でどういった

成果物を出していくべきか、を考えると良いと思います。

「外部設計」「内部設計」という言葉の厳密な定義からはそれルカも知れませんし、抽象的ですみません。

>外部設計とは、「ユーザーに見てもらい、仕様の漏れや誤解を無くす」ための作業なのでしょうか？

そうですね。

できあがったシステムのイメージがユーザと共有できるようにするための作業だと思ってやっています。

ですので、操作方法やデータの表現方法、保持しないといけないデータの内容、印刷物や出力するファイルなど、ユーザが操作するもの目にするものを明確にするような設計資料を作成するようにしています。

上の「保持するデータの内容」はテーブル定義という意味ではありません。ユーザが意識しているレベルのものです。（「伝票」や「サポート履歴」といったレベルです）

また実運用に入った場合にクリアすべき性能も含まれると思います。

• システム化対象の伝票や帳票、書類の書式などを集める
• 既存のシステムのリプレースなら既存の画面・帳票、足りない項目などを調べる
• 上記をもとに必要な入力項目・表示項目・印刷項目などを割り出す
• 画面や帳票に再展開し、操作方法・画面遷移や集計方法などを決める

• etc.

といったことをやって設計資料を作ってます。

内部設計に関しては、外部設計で作り上げたものをいかにして実現するのか、という設計作業だと位置づけてです。実際にプログラムを作成するにあたって必要な取り決めや使用する技術、テーブル設計などをこのフェーズで行うようにしています。

>逆に内部設計は、「ユーザーに見てもらう必要は無い」との理解でよいでしょうか？

内部設計をユーザに見せる必要があるかないか、は案件にもよると思いますのでどちらとも言えませんが、社内向けであれば特に「見せる」必要はないのかも知れませんね。

いずれにしても、「こうやって実現するんですよ（しているんですよ）」が明確になっている設計資料をつくることができれば、後の製造作業はもちろん、ユーザへの説明、メンテナンス等に「使える設計」になるのではないでしょうか。

基本設計