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

Missing requirements - Much harder to catch. Seperating out requirements into clear sections (e.g. safety, performance, styling, etc) can make this easier to spot.

Answer 2

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.

Answer 3

Making assumptions - double check that anything that looks like an assumption has actually been verified.

Answer 4

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)

Answer 5

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.