What are the metrics for a good SRS (Software Requirement Specification)?

Question

I have been searching but all that I have found is the characteristics of a good SRS (Software Requirement Specification). What are the metrics you could use to verify it is good?

Answer 1

Some of the metrics for a good SRS are no different than the metrics defining any good specification. For example:

• maturity: measured by number of TBXs, shorthand for to be determined (TBD), to be reviewed (TBD), to be suppplied (TBS), etc.
• verification information: in a good spec, each requirement will have an associated verification method (i.e. test, inspection, demonstration, or analysis) and a methodology (i.e. what action will be taken to verify the requirement). Verification methodology doesn't have to be long, but it's important. For example, if the requirement is a system with some percentage of up-time, how is that going to be measured? For how long? What counts as down?
• baselined: a spec that's not under revision control isn't very useful

Answer 2

Weinberg and Gause proposed an "Ambiguity Metric" in their book "Exploring Requirements. Quality before Design" (Dorset House 1989). The idea is that you ask "qualified individuals" to estimate the cost or effort to design and build a solution to meet the requirements. When the range of estimates is large, you know you still have work to do.

I don't know if anyone ever used this, but I don't think it very practical.

What you can do is quantifying your requirement testing or review process, which you should do anyway. For instance, 17 out of 20 requirements passed the tests. You may calculate a general number, or more detailed depending on the individual tests (e.g. 15/20 are incomplete; 3 we haven't figured out yet how to test ...).

Tests of individual requirements can be any or all of the criteria for 'good requirements' that most textbooks on requirements engineering will offer, e.g.

• Completeness of the requirement template
• Traceability
• Consistent terminology
• Is it relevant for the business objectives?
• Is it testable
• The maturity number Adam proposed is also a good one
• Etc.

Answer 3

IEEE 830 requires an SRS to be correct, unambiguous, complete, consistent, ranked for importance, verifiable, modifiable, and traceable.

Every one of these qualities could be (and should be) verified in their own specific ways. How exactly - depends on the format of SRS document you're using.