Metrics can be very helpful, but only if the value of them is worth the value of the time put in to track them. And keep in mind, metrics are designed to be used for analysis and improvement, not necessarily for management 'on the fly' of current projects.
So, while I see the need to track the kind of information one is looking for, I think it would be difficult to get useful metrics if the requirements are not stabilized.More importantly, what is it you are trying to analyze about the requirements? For what purpose?
If you want to be able to better analyze the requirements and how to go about testing them, then try to implement some sort of weighting practice. Have the business side prioritize requirements based on how critical they are to have in a particular (or first) release of the application. Have the technical people estimate the amount of effort required to implement, and it should be easier to plan development and testing based on that sort of matrix.
If you're concerned about change, consider using a requirements management tool- there are commercial apps, or do something as simple as keeping a spreadsheet of the current requirements at a high level, and tracking changes to each requirement. Try to implement some level of change management or change control through your defect tracking system - defects can be written do documentation as well, and can track change requests as easily as actual errors.
