When are requirements done?

A question came up recently about when requirements are done. When can you say that you have completed the requirements and there is nothing left to add?
The answer is probably never. Given unlimited time and resources there will always be more information that you can obtain that will change the requirements you have specified, or add new ones, or delete old ones, up to and including changing the entire solution. Had you started a project in 1992 and planned to have the software requirements finished in a year with the target platform being a CICS 3270 terminal. You might have found yourself redoing all the requirements the following year when Windows 3.1 was announced, and then again a couple of years later for Windows 95 and the web and Java (all came into commercial use in 1995.
The bottom line is that the requirements are always complete and correct, assuming you've done proper analysis, based on the information you have gathered and confirmed up to this point in time.
However, a guideline is still demanded. So, here goes: when you have a solution to the business problem and have specified everything the business needs to do to solve the problem, the business requirements are done. When you have specified everything that is necessary from a technical perspective, the system requirements are done. And when you have specified everything that needs to be completed for the project to be successful the project requirements are done.
That doesn't mean frozen or unchanging - just done at this point based on the information you have at that time.
The real answer is that the requirements for the system or change that is implemented are done when the system or change is in production, and subsequent requirements become subsequent changes.