Requirements can appear, change or disappear at any moment during the life of the software.
It is worth noting that the life of the software is not the same as the life of the software development project.
The life of the software begins as a concept. An idea is somebody's head. This idea, may or may not come from a problem or a necessity. And while it is in the head of that person, it is getting its first requirements.
The life of the software ends when (nobody uses it anymore and) it is forgotten. Once the software is forgotten, we can be certain that it will have no more requirements. The software may or may not have new requirements up until that moment. If the software was ever used, but the users moved on, it was because the software was no longer a good fit for its requirements.
It is also worth noting that the life of the software is not the same as the life of the system. A system may include no software components. It may include many. And yes, it may include only one. In fact, the number of software components involved may change during the life of the system.
Some software will be used for multiple system, and continue its life beyond them. Some systems will outlive its software components, perhaps by replacing them as needed.
And hardware components, and peopleware components.
If a company that has decided they want a software (likely because they have a problem), they need to figure out if they are going to license some third party software or start a development project (I'm bounding outsourcing here). To be able to decide if a third party software fits what they want... they need some crude requirements (e.g. inventory management software, must run on Windows, must be accessible via intranet). And in the process of checking software, this the list requirements may grow.
Then, when they green light a software development project. They already have some crude requirement. They may even ask for an estimate, but let us not go that path, or I will end up in a rant.
Thus, before the project begins, the software exists as an idea, and it already has requirements. Then comes scope management and planning. Some features to work on are selected, resources are assigned to activities... including requirements engineering. At the end of the project (hopefully) a version of the software has been produced (by whatever methodology).
Requirements can appear, change or disappear at any moment, including before planning, during planning, and after planning. It is the job of the requirement engineering activity (phase or not) to collect them, document them, and analyze them.
Well, it is
unlikely impossible for the first version of the software to be perfect. What is likely is that there will be a new project, which will produce a new version. Meanwhile, the developers had some ideas that they want to incorporate in the software, the users came up with some suggestions, and bug reports too... those are more requirements.
Maintenance might be a phase in the life of a software. It isn't a phase of the project. You do projects to maintain the software. See also Change Management.
Thus, we have more requirements for the project of the second version. We do planning based on that, then more requirement engineering (along side other activities according to whatever methodology, with its phases and such), and we produce a new version of the software along the way.
And repeat for every subsequent version. Or forks, or whatever.
So... were there requirements before planning? Yes. Did we do planning before requirement engineering? Yes.