Requirements and associated information can be changed.

The method of storing requirements affects modifiability. For example, requirements in a word processor may be more difficult to modify than in a requirements management tool. But, for a very small project, the cost and learning curve for the RM tool may make the word processor a better choice.

Consistency affects modifiability. Templates and glossaries for requirements make global changes possible. Templates should exclude information that will be associated with the requirement.

For example, "the Calculation Module shall determine the gross amount of annuity," must be reworded if the name "Calculation Module" is changed or if annuity calculating is moved to another module. This change will be in addition to updates to the information or linkages associating the requirement with the Calculation Module in the requirements repository.

Implementing global name changes increases the potential for injecting errors. Design requirements standards to minimize the number of changes needed to maintain requirements.
The requirement should be necessary. Some unnecessary requirements:

Included in an SRS: The system shall be designed to accommodate the capabilities in the system requirements specification document.

The real object of this requirement is project processes, and it has no place in product requirements. Every requirement, product, and test would have to be traced to this requirement resulting in a requirements repository cluttered with meaningless traceability. The requirement is also vague. What is actually meant by "accommodate"?

A traceability matrix is used to verify that a product includes planned requirements. The correction is to delete this requirement from the SRS. A requirement to deliver a compliance matrix with each product can be included in the contract or process standard.

Included in an SRS: The system shall be accepted if it passes 25 test cases.

Unless the term is defined for the project, "test cases" has no standard meaning, so the requirement is meaningless. In addition, this requirement attempts to set a contractual standard for the client through the backdoor. If the SRS were attached as part of the statement of work (contract) for the next phase of work, it could limit the client's ability to fully test the product before accepting delivery and will certainly lead to disputes. The correction is to delete the requirement from the SRS and create a test plan.

No unnecessary design
The requirement is free of unnecessary design. Read examples of unnecessary design.
Duplicate requirements cause problems:

  • Duplicates increase maintenance. Every time a requirement changes, its duplicate(s) also must be updated.
  • Duplicates increase the potential for injecting errors. For example, redundant requirements may be overlooked and not updated.

It is OK to associate more than one product with the same requirement in the traceability matrix. If there are duplicate requirements, analyze them to see if they are really the same. If they are different, rewrite them to make their differences clear. If requirements are related, but located in separate areas of the repository or document, they can be cross-referenced.

Has no unnecessary verbiage or information.

In view of the need to achieve high understandability and in order to increase the amount of comprehensibility, in a number of cases, the removal of multiple words-specifically those that are not central to the understanding of the requirement-is a necessary and prudent action owing to the fact that a requirement with fewer words can be understood in a somewhat more satisfactory manner than in the case of a requirement with more words and the same meaning.

To improve clarity, edit out remove extraneous words. Terse requirements are more easily understood than long ones.

Next page

Page updated 2/13/2006
Ludwig Consulting Services, LLC