REQUIREMENT TESTABILITY CONTINUED
Non-specific Acronyms and Words
Avoid "etc.," "and/or," "TBD." TBD can be used during the analysis process to indicate ongoing work, but should not be in the final requirements.
Words and phrases include: as appropriate, if practical, as required, and to the extent necesssary/practical. Their meaning is either subject to interpretation or they make the requirement optional, even if it is included in a contract. If the requirement isn't important, assign a low priority to it. Phrases like "at a minimum" only ensure the minimum, while "shall be considered" requires the contractor to think about it.
Vague words inject confusion. Examples of frequently used vague verbs are:
Negative Requirements (Not)
Everything outside the system is what the system does not do. Testing would have to continue forever to prove the system does not do something. State what the system does.
It isn't that difficult to correct a negative requirement. Substitute an active verb that expresses what the system must do. For example change "the system shall not allow X," to "the system shall prevent Y." Another method is to use the prefix "un," such as: The system shall reject unauthorized users.
Assumptions and Comparisons
The requirement "the system shall increase throughput by 15%" sounds testable, but isn't. In this real life example, the assumption is "over current system throughput." By comparing to another system, the meaning of the requirement changes when the other system changes. For example, if current system throughput becomes even more reduced, the required result could be a new system with less throughput than that which initiated the requirement. On the other hand, if current system throughput is dramatically improved while waiting for the new system, the requirement could become technically infeasible. Such requirements create disputes later in the SDLC.
Another example, sometimes found in requests for proposals, is: "The system shall address the future needs of users." The writer is, probably, thinking ahead to after the contract is awarded. The requirement is meaningless because whenever it is read, it will point to the future. A non-technical requirement for change management as part of project management processes, rather than levying a requirement on the system, would make sense.
Indefinite pronouns stand in for unnamed people or things, which makes their meaning subject to interpretation. Some of these may find their way into requirements:
Review any requirements conjunctions such as "and" or "but" to see if the requirement can be interpreted in more than one way.
While is it not incorrect to use "and" where multiple items must be included, it facilitates work later in the SDLC, particularly testing, if the multiple items are shown as a list. The list approach avoids misunderstandings when reviewing requirements for traceability. See examples of lists.
Visit other sites to find out more about requirements and testing:
Page updated 1/14/2012
Ludwig Consulting Services, LLC