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

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.

Answer 2

OK, this is more than 7, but good requirements have the following attributes:

• Unique. Are there any other requirements that are similar?
• Identifiable, Can the requirement be uniquely identified? Can it be traced throughout your development process?
• Complete. Is anything missing or forgotten? Is it thorough? Does it include everything necessary to make it stand alone?
• Accurate. Is it correct? Does it properly define the goal? Are there any errors?
• Unambiguous. Is the description exact and not vague? Is there a single-interpretation? Is it easy to read and understand?
• Consistent. Is the description of the feature written so that it doesn't conflict with other items in the specification?
• Relevant. Is the statement necessary to the feature? Is it extra information that should be left out? Is it traceable to an original customer need?
• Feasible. Can it be implemented with the available personnel, tools, and resources within the specified budget and schedule?
• Code-free. Does the specification stick with defining the product and not the underlying software design, architecture, and code?
• Testable. Can it be tested? Is enough information provided that a tester could create tests to verify the requirement is satisfied?
• Prioritized. Is it more or less important than other requirements?
• Uses Active Voice. Does the specification use the active voice? Passive voice doesn't always specify who or what performs the action.
• Categorized. Is the requirement logically grouped with similar requirements? Possible categories are: Behavioral, Performance, Interface, Data Structures/Elements, Implementation, Compliance/Quality, Operational (Reliability, Safety, Security), Derived/Engineered.

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.

Answer 3

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.

Answer 4

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.

Answer 5

Ambiguous requirements are bad.

Unverifiable and unquantifiable requirements double so.

Answer 6

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