既設システムの更新などの場合には、スムーズに行くが、客先が望んでいるシステムが漠然としている場合には確実に発生する課題。
客先で要件がまとまっていない場合、システムの目的や利用する業務の手順、求めるシステムの周囲の条件そして、利用する時の操作など、全体が関連付けできるように可視化していくことです。
この段階の要点
情報の網羅・・・目的、条件、機能などが十分に洗い出せていること
情報の整合・・・上記の情報の辻褄が合っていること
表現と運用・・・機能や運用のイメージが分かりやすいか
実現していくシステムのジャンル（構築しようとしているシステムのグルーピング）
が大幅に変化していく受注もまれにあるが、極端なジャンルの違いが無い限り、要件の雛形を作っておくだけで、無駄の無い要件定義を行うことができる。
システムのジャンルの違い：6千ボルトを扱う電気設備と業務運用で用いるシステムの違いなどをさす。
また、雛形があるとは言え、業務で用いるシステムの場合、客先業務の営みを十分に聴取し、客先の思想（客先業界の常識）を理解することに欠けると、手戻りにもつながることが起きる。
当然、要件定義のまとめも中途半端であったといえる。
要件定義の雛形は、扱うシステムのジャンルによって差異がある。よって固定的な雛形を載せても誤解を与えるため省略したが、必要であればコメントに入れていただければ、システムのジャンル（どのようなシステム（概要）なのかなど）を教えていただければ、それなりの雛形を書き出すことも可能です。
◆要件定義
顧客の案件に限らず、自社内の製品であっても、どのようなシステムを構築するのか、と言う「ものつくり」では、とても大切な定義です。
この定義があいまいであったり、十分な聴取や調査に至っていない状態で要件定義を実施しても、インプット条件が抜けたまま仕事を進めていることになり、その結果として出力される成果物などは、条件がそろっていない成果物となってしまう。
◆要求定義と要件定義の差異は、
システム事業では、顧客から要求された「事」に対して実現するシステムを構築し納入します。この顧客から要求された「事」が全てでしょうか。
顧客は、自分たちの業務にかかわるプロです。それ以外の必要な条件があったとしても、あって当たり前と考えているかも知れません。
要件定義では、他に必要な「事」とお客さんが必要な「事」が関連付けされていなければを効力がないもの(処理や機能）もあります。このように、要求された事だけでは、システムが構築出来ても運用で維持継続ができないなど、システムに根幹に係わる重大動作となってしまう場合もあるという事です。
上記の例は、
3つの独立したホールの館内放送システムの場合、全てが独立して選択できるシステム。という要求があっても、単純にデジタルミキサーやクロスポイントスイッチ、プログラマブルシーケンサ、アンプ、スピーカ・・・だけでシステムが構築できるか、という事にあります。
機材が有する機能だけでは、システムが構築できません。
電安法で必要な条件や電気設備の技術基準などの要求が含まれて入っいなければ、システムの動作振る舞いやお客さんが要求する機能が実現できたとしても、法的要素の観点では、業務運用を行うことが出来ません。
このようにリレーションシップを考慮しているという位置づけで、要件定義として表現しています。