最初は、「要件定義」といわれる作業です。システムの全体像を作成し、システム化にかかる費用、期間を見積ります。
①お客様との打合せ・・どんなシステムを作りたいか？なにをシステム化したいか？どんなアウトプットがほしいか？
②要件定義書作成・・・お客様の要望をシステム化する為に必要な処理をすべて記載する。
③見積作成
お客様に聞きたいこと（要件定義書の記載内容）を整理して、何度も繰り返し打合せを行います。
ここでは、正確性・完全性・非曖昧性・一貫性・ランク付け・追跡可能性・検証可能性・変更可能性を満足することが求められます。

システムの全体像を設計書に記載し、お客様にも見える形で要件定義に漏れや誤りがないかを検証します。
①基本設計書作成・・・必要なデータ（情報）の管理の仕方（入／出力、保管など）、必要な処理の洗い出しをシステムエンジニアが行います。
②内部レビュー
③お客様レビュー
要件定義書をインプットに、お客様に見える画面や帳票等の詳細を定義します。
機能単位に担当者を決めて基本設計書を作成し、チーム内部でレビューを行います。
レビューは指摘を取り込んで何度も実施することが多いです。
内部でのレビューが終わったらお客様にもレビューしてもらいます。

実際にプログラミングをするために、詳細を定義し設計書に記載します。
①詳細設計書作成・・・入力するデータ、出力するデータ、処理のタイミングなどをシステムエンジニアが定義します。
②内部レビュー
基本設計書の内容をどのようにプログラムで実現するか検討し、プログラム単位で詳細設計書を作成します。
それを基本設計を担当したシステムエンジニアがレビューします。

詳細設計書に基づき、実際にプログラミングをし、テストをして詳細設計書通りに動くことを検証します。
①プログラム作成
②単体テストケース作成
③単体テスト実施
④単体テストケース/結果レビュー
①～③はプログラマが実施します。
テストケースが足りないと、特定の条件下では設計書通りの結果が出ないなどの問題が発生します。
システムエンジニアはテスト結果のレビューや各種ルール作り、テストで発見したバグ対応等を行います。

結合テストでは、基本設計書通りに動くことを検証します。
①結合テストケース作成
②結合テスト実施
③結合テストケース/結果レビュー
単体テストでプログラム単位で検証を行いましたが、その範囲を機能単位での検証に拡大します。
個々のプログラムが詳細設計書通りに動いても、他のプログラムと連動させると動かないことがあります。
基本設計レベルの検証のためテストケースをシステムエンジニアが作成し、テスト実施をプログラマがやることが多いと思います。

総合テストでは、要件定義通りにシステム全体が動くことを検証します。
①総合テストシナリオ作成
②総合テストケース作成
③総合テスト実施
④総合テストケース/結果レビュー
総合テストでは要件定義の内容通りにシステム全体が動くのかを検証します。
具体的には要件定義で作成した業務フローをもとに、まずテストシナリオ（テストの流れ）を作成します。
それをさらに詳細な確認ポイントを記載したテストケースに落とし込みます。
開発側のテストとしてはこれで終わりになるので、ここでバグを出し切る必要があります。

出来上がったシステムをお客様にテストしていただきます。
①お客様のテストのヘルプ
②お客様問合せ対応
受入テストは基本的にお客様でのテストなので、開発側が主体的に実施する作業はありません。
テストを実施するための準備を手伝ったり、問合せ対応を行ったりします。