Requirements rarely completes, usually it evolves and changes.
As is told in the famous book Pragmatic Programmer, From Journeyman to Master by Andrew Hunt, David Thomas;
The Requirements Pit
Many books and tutorials refer to requirements gathering as an early phase of the project. The word "gathering" seems to imply a tribe of happy analysts, foraging for nuggets of wisdom that are lying on the ground all around them while the Pastoral Symphony
plays gently in the background. "Gathering" implies that the requirements are already there—you need merely find them, place them in your basket, and be merrily on your way.
It doesn't quite work that way. Requirements rarely lie on the surface. Normally, they're buried deep beneath layers of assumptions,
misconceptions, and politics.
I am not really sure if there is any point at which you can tell that requirement are complete.
I am asking this from the perspective of an analyst who wants to make sure that his requirements are complete before passing them on to the design team.
It purely a personal or business choice, many projects starts with a high level idea of what they want, and will evolve by itself to reach the final stage. Some cases you might need to sign some contract which will state the basic set of requirements. so, it always depends.
When it comes to requirements the only important thing is that, you should be prepared to act based on the change.