Again from the IEEE standard:
An SRS should be
- a) Correct
- b) Unambiguous
- c) Complete
- d) Consistent
- e) Ranked for importance and/or stability
- f) Verifiable
- g) Modifiable
- h) Traceable
Correct – This is like motherhood and apple pie. Of course
you want the specification to be correct. No one writes a specification
that they know is incorrect. We like to say – "Correct and Ever
Correcting." The discipline is keeping the specification up to date
when you find things that are not correct.
Unambiguous – An SRS is unambiguous if, and only if,
every requirement stated therein has only one interpretation. Again,
easier said than done. Spending time on this area prior to releasing
the SRS can be a waste of time. But as you find ambiguities – fix them.
Complete – A simple judge of this is that is should be all that is needed by the software designers to create the software.
Consistent – The SRS should be consistent within
itself and consistent to its reference documents. If you call an input
"Start and Stop" in one place, don’t call it "Start/Stop" in another.
Ranked for Importance – Very often a new system has
requirements that are really marketing wish lists. Some may not be
achievable. It is useful provide this information in the SRS.
Verifiable – Don’t put in requirements like – "It
should provide the user a fast response." Another of my favorites is –
"The system should never crash." Instead, provide a quantitative
requirement like: "Every key stroke should provide a user response
within 100 milliseconds."
Modifiable – Having the same requirement in more than one place may not be wrong – but tends to make the document not maintainable.
Traceable – Often, this is not important in a
non-politicized environment. However, in most organizations, it is
sometimes useful to connect the requirements in the SRS to a higher
level document. Why do we need this requirement?