The anecdotal answer would be “as soon as it is made”. But while it is funny and tragic, it is also not correct.
Inevitably, requirements that someone may have from a system today will likely change at some future time.
Requirements change can be due to that person’s learning from use: they use the system, and new requirements arise, while old ones lose relevance. Take a trivial example: your requirements from an email client were different the first time you wrote an email, and today, after you wrote hundreds, or thousands of them.
Besides learning, the context in which you use the system may have changed. You may no longer need to use it in the same way. Its use may no longer be as important to you. There may be alternative systems which offer different features, and which may lead you to have new requirements; and so on.
But even if requirements changed, the requirements model or requirements specification can remain relevant for a long time, throughout the system’s lifecycle; this can be from months to decades.
One reason for a long lifetime of a requirements model is that it reflects the expectations and intentions of those who provided the requirements in the first place, and can thus be used to explain why the system is as it is.
A second reason, beyond explanation, is that a requirements model is a way to preserve and transfer knowledge about the system. It is often equally useful to know why something was made as it is, besides knowing how it was made and how it works.
A third reason is that it is part of the system’s documentation, as long as the requirements in the model are still being satisfied by the system.