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.
Requirements must be specific and unambiguous with respect to what's needed, but should be less so on how to meet the requirements.
Making assumptions - double check that anything that looks like an assumption has actually been verified.
My recommendation and what I always do before a new project is double check the check list on Page 42,43 of Steve McConnell's Code Complete
Poorly worded sentances that contain more than one requirement. Seperate them out somewhere to make them more clear and easier to tick off as done.
Requirements that are not easy to verify as being met - Change to a form that can be more easily marked as met or not when reviewing.
Missing requirements - Much harder to catch. Seperating out requirements into clear sections (e.g. safety, performance, styling, etc) can make this easier to spot.
Features, Time, Quality - pick any two. make sure the requirements do not impose all three on your team.
Push back on requirements that try to control your process.
Ask for clear prioritization from the beginning.
Insist on a clear acceptance criteria for each requirement.
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?
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.
Ambiguous requirements are bad.
Unverifiable and unquantifiable requirements double so.
The all knowing wikpedia has a good synopsis for requirements- http://en.wikipedia.org/wiki/Requirement#Good_requirements. I would say that of those points, lack of verifiability is what is most common. Understanding the big picture is important in life, however, you need to spell things out explicitly in you requirements, ex. The system shall be respond quickly. Instead, the system shall respond to all requests in less than 2 seconds.
Naturally, all this depends on what kind of requirement you get. I'm used to typical Gui or Web application, batch processes and
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.
OK, this is more than 7, but good requirements have the following attributes:
A decent requirements tracking tool can automate/enforce some of the above, like Identifiable, Prioritized, Categorized, but only a review by the team can check the rest. The key is in training your team on these attributes, getting them practice by reading both good and bad examples of requirements, and establishing an efficient review process that checks requirements early enough in your life cycle as to have an impact on the downstream activities.
Avoid 'weasel words' - any language that can be wrested from its context and made to sound bad is bad.
Make sure everything is absolutely clear: vague == Bad Thing (tm)
You might consider reading some of Requirement management and CMMI documents.
Also visit Requirement Checklist and google for "Criteria of Good Requirement".
These are specifically designed to create processes helping in software development.