When reviewing requirements specification what “de

Question

When reviewing requirements specification (that includes functional, non-functional requirements, constraints etc) however small or large it is what are the "deadly sins" committed by authors to look out for?

Please list not more than 7 most essential things (in order of decreasing severity) that being done (or not done) in requirements specification have adverse effect on the quality of software product. Less than 7 is perfectly OK.

Answer 1

Requirements must be specific and unambiguous with respect to what's needed, but should be less so on how to meet the requirements.

Answer 2

The requirement does not specify who/what does the thing.

"The invoice is reconciled to the purchase order."

Does this mean the system does something, or the user?

Answer 3

Over stringent - If possible specify relevant tolerances.

Answer 4

Naturally, all this depends on what kind of requirement you get. I'm used to typical Gui or Web application, batch processes and

• Put up standars first, that don't have to be defined in each specification , refer to them
• Make it as small as possible - rarely one can read a 200 pages document and keep everything in mind
• Be specific, mesurable, concrete
• Do examples (drawings, accounting writings)
• Explain the purpose before describing the funtction
• inlcude performance standards, resilience standars, deployment instructions, documentation for operations needed

I have also one single advice for the reviewer: know your subject

You have to have very detailed knowledge of the requirement's context, the specific client's need, the technical environment and perhaps the most important who this requirement will be addressed to and what level of global understanding they have.

I made very bad experience in projects with many people reviewing the specs since their individual knowledge was very shallow. You get the feed back on the same level, mostly formal corrections but the profound lacks of the specification will only discovered very lately in the project.

Answer 5

• Separation of functional, architectural, interface, non-functional requirements.
• Use of unambiguous and consistent notation to describe entities
• Clear entry and exit criteria for the use cases
• Have flow diagrams ( mindmaps serve the same purpose as UML, and are easier to draw)
• Define the scope in clear terms, what is covered and what is not and where to find those left uncharted
• Have a traceability matrix

Answer 6

Worst one I've seen on a project I coded for:-

The system shall interface to SAP as required.

Firstly, a requirement with "as required" in it is stupid. That one line must have cost $400k. The customer kept pointing at it and saying it says there you're going to do blah, blah, blah.