It's certainly not measured by how thorough it is, in fact too much verbiage could be a sign of a bad one.
It's not the one that results in the most detailed and comprehensive set of requirements.
It is most definitely not the one that gets the project through to the nest stage in the fastest possible time.
So what is a good one? In my opinion a good requirements plan give you
The requirements necessary to define an appropriate solution, documented in a form that can be easily consumed by stakeholders, elicited and defined in a way that is sympathetic to the nature of the organisation and project, that can be executed in a timely and cost effective manner.
Parsing that out there are four essential elements to a plan:
- Requirements: What requirement types will you elicit/define and at what level?
- Artefacts: What form will you document these requirements in?
- Techniques: How are you going to interact with stakeholders to elicit requirements and to validate and designs?
- Execution: When and who is going to perform this work?
For every one of these except Execution you can pick up BABOK 2.0 and get a list of possible answers
I think it's always worth setting some time aside at the start of the project to come up with a requirements plan separate of the project plan. It doesn't have to be formal document, it doesn't even have to be written down, it doesn't have to (and probably shouldn't) remain static over the project, but it should force you to sit down and understand why this project is different from all the others.
Because if you're not consciously planning, you'll just end up doing the same thinking, and having the same conversations throughout the project and it will take up even more of your time, and you'll do it worse than if you'd thought about it up front.
P.S. I know I've ignored change management, and traceability - but this is a blog not a textbook.