たとえるなら
川の流れそのものです。上流で決めた水の流れは、そのまま下流に届きます。上流で水が濁れば下流も濁るように、最初の要件定義や設計での間違いは、後の開発やテストにそのまま流れ込んで大きな影響を与えます。
もう少しくわしく
システム開発は大きく、「何を作るか決める（要件定義）」「どう作るか決める（設計）」「実際に作る（開発）」「正しく動くか確かめる（テスト）」という流れで進みます。この流れを川にたとえ、前半の要件定義・設計を上流工程、後半の開発・テストを下流工程と呼びます。
この呼び方は、工程を上から下へ順番に進めるウォーターフォール開発の考え方と深く結びついています。上流での決定はすべて下流に流れ込むため、上流の間違いを下流で見つけると、設計からやり直しになって修正の負担がとても大きくなります。だからこそ上流工程では、文書をしっかり作り、関係者で何度も確認するのです。
注意したいのは、上流・下流は偉さの上下ではないということです。日本のIT業界では「経験を積むと上流を担当する」という慣習があり、求人でも「上流工程から携われます」が魅力として書かれがちですが、開発やテストにも高い専門性があります。設計だけ・開発だけに偏らず、両方を知る人ほど現場では頼りにされます。
現場での使われ方
「この案件は上流から入れますよ」
求人や営業でよく聞く言い回し。プログラムを書くだけでなく、要件定義や設計といった決めごとの段階から参加できる、という意味です。
「上流でのミスが下流で発覚して、手戻りが発生した」
設計段階の間違いがテスト段階で見つかり、前の工程からやり直し（手戻り）になった、という開発現場で恐れられる状況です。
よくある質問
上流工程のほうが偉いのですか？
いいえ、川の位置になぞらえた工程の順序の話で、偉さの上下ではありません。日本では上流担当が経験者の役割とされる傾向はありますが、開発もテストも専門性の高い仕事で、どの工程が欠けてもシステムは完成しません。
アジャイル開発にも上流・下流はありますか？
アジャイル開発では短いサイクルで要件・設計・開発・テストを繰り返すため、工程を一方通行の川にたとえるこの言葉はあまり使われません。主にウォーターフォール型の現場で使われる言葉です。