Sold to the fine

 
Testing Software Requirements Specifications 
(SRS) 
Most of the bugs in software are due to incomplete or inaccurate functional requirements. The 
soft a e ode, does t atte ho ell it s itte , a t do a thi g pu poseful if the e a e 
ambiguities in the requirements. 
Cost of fixing the bug after completion of development or product release is too high. 
Thus it s ette
to have requirement analysis and catch the requirement ambiguities and fix them in early 
development life cycle. 
How to measure and freeze requirements in design phase? 
We need to define some standard tests to measure the requirements. Once each requirement is 
passed through these tests you can evaluate and freeze the functional requirements. 
He e is o e e a ple to easu e e ui e e ts. Let s sa ou a e o ki g o a e ased appli atio
and the requirement is as follows:

---

www.SoftwareTestingHelp.com
 
PAGE 53
Software Testing Career Package
 
 
 
© 2015
By Software Testing Help 
 
Web application should respond to user queries as early as possible
How will you freeze the requirement in this case? 
What will be your requirement satisfaction criteria? To get the answer, ask this question to 
stakeholders: How much response time is OK for you? If the answer is, we will accept the response if 
it s ithi se o ds, the this is ou e ui e e t e h a k. F eeze this e ui e e t a d a the 
same procedure for next requirement. 
No let s take a othe e a
mple. For one of our company projects we got SRS document for first 
phase of the application from the client. When we were discussing these requirements, everyone in 
the team was having their own understanding of the requirements. We quickly realized that there are 
lots of ambiguities in this document. We decided to first fix these ambiguities before writing test 
cases or starting design phase. All ambiguous requirements were sent to client with list of questions 
to get those clarified. Later everyone understood the overall project scope and we were clear to start 
project design and writing test cases. 
Requirements should be clear and consistent - Make sure overall project scope and requirements are 
clear to everyone before starting to write test cases.
Generally we use our own method to uncover the unspecified requirements. When we read the SRS 
document, we note down our own understanding of the requirements that are specified, in addition 
to other requirements that SRS document is supposed to cover. This helps us to ask the right 
questions about unspecified requirements. 
Next criteria for testing the requirements specification is 
–
dis o e the issi g e ui e e ts .
Sometimes SRS writer(s) simply assume some requirements. But requirements should not be based 
on assumptions. Requirements should be clear and complete covering each and every aspect of the 
system to be developed. Requirement specifications should mention both types of requirements i.e. 
what system should do and what should not. 
For checking th
e e ui e e ts o plete ess, di ide e ui e e ts i th ee se tio s, ust 
i ple e t e ui e e ts, e ui e e ts those a e ot spe ified ut a e assu ed a d thi d t pe is 
i agi atio t pe of e ui e e ts. Che k if all e ui e e t t pes a e add essed ef
ore design 
phase. 
Check if the requirements are related to the project goal - Sometimes SRS writers have their vision 
about the functionality of later phases of the application. For that they may introduce some 
requirements in current phase of the application which they may just want to implement but not use 
until the later parts are completed. We need to understand such requirements carefully. If you thing 
any requirement is not relevant to scope of the current phase being developed you can ask question 
about the purpose of that requirement. This will then describe the particular requirement in detail 
making it easier for designing and testing the application considering the future scope. 

---

www.SoftwareTestingHelp.com
 
PAGE 54