It is very hard to objectively quantify and/or measure the quality of requirements upfront.

The main thing you need to do upfront is consider putting in place some guidelines and best practices for writing and capturing requirements, for example:

• ensure each requirement is tracked back to a business goal/need - or else you're likely working on the wrong thing;
• ensure each requirement is objective and un-ambiguous; requirements which are not objective are open for interpretation and the clients tent to not interpret them in your favor - > examples of bad requirements: the system shall "be fast", "support multiple users", "be user friendly"...
• insist that requirements only contain the requirement and not design decisions aka keep solutioning apart from requirements;
• validate the requirements with the business stakeholders;
• create prototypes or wire-frames or solution documents which explain how the requirements might be realized by the system and place those in the broader business process => get feedback from the stakeholders.

OK - we can you measure the quality of requirements?  Probably only after the fact... The real test of good requirements if they deliver a system which fills the need the business has.  Once requirements have been realized and delivered you can measure all kinds of things such as:

• from the stakeholder's perspective, how many requirements were not implemented as per their expectations => need to find the root cause: ambiguous requirement, business need changed, etc.
• track how many requirements change over time for reasons other than changing business need,
• how many new high priority requirements are discovered during the development, QA, and production.

The one thing to keep in mind is that it is also possible that each requirement, by itself, is a "quality" requirement and still deliver a system which does not meet the business need.  Why?  There could be many reasons but one of the, related to requirements is:  the totality of requirements don't solve the business problem.  It is rare that one single requirement solves a business need.  Usually it's the entire package or sets of requirements which provide value to the business.

Hope this helps!

- Adrian