There are several reasons:
- the most basic reason: do we have a requirements problem, and if so, how big a problem do we have (i.e., as an input to estimating the amount of work to do a requirements analysis)
- we are a manager and have staff developing a requirements specification or doing a requirements analysis. Are they working effectively?
- we set a standard for our requirements specifications in terms of the value of a requirements quality metric, actually, more probably three values for different circumstances:
- original novel development in demanding circumstances
- original novel development in non-demanding circumstances
- very routine development or acquisition
- in contracting with a service provider to develop a requirements specification or do a requirements analysis to a defined standard
- as a professional service provider providing professional advice on requirements quality, in terms of the value of a quality metric, followed an interpretation of the consequences of the quality value in the circumstances which apply
- in requirements-related litigation.
Of all the metrics in use in engineering, I find a requirements quality metric to be one of the most valuable, addressing as it does historically the single biggest problem in engineering: developing the wrong thing.
