要件定義ではもやっとした内容よりも「最終目的」とその最終目的に至る初動（きっかけ）をはっきりさせるとよいです。最終的にユーザーに何をもたらし何を満足させるのかというところに着眼すると要件が整いやすくなります。
要件定義の前段階として少なくとも上記が必要になります。
要件定義では予算とスケジュールがかなりの深度で関係してくるのでこれまた大変な作業になります。やってはいけないことは技術単位の切り分けとコーディング・プログラミング単位での指示や決定。
通常ユーザーが見える部分（視覚化）できる部分についての設計やデザインを指します。操作時の動作やフロー、またはその動作やフローの結果がどのようになるかなどです。それらの動作に関連するパターンや確率、条件なども設計します。
要件定義に従って設計されるものなので、前提として要件定義がないと外部設計に着手できないことになります。また外部設計ではOSやフレームワークなどそれ特有の特徴的なフローや規約、限定的な動作などを十分に考慮しましょう。
パターンだしのコツは例外処理の洗い出しです。逆にいうと例外処理を洗い出せない外部設計はすでに設計ではないということになります。
外側から全く見えない部分の設計とフローを考えます。通常コーダーの裁量で行われる部分でありますが、コードレビューの対象になるのも内部設計に関連する部分になります。メンバー間でのDocumentの保持、規約や共通のルールの設定が大切です。具体的なプログラムフローやプロトコルの決定、関数の定義などを行います。（小規模案件ではこのフローはほとんどなしの場合が多いです）