What is a Project Management Plan?
A Project Plan must give you 3 very different things:

An overall idea of how the project is to be managed (namely when to cancel it)

An increasing detail of the work to be done in all of the 8 project areas (Scope, Time, Cost, Quality, Human Resources, Risk, Procurement and Communication)

Estimates (of what you will deliver, in what time frame, with what cost and so on)

In the Project Management Book of Knowledge, page 443, it says that a “Project Management Plan is a formal, approved document that defines how the project is executed, monitored and controlled. It may be a summary or detailed and may be composed of one or more subsidiary management plans and other planning documents”. The bottom line is that the Project Management Plan is something live that grows in time with detail.

Rolling wave
Thus the first concept, the rolling wave. It’s quite natural to have a greater level of detail of what’s coming up next than the level of detail of what’s coming up in 6 months, right? So why not plan your project that way? Plan to the detail what’s next and take only the time to plan an overview of what’s coming later, so the tasks that are to take place sooner will have a greater level of detail. Does that make sense to you? You’ll learn about some tools that will help you on this, namely the Work Breakdown Structure.
Anyway, don’t get the idea that you will always plan in this manner. I’ve done several short projects (like 2 weeks long) where all the planning is in place prior to beginning the project work. The fact remains that most projects will benefit from rolling wave planning.

Requirements
A requirement is something that is needed and that your project should address. You can always classify requirements into:

Business requirements, something that the organizations needs

Stakeholder requirements, something a particular stakeholder needs

Solution requirements (both functional and non-functional), are the requirements needed by the solution you’re developing to address the business’ and the stakeholder’s requirements

Transition requirements, are the requirements needed to take the organization from it’s current state to where they will be after your project is done but that won’t be needed afterwards. Just to illustrate this, you may have to migrate data from an old system to a new system and build a third system just to do that - and that third system will no longer be needed once all the data is in the new system. You can find a lot about requirements on the Business Analysis Book of Knowledge.

Relation between the project areas

No matter what you do, each project area (from scope to communication) will impact some other areas. This is fairly plain to see: if you have to buy something that you expect to take 2 months to be delivered when started planning the procurement, you will definitely go back to your schedule and adjust it so it reflects it, right? Same thing if it costs half of what you expect because demand for that product broke for some reason. So there is no way you can separate each one of the project areas and plan it alone, you somehow have to put them all together or re-plan the previous planned areas each time you plan a new one. In any case, you can’t follow a rule like “first do this then do that”. If someone tells you they have a planning flowchart you can safely assume they’re either lying or don't know what they're saying.
So how should you deal with that? I don’t think there’s an answer to that, and this is why Project Management is so tricky. What you definitely must do, and that’s what the Project Management Institute framework advices you to do, is to take the time to double check if everything you planned for each of the different project areas do fit perfectly - and they call it the “integration knowledge area”.

Conclusion
This was a preparatory article on what’s coming within the planning phase. The 8 project areas will be addressed in the following articles so it will take some time before we move on to the next phase. By the way, project phases do usually overlap a bit: you can plan a bit before you’re finished with starting the project and so on.
And please remember: the plan is something to guide you and it's bound to change. The plan *is not* something pre-agreed upon that you must follow blindly!