Requirement Quality Factors

If software testing depends on good requirements, it is important to understand some of the key elements of quality requirements.

Understandable

Requirements must be understandable. Understandable requirements are organized in a manner that facilitates reviews. Some techniques to improve understandability include the following:

* Organize requirements by their object, for example, customer, order, invoice.
* User requirements should be organized by business process or scenario. This allows the subject matter expert to see if there is a gap in the requirements.
* Separate functional from nonfunctional requirements, for example, functional versus performance.
* Organize requirements by level of detail. This determines their impact on the system, for example, "the system shall be able to take an order" versus "the system shall be able to take a retail order from the point of sale."
* Write requirements grammatically correctly and in a style that facilitates reviews. If the requirement is written in Microsoft Word, use the spell check option but beware of the context; that is, spell check may pass a word or phrase, but it may be contextually inappropriate.
* Use "shall" for requirements. Do not use "will" or "should." These are goals, not requirements. Using nonimperative words such as these makes the implementation of the requirement optional, potentially increasing cost and schedule, reducing quality, and creating contractual misunderstandings.

Necessary

The requirement must also be necessary. The following is an example of an unnecessary requirement. Suppose the following requirement is included in a requirement specification: "The system shall be acceptable if it passes 100 test cases." This is really a project process and not a requirement and should not be in a requirement specification. A requirement must relate to the target application or system being built.

Modifiable

It must be possible to change requirements and associated information. The technique used to store requirements affects modifiability. For example, requirements in a word processor are much more difficult to modify than in a requirements management tool such as CaliberRM or Doors. However, for a very small project, the cost and learning curve for the requirements management tool may make the word processor the best option.

Consistency affects modifiability. Templates and glossaries for requirements make global changes possible. Templates should be structured to make the requirements visible, thus facilitating modifiability. A good best practice is to label each requirement with a unique identifier. Requirements should also be located in a central spot and be located with ease. Any requirement dependencies should also be noted, for example, requirement "Y" may depend on requirement "X."

Nonredundant

There should not be duplicate requirements, as this causes problems. Duplicates increase maintenance; that is, every time a requirement changes, its duplicates also must be updated. Duplicate requirements also increase the potential for injecting requirement errors.

Terse

A good requirement must have no unnecessary verbiage or information. A tersely worded requirement gets right to the point; for example, "On the other hand," "However," "In retrospect," and so on are pedantic.

Testable

It should be possible to verify or validate a testable requirement; that is, it should be possible to prove the intent of the requirement. Untestable requirements lend themselves to subjective interpretations by the tester. A best practice is to pretend that computers do not exist and ask yourself, could I test this requirement and know that it either works or does not?

Traceable

A requirement must also be traceable. Trace ability is key to verifying that requirements have been met. Compound requirements are difficult to trace and may cause the product to fail testing. For example, the requirement "the system shall calculate retirement and survivor benefits" is a compound requirement. The list approach avoids misunderstanding when reviewing requirements for trace ability individually.

Within Scope

All requirements must be defined in the area under consideration. The scope of a project is determined by all the requirements established for the project. The project scope is defined and refined as requirements are identified, analyzed, and baselined. A trace ability matrix will assist in keeping requirements within scope.