The 1^st Requirements Paradox sounds:

• Requirements must be stable (why?) to develop reliable results.
• However, the requirements always change.

Even if you did your utmost best to get complete and stable requirements, they will change. Not only because your customers change their mind when they see emerging results from your developments. Also the developers themselves will get new insights, new ideas about what the requirements should really be. So, requirements change is a known risk. Better than ignoring the requirements paradox, use a development process that is designed to cope with it: Evolutionary delivery.

During a development cycle, the requirements are kept stable, as needed for quality results.
At the start of every cycle, the requirements for that cycle are defined, based on the list of priorities at that moment. The list of priorities could have been changed by:

• Changing (adding, deleting) requirements, caused by accepted change requests
• Adding problems to be solved, caused by accepted problem reports
• Reshuffling the priorities

Between cycles there is a short time slot where stakeholders input is allowed and requested to reprioritise the list.

This is due to the 2^nd Requirements Paradox:

• We don’t want requirements to change
• Because requirements change is a known risk, we try to provoke requirements change as early as possible

We solve the requirements paradoxes by creating stable requirements during a development cycle, while explicitly reconsidering the requirements between cycles.

If we know the requirements will change, it is sound risk management to provoke these changes earliest rather than later. In conventional waterfall developments, the customer gets a Big Bang result, where he may admit that the requirements agreed are perfectly well fulfilled, but unfortunately this is not what he needed. You worked for the wrong solution. That's a pity.