Seems some people have exaggregated expectations in quality characteristics of IEEE 830. To me the following is already a great achievement:
“Are these requirements all that exist, or just all that your expert could think of?” If someone reacts heavily surprised here, he/she is definitely not an analyst. This is about completeness. Completeness is a property of requirements an analyst is definitely aware of (doesn’t mean that his/her requirements have always to be complete). Completeness is one among the characteristics of software requirements specs of IEEE 830:
“Great! Now can I measure these characteristics in order to produce some pretty figures for my management?” I don’t think so! (try to proof me wrong, if you like) Therefore, the subject of requirements is much too complex.
“So, are these characteristics good for sth at all?”
The point is, that they provide a valuable basis for communication, like for asking questions like the introductory one, in order to create an awareness of what makes good requirements at all. For example, have you ever tried to discuss the traceability of your requirements with so. who isn’t aware of this concept at all? Such discussions are completely useless, unless you have a common basic understanding of what desirable properties of requirements are.
This way IEEE 830 can help turn discussions about the quality of requirements from completely useless to ‘just’ difficult.