Requirements Writing - Syntax and Grammar

A Specific Requirement must be:

• Correct and complete - it must express a complete thought.
• Clear and consistent - eliminate ambiguous and conflicting requirements.
• Testable and traceable - the Requirements Analysis process helps here.
• Modular and Modifiable - minimize or eliminate inter-relations between requirements.
• Design independent - do NOT specify implementation!

Syntax & Grammar of a Specific Requirement

Follow the standard sentence syntax:

The <noun> will do <action verb> to <direct object>.

E.g. “The user will be able to save the data to a file.”

Without an action verb, the tester has no action to perform during testing. For example, a requirement like "The software will have a main menu" has no action verb. This requirement could be fulfilled by the simple placement of a non-functioning main menu. The menu exists and need do nothing - and it passes the test! A better requirement would be "The user [noun] shall be able to print the file [verb] from the main menu [direct object]." This requirement can only be fulfilled by having a main menu that actually does something.

Common Pitfalls

• Multiple requirements wrapped into one (i.e. not modular).
• Mixed level of detail.
• Speculation - e.g. often, or normally.
• Vague or non-quantifiable terms - e.g. flexible, user-friendly, fast.
• Suggestions - e.g. may, might, should.
• Wishful thinking - e.g. Handles all errors.
• Forward-looking statements - e.g. "in the future, the software will add this feature..."
• Not testable - e.g. no action verb, or it should be a non-specific requirement.
• Too much detail - e.g. implementation details. This may also indicate that the requirements were written in retrospect - after the software was coded.

Informal Requirements Languages

Formal Requirements Languages