適用案件：
インフラ変更時の案件や、機材に含まれるオペレーティングシステムのアップデート案件。
要求仕様及び業務設計内容は変わらないものの、システム基盤の変更などにより又は使用言語を別の言語や版に変更して実装し直す作業。
顧客のインフラが変更され、帯域制限や、納入システムのシステムポリシーを修正する場合等もこの業務により再設計（検証など）を行います。設定以外では、既設システムのオペレーティングシステム（OS）が保守終了した場合など、同等システムになるように更新する業務も含まれます。
この同等システムの更新では、既設の動作振舞を理解すること最大の課題となり、場合によっては、新規個設計更新人ある場合も出てきますので、顧客尾要件を十分に聞き取り調査をして、対応方法を選ぶことが重要です。
適用案件：
複数の製品が有機的に連携し、尚且つ固定構成（基本構成）を有する案件。過去の機器構成から定型化が可能な案件。
既に開発済の製品を物品購入して利用する方法。
製品の一部を追加変更するカスタマイズ役務とセットにして調達する場合もある。
利用する範囲が限られ、顧客がその機能で十分に満足する場合、商品同様にパッケージを発注し購入する販売方法。
この販売方法では、過去の経験、顧客情報、納入仕様や納入図書などから、共通する要件を一つの定見システムとして商品化する方法です。
商品化のために、個々の顧客の要望聴取するビジネス形態ではなく、商品同様に指名して購入していただく方法(箱売りと同じ）です。
従って、販売人員等を最小限に抑え、注文書に対して、販売するスタイルは、量産品と類似と言え得る。
ただし、注意しなくてはならないことは、販売物のアフターフォローを行う事が必要になります。
幾つかのメーカは、購入後＊＊日鵜迄無料、それ以降有料でアフターフォローを行うパパッケージシステム会社もある。
パッケージシステム原型とし、顧客固有の要求事項に合わせた個別開発を行う場合もある。この場合は、受注工程と同じプロセスで業務を進める、顧客の意図を十分に際していくことが重要。
適用案件：
実証実験等を実施した結果を製品使用に取り込む案件。発注者や、他社との新機処理（ソフト及びハード）の共同開発が必要な案件。
対象の一部を先行して開発し、その試行評価をフィードバックしながら修正・追加開発を進めていく方法。（アジャイル開発と言う手法と同等）
事例として、システムに用いる客先固有のソフトウェア（GUIや操作系アプリケーシション）
の実証実験などがこれに当たります。
スパイラル型業務では、フェーズ毎に検証を重ねてい置く開発方法です。
それぞれの検証に時間を費やす反面、要求先の課題解決する検証を実際に行いつつ対応するために、より確実であり、尚且つ、納入後に実運用ではないために、顧客の細かい要件をキャッチアップすることができる手法です。
ただし、スパイラル型の業務は、コストが膨大に発生します（時間もコスト）。よって、試験検討などの本契約に至らない案件などの顧客を引き込み手段として用いることがあります。
従って、十分な計画（スケジュール、費用の工面、対応人員の計画（無償提供になるため）が必要です。
製品を持たないシステム会社などは、実証実験を行う行為を『コンサル契約』として有償化にして無償稼働を極力するなくする活動で進めている。（人材の活動が資源になるため）
注意点
各フェーズのコストと最終時のコストの管理が非常に曖昧になる。
特に、納入物である場合、各フェーズを定めて成果物として検収し、入金してもらう、などの事前取り決めが重要になる。
受注物ではない場合、どこまでやったら、開発を完了にするのか曖昧になり、湯水のようにコスト（人件費）がかかる場合も出てくる。
これらの問題を出さないために、目標を定め、その目標の評価（効果）を明確（ドキュメント文化）にすることが、世間のアジャイル開発のスタイルです。
適用案件：
入札仕様や顧客との要件の作り込みによる受注案件。既存機材等を用いた受注案件
開発ライフサイクルを、要件定義、設計、構築、テスト、工事（取付）といった工程に分割し、前工程の成果物を入力として各工程を実施する開発手法。
商談で得た情報や顧客要求（要件）を元に、顧客を起点とした情報からシステムの納入（検収）まで一環した仕事（の成果物）を生み出していく事が、受注システムの品質のの向上に繋がる。そして、受注後の初動の資産に繋がります。
標準製品（量産製品）の企画段階（上流）から出荷（下流）までは、
企画→構想設計→基本設計/それぞれの詳細設計→妥当性/検査→製造→出荷
上流で定めた諸元（デザイン、機能、コストなど）は、一貫して下流まで引き継がれて
製品化される。
標準製品（量産製品）が出来るまでの過程と、客先受注したシステム納入物（取り付け含め）が出来るまでの過程も、考え方の違いは有りません。
なぜ、ウォータフローモデルなのか。
顧客の意思を間違えなく細部まで展開することが必要となるため。また、この方法で顧客要件の実現方法と基本設計（見積設計）はシステム設計としてコンセプト設計も取り込むことで、納入物のモデル化にすることができる。従って、納品のスケールが変化しても設計の考え方が固定化できるメリットがある。
基本設計が固定化されれば、詳細設計に落とす場合、コンカレントに指示（依頼）を行うことができる。 したがって、システム受注時の主法は、上流から落とすやり方が最適と言える。
例
上流（お客さんの情報、商談、要求（要件）など）が起点となり、要件と要件を実現する思想（考え方）そして、システム全体のコンセプト（お客さんが求めるもの）がぶれることなく、順次に展開していく。このときの展開は、それぞれの作業（校庭とも言う）の成果物（アウトプット）により引き継がれていく。
それぞれの作業だけを抽出してみると、
次の工程では、
さらに次の工程では、
インプットの成果物（成果物は、可視化できる情報であること＝エビデンス（証拠、根拠となる資料にも用いるため。）から生成していくことで、納入物のブレを少なくし、品質が事前に予測できるメリットも生まれる。
また、顧客に対し事前承認を取ることで手戻りを最小限に抑えることができる。
必ずインプットがあり、アウトプットがある仕事にしていくことが、検収後の無償稼働を減らすことに繋がる。
ウォーターフォール図を用いた図示は下記の通り。
（一般的な汎用（主要イベントのみ）工程で記載しています。各工程の間に企業独自の工程が入る場合が多々あります。）
