SOFTWARE

VERIFICATION
AND
VALIDATION 1

(SQT)
How to write Testable Requirements?
 WHAT IS A
2
TESTABLE
REQUIREMENT?
 A testable requirement describes a single function or behavior
of an application in a way that makes it possible to develop
tests to determine whether the requirement has been met.
 To be testable, a requirement must be clear, measurable,
and complete, without any ambiguity.

3
 HOW TO WRITE
4
A TESTABLE
REQUIREMENT?
• For example, assume that you are planning to test a web shopping
application.
• You are presented with the following requirement: “Easy-to-use
search for available inventory.”
• Testing this requirement as written requires assumptions about what
is meant by ambiguous terms such as “easy-to-use” and “available
inventory.”
• To make requirements more testable, clarify ambiguous
wording such as “fast,” “intuitive” or “user-friendly.”
• Requirements shouldn’t contain implementation details such as “the
search box will be located in the top right corner of the screen,” but
otherwise should be measurable and complete. 

5
 HOW TO WRITE
6
A TESTABLE
REQUIREMENT?
 Consider the following example requirement for a web shopping
platform:
 “When at least one matching item is found, the system shall display
up to 20 matching inventory items, in a grid or list and using the sort
order according to the user preference settings.”
 However, this requirement describes more than one function. It
would be better practice to separate it into three separate testable
requirements, as shown below:
 When at least one matching item is found, the system shall display up to
20 matching inventory items.
 The system shall display search results in a grid or list according to the
user preference settings.
 The system shall display search results in the sort order according to the
user preference settings.

7
 DONTS OF A
8
TESTABLE
REQUIREMENT
 Testable requirements should not include the following:
 Text that is irrelevant. Remove anything that doesn’t add to your
understanding of the requirement.
 A description of the problem rather than the function that solves it.
 Implementation details. For implementation details such as font
size, color, and placement, consider creating a set of standards
that apply to the entire project rather than repeating the standards
in each individual requirement.
 Ambiguity. Specifications should be specific. Avoid subjective terms
that can’t be measured, such as “usually.” Replace these with
objective, measurable terms such as “80%.”

9
 SAMPLE
10
TESTABLE
REQUIREMENTS
 The user shall be able to login into the system within three
seconds.
 Registered users shall be able to post maximum 5 post per day.
 The system shall respond to all user commands and data entries
within 3 seconds.
 The application shall support windows and LINUX operating
systems.
 The user shall be able to make a call using the internet
connection within 0.5 seconds.
 The captain shall be able to contact the rider via phone call/ sms.
 The system shall display the details of the driver to the user after
0.5 seconds of ride booking.

11
CLASS ACTIVITY 04:
WRITING TESTABLE
REQUIREMENTS
Make a group of 3-4 members. Tear a page out and write your

Names and ID’s on it.
 Take into consideration the an application and write only four
testable requirements. Assign each requirement a unique ID.
 Solution: Discussed on board.

12