Requirements Paradoxes

Even if you did your utmost best to get complete and stable requirements, they will change, because we learn, they learn and the circumstances change. The longer the project, the more the requirements have a chance to change. Requirements change is a known risk, as it will happen anyway. Better than ignoring this requirements paradox, use a project process capable of coping with it.
Evo uses rapid and frequent feedback by stakeholder response, to proactively verify and adjust the requirements to what the stakeholders really need, as quickly as possible

"What? Provoke requirements change? We don't want the requirements to change!"
Well, if some requirements have to change for whatever reason, let them change as quickly as possible, so that we have to redo as little as possible. Waiting until we find out that a requirement has to change probably causes more rework than proactively provoking the requirement to change as quickly as possible.

figure: If by the end of the project a requirement changes,
by definition, this creates a galaxy of defects

Why don't we want the requirements to change? Assume (see figure) that we have almost successfully completed the project, perfectly implementing perfect requirements (I said: assume). The moment any requirement changes, by definition, if a defect is defined as something that is not in order, this creates a galaxy of defects. Because defects have a lot of adverse properties (like: difficult to find, difficult to repair, causing scars, costing extra time, ...) this is very undesirable. The more we can prevent the generation of defects, the better.