Able to prove (validate) the object of the requirement satisfies the requirement. Untestable requirements can lead to disputes with the client. See what can make a requirement untestable.
Each product can be associated with its originator and vice versa. Traceability is key to verifying 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 annuities and survivor benefits," is a compound requirement. If the first build only includes retirement annuities, it will fail the requirement during testing. But, if the product is marked as having passed testing, the record is that the entire requirement was met. As a result survivor benefits may be excluded from later builds. This is not the only problem compound requirements can cause. Requirements with lists are not necessarily compound:

The system shall report retirement claim status as one of the following:
  • pending
  • complete

The interface shall accept the following data:
  • data A
  • data B
  • data C

These requirements are not compound because they express a single need at their level of decomposition. The second list could be written as three requirements, but this would add unneeded complexity and maintenance overhead to the requirements repository. At this level of requirement, there is no need for further decomposition: all three data items must be included for the interface to pass testing.

While is it logically correct to use "and" where multiple things must be included, showing multiple items as a list facilitates work later in the SDLC, particularly testing. The list approach also avoids misunderstanding when reviewing requirements for traceability.

Understandable requirements are organized in a manner that facilitates overall review.

Requirements management tools can facilitate multiple ways of organizing requirements so that reports can be tailored to different audiences. Some ways to organize requirements include:

  • Organize requirements by their object. Separate non-technical requirements from requirements directed to the actual product. Non-technical requirements, for example, might specify development team processes or how the team must work.
  • User requirements can be organized by business process or scenario. This allows the subject matter expert to see if there is a hole in the requirements.
  • Separate functional from non-functional requirements. Non-functional requirements are those that relate to areas such as performance, reliability, availability, accuracy, and capacity.
  • Organize requirements by level, which determines their impact on the system.

Understandable requirements are grammatically correct and written in a style that facilitates review by the affected parties.

Standards help ensure all requirements have the same style. Various organizations, such as IEEE, have created standards for writing requirements that can be leveraged for your project. Remember: while these standards attempt to address many situations, additional details may be needed for your project. A typical format is:
The system shall [verb] [object of verb].

Understandable requirements are written in the imperative.

Use "shall" for requirements. Do not use "will" or "must." Requirements are a statement of work to be performed and, even though a requirement is included in the contract, using non-imperative words make implementation of the requirement optional, potentially increasing cost and schedule, reducing quality, and creating contractual disputes. If it isn't that important, associate a low priority rating with the requirement and schedule it for later implementation.
Within scope
All requirements are within the area of consideration. Models can help ensure requirements for a system are within scope.

The scope of a project is determined by all the requirements established for the project, including—but not limited to—those levied on deliverables. For example, the scope of a project may also include a requirement to provide user help services. The scope of a contract can be wider than the scope of a project if all possible contract requirements have not been tasked.

Project and contract scope get refined as requirements are identified, analyzed, and baselined. For example, where the system has external interfaces, scope decisions may need to be made about the system boundary or services to be performed related to the interface. These are important decisions that can affect cost and schedule and may require special meetings and analyses before the requirements can be settled.

Next page

Page updated 7/3/2006
Ludwig Consulting Services, LLC