How does requirements engineering differ between Waterfall and Agile methodologies?

Waterfall front-loads requirements — gather and document everything before building; Agile gathers them continuously, just before each piece is actually implemented.

* The same work, placed differently in time — that placement is the whole disagreement. *

The split reflects a genuine disagreement about whether future needs can be predicted up front.

Waterfall (static):

• All requirements are gathered upfront.
• The aim is to completely elicit and document all requirements in an early project phase.
• This happens before any design or realisation decisions are made, so the design can be optimised against the whole picture at once.
• It works when the domain is stable and well understood — and it is often not optional, because a fixed-price contract or a regulator may demand the full specification in advance.

Agile (continuous, "on the move"):

• Requirements are elicited once they are supposed to be implemented, not before.
• The reasoning is explicit: "foretelling" future functionality is difficult, and requirements change as the project runs.
• So the decision is deliberately deferred to the point where you know the most about it.
• The cost is that no one holds the complete picture early, which makes total budget and end date genuinely harder to fix.

Tip: Waterfall bets that you can know everything early; Agile bets that you cannot, so it keeps the cost of changing its mind low. Neither bet removes the requirements work — Agile does not skip elicitation, it spreads it out, and a project that "went Agile" to avoid writing requirements has simply stopped writing them down.

Go deeper:

• Waterfall model (Wikipedia) — the sequential model, its origins and the standing critiques of it.
• Agile software development (Wikipedia) — the opposite bet, and what it does with requirements instead.