How do you measure and improve the quality of requirements in waterfall projects?

Quality criteria is very critical and very important aspects , definition and standards should be followed.Proper Adaption and methods are important.

The MoSCoW criteria are not quality criteria, per se. MoSCoW is a methodology (or paradigm) for prioritizing requirements. It says nothing about the quality of the underlying requirements.

I have found it useful to have defined standards for a requirements document; this drives a common template, style and methodology. Once agreed by the BA team then start a peer review process where work is reviewed prior to being sent out for approval by stakeholders. Integrate feedback before issuing to the wider audience.

I've always found that an inspection meeting with key stakeholders is a big timesaver. It reduces days of back-and-forth emails (with an ever-growing CC list), contradictory edits, and the number of smaller meetings trying to get everyone 'on the same page.' Final revisions are then sent by email, with a deadline. But the success of this method requires real commitment from the BA. Once key stakeholders realize that I'll keep rescheduling until the essential individuals can make it, they find time - and ultimately see its value. In fact, it's very rare for me to need more than one inspection to get to sign-off, and I've never had difficulty getting those same stakeholders to the table in future (in-person or virtually).

I have received success fashioning my requirements gathering and quality control processes based on 'Volere' method. It supports a hybrid delivery cycle.

Testing, as I understand, is the 'Verification' of requirements with the qualities of the software solution. 'Validation' is where the customes/client can solve their problems or meet their needs with the verified system.

Various approaches are there for validation , you can validate the requirements, use collaborative tools , use surveys , leverage networking.

I would say, the qualities enumerated above help compile quality requirements in any development style. Only, the extent of documentation and volume varies. In some styles, all requirements are gathered upfront due to contract requirements while in others they can be progressively elaborated with prototype/MVP using co-located teams.