Requirement quality affects work performed in subsequent phases of the system life cycle. Requirements of poor quality:

There never seems to be enough time to do it right, but time is found to do it over—if funding is available!

Associated information
Information is associated with the requirement. This information is necessary for managing the project as well as the requirements. For example, associating priority and WBS with requirements facilitates planning and scheduling, associating change history with the requirement faciliates change control, while other associated information is necessary to produce traceability and other requirements management reports.

Completeness means there is enough information to proceed to the next stage or phase of work without risking a serious amount of rework. An example of incomplete requirements:
The system shall validate charges over $100.
The system shall accept charges under $100.

What about charges of $100? Correcting the first requirement to state:  "The system shall validate charges of $100 or more" is one way to address the situation.

Ensuring completeness is hard work, although models can help.

Consistent terminology.

  • A glossary helps achieve consistent terminology. Even commonly understood terms can create headaches later if they are undefined because they can change meaning over time.
  • Acronyms common to the users' business can be used in requirements. Define them in the glossary for newcomers to the project.

Lack of conflict among requirements.

  • Conflicting subjects: a requirement for blue backgrounds and one for red.
  • Conceptual conflict: a requirement for accessibility and one requiring red and green on the GUI.

Use the RM tool to search on key words and phrases to locate consistency problems. Key word and phrase searches may not locate conceptual conflicts. Diagrams can be also be used to locate some inconsistencies.
The requirement is technically and operationally possible to do within existing constraints. The constraints are typically time and money. For example, we can send a person to Mars, but not within a year and under a thousand dollars. An example of a technically infeasible requirement is time travel.

An infeasible requirement does not always cease to be a requirement. Thinking these requirements cease to be requirements is a contractor/project's perspective. It is true they are not requirements for the project. But, if the client is enlightened and will use the respository for product maintenance, the requirement may be retained for future implementation. Typically, however, the requirements repository (if there is one at all) is scrapped after completion of the contract because it was not specified as a deliverable.
The requirement does not rely on another requirement to be fully understood.

Requirements that need proxies are not independent. Parent requirements rely on their children to be fully defined. In testing, a parent is not satisfied until all its children are met. Why retain them? These may be source requirements that must be retained. Also, using them to structure the proxies or children improves understandability. For example, "user friendly" can be used to assign, talk about, or locate the group of proxies defining "user friendly" for that particular project. See examples of proxies.

Next page

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