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.

Modifying Phrases

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

Vague words inject confusion. Examples of frequently used vague verbs are:

manage track	handle flag

Information systems receive, store, calculate, report, and transmit data. Use words that express what the system must do.

Problem requirement: The system shall process ABC data to the extent necessary to store it in an appropriate form for future access.

Discussion: Vague words and phrases make this untestable. Not terse.

Correction: The system shall edit ABC data.

Pronouns With No Reference

For example: it shall be displayed. When this occurs, the writer is usually relying on a nearby requirement in the requirements document for the meaning of "it." As requirements are assigned for implementation, they are often reordered and regrouped, and the defining requirement is no longer nearby.

Passive Voice

Requirements are written in active voice, which clearly shows X does or provides Y.

Active voice: the system shall calculate Z.
Passive voice: Z shall be calculated. By what?

Words Involving Time

Time-based words can cause confusion or unintended meaning, which could have serious consequences, such as on sizing the system:

until after as

before once until

when earliest latest

instantaneous simultaneous while

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

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:

all another any anybody anything both each

either every everybody everyone everything few many

most much neither no one nobody none one

several some somebody someone something such

Conjunctions

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.

Download an Acceptance Test Plan template

Visit other sites to find out more about requirements and testing:

Software Quality Newsletter

www.stickyminds.com.

Resources for Professional Software Testers

Sizing Software Using Testable Requirements

Software QA/Test Resource Center

ApTest Software Testing Resources and Tools

Requirements Based Testing

Testing Templates & Guidance