|
|
It is a well established
fact that early involvement
of testers during the
software development life
cycle brings immense
value to the project.
Participation of
the testers during
the requirement phase helps
in identifying and
correcting defects in the requirements.
As a tester if you are
involved in the requirement
phase you need to know ,
what attributes you should
be looking for in the
requirements? How can
you ensure quality of the requirements?
Following checklist gives
you information about the
attributes which should be
tested for every
requirement. These are just
a subset of attributes that as a
tester you will be
interested in.
|
a. Complete:
Every requirement should
be complete and give
complete information on what
is expected. For example,
provide a shopping cart to
the website is not a
complete requirement.
Complete requirement could
be stated as "Provide
shopping cart to the
registered user who can pay
using credit card and are
within the EU region"
b. Correct:
This is self explanatory, it
is expected that every
requirement specified in the
requirements document will be
correct. This can be ensured
by having stake
holders/client
representatives in the team.
c. Precise,
Unambiguous and clear:
Each item in the requirement
should be clear and have
single interpretation, for
every member in the team;
the meaning of each item
should be understood and
specifications should be
easy to read. For example,
response time of the
application should be good.
Now good can have different
meaning for different
people. Requirement should
be stated as "With an
anticipated load of 1000
simultaneous users, system
should respond with in 4 seconds."
d. Consistent:
Requirement should not
conflict with each other.
For example if one
requirement states that
"Additional 2% charges
should be applied for the people
shopping out side US" and another
says "Options to buy/sell
should be disabled for the
people who are not in US",
these two requirements are
conflicting. Either one of
them is wrong or not clear,
and you should seek
clarification from the stake
holders or clients
representatives.
e. Relevant:
Each item is pertinent to
the problem and its
solution. For example, if we
are dealing with the problem
of providing web interface
to the existing retail
operation, information
related to staffing may or
may not be pertinent to the
problem we are solving. You
should hunt for
clarification on why this
item is present in the
requirements documents.
f. Testable:
Every requirement should be
testable, it should be
possible to determine
whether the stated requirement
has been satisfied or not.
For example, requirements
like application navigation
should be very good is very
difficult to test. Testable
requirement should be that
"The user should be able to
navigate from one page to
any other page on the site
with maximum three clicks".
g. Feasible:
It should be possible to
implement requirement with
the available techniques,
tools and resources within
the specified cost and schedule
constraints.
h. Free
of Unwarranted Design
Detail: The requirements
specifications are a
statement of the
requirements that must be
satisfied by the problem
solution. Requirements
document, ideally should not
implementation and design
details.
i.
Manageable: The
requirements should be
expressed in such a way that
each item can be changed
without excessive impact on
other items. Even if there
is any impact, it should be
minimum and and it should be
possible to identify
dependencies in the
requirements for impact
analysis. Hope this
template was useful for you.
You can also visit
defect report and
test
plan in this section.
Your feedback is
important to us. Please
provide your
feedback. | 
