たとえるなら
注文住宅の建築です。間取りを決め（要件定義）、設計図を引き（設計）、工事をして（開発）、完成検査をする（テスト）。基礎工事が終わってから「やっぱり3階建てに」とは言えないように、後戻りしない前提で、最初に全部を決めてから進みます。
もう少しくわしく
ウォーターフォール開発は、開発の工程を「要件定義→設計→開発（実装）→テスト→リリース」と順番に並べ、上から下へ一方通行で進める方式です。滝（waterfall）の水が逆流しないように、前の工程が完了してから次へ進み、原則として後戻りしません。それぞれの工程の終わりに文書や成果物をきちんと確認してから先へ進むのが特徴です。
この方式の強みは計画の立てやすさです。最初に全体像を固めるので、完成時期や費用の見通しを立てやすく、多くの会社や人が関わる大規模開発でも分担しやすくなります。銀行のシステムや官公庁のシステムなど、途中で要件が変わりにくく、失敗が許されない大型プロジェクトで長く使われてきました。
弱点は変化に弱いことです。最後のテスト段階で問題や認識ずれが見つかると、前の工程まで戻る大きな手戻りになります。「作っている途中で要望が変わる」ことが当たり前のWebサービス開発では、短いサイクルを繰り返すアジャイル開発が選ばれることが多くなりました。どちらが優れているかではなく、プロジェクトの性質による使い分けです。
現場での使われ方
「このプロジェクトはウォーターフォールで進めます」
最初に要件と設計を固め、工程を順番に進める方式でやります、という開発方針の宣言です。
「いま設計フェーズなので、実装はまだ先です」
工程を順に進めている途中で、現在は設計段階。フェーズは工程の区切りを指す言葉です。
よくある質問
ウォーターフォールは古いやり方なのですか？
古いというより「向き不向きがある方式」です。要件が最初から明確で変わりにくい大規模システムでは今も現役で使われています。一方、変化の速いWebサービスではアジャイル開発が主流になっています。