What is the correct mindset for Requirements Engineering regarding specification completeness?

Don't ask "is the spec complete?" — ask "how much must we invest to shrink the risk to a size we can accept?" Completeness is never the goal; managed risk is.

* The stopping point is set by the risk this project can accept — the same curve, two different answers. *

The naive framing treats a specification as something you either finish or don't, which leads straight to the excuse "we don't have the time for a complete specification" — an answer to a question that was wrong to begin with, because no specification of a real system is ever complete. The mature framing treats specification effort as a risk-reduction investment you dial up or down, so "how much" replaces "whether".

Rule of thumb: the effort spent on requirements engineering should be inverse to the risk you are able to manage. Read the other way round: the less risk you can afford to carry, the more you have to invest up front. A throwaway prototype can absorb almost any mistake, so it earns almost no specification effort; a system whose failure costs lives, licences or millions can absorb almost none, so it earns a lot.

You stop investing when the residual risk is acceptable — not when the document feels "done". That also gives you a defensible answer to the schedule pressure behind the excuse: the question is no longer "do we have time to be thorough?" but "which risks are we consciously choosing to carry?"

Tip: Any time someone says a spec is "complete", ask what risk that completeness was measured against. Without a risk to measure it against, "complete" is an opinion.

Go deeper:

• IREB CPRE Foundation Level — the certification syllabus that formalises exactly this "adapt the process to the situation" principle.