Software is never finished, merely abandoned.
Don't remember who said this first, but it's true. After you spend some time in the industry, you inevitably reach the same conclusion. And based on this, you can't say when the requirements are finished either. In fact, the only guarantee you have is that you are missing requirements.
And then the better question becomes "Which requirements are you missing?", because just identifying the lack of requirements isn't enough. For example, some requirements are essential, while others just represent a "nice to have" feature. If you think you are missing requirements, you better think of where you want to spend that time.
This is the problem with a predictive approach of developing software for example. You try at the beginning of the project to sit down and identify everything you need, put all of the details in, cover all the cases, and be afraid you've missed something. You sit down and think hard about everything, so that you don't miss anything.
But that doesn't work.
That's why we have things like Agile and an adaptive approach. Because you can't predict everything, and you can't write complete requirements for that, and you don't know what you are missing. Another reality of the industry is that users don't even know what they want. So even if you write (what you think are) complete requirements, they might be complete requirements for the wrong product. So you still need to sit down and think, but you think about what's the most important thing now, based on the information you actually know (not the one you try to predict), build something, experiment with it, and feed back the results of those experiments as lessons learned about what's still needed.
The only way you can get an idea of "complete requirements" is if you actually build the darn thing and then start using it, until you either abandon it because it serves all your needs for now, or you still need to add things to it (many times the development is abandoned, the software is used, people get frustrated with its limitations, they want a new version, which then gets built, the development gets abandoned, the software is used, people get frustrated with its limitations, they want a new version, and so on, and so on).
Using the software is the best way to determine if you truly have what you need. No matter how many discussions and conversations you have to elicit better information, seeing the thing and actually use it beats talking about it every time.