When reviewing requirements specification what “de

问题:

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.

回答1:

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.

回答2:

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

回答3:

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.

回答4:

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

回答5:

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

回答6:

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.

回答7:

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.

回答8:

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?

回答9:

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.

回答10:

Over stringent - If possible specify relevant tolerances.

回答11:

Ambiguous requirements are bad.

Unverifiable and unquantifiable requirements double so.

回答12:

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.

回答13:

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)

回答14:

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

回答15:

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.

回答16:

• 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

回答17:

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.