Assuming that you are asking if there is some kind of typical measure of how many requirements for a given system are in fact incorrect in some way, the simple answer is it depends.
Is a requirement that turns out to be unusable once implemented a defective requirement?
What about one that the customer insists they want then never use?
Do you include the additional requirements that can't be known until well into development?
This is why software development has changed from trying (and failing) to enforce strict process models to a more flexible agile-like approach. Unlike manufacturing, every software project is different, and every software project can be completed in a number of different ways and still satisfy the customer - in short, software development is a wicked problem and apart from small, clearly bound projects is likely to stay that way for the foreseeable future.
So, you're unlikely to find any references on how many requirements are typically defective in some way. You'd do better looking for resources about keeping the requirements up to date as a project evolves.