How to Test Software Requirements Specification (SRS)?

Are you aware that “Most of the Bugs in software are due to incomplete or inaccurate functional requirements?” However well it is written, the software code does not matter and nothing can be done if there are any ambiguities in requirements.

This article on Software Requirements Specification (SRS) states that Requirements must be clear, specific, measurable and complete without contradictions.

It’s better to catch the requirement ambiguities and fix them in the early development life cycle itself. 

How to Test Software Requirements Specification (SRS)_

Cost of fixing the bug after completion of the development or product release is too high.  So it’s important to have requirement analysis and catch these incorrect requirements before design specifications and project implementation phases of SDLC.

How To Measure Functional SRS Documents?

Well, 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.

Let's take an example, you are working on a web-based application. The requirement is as follows: “Web application should be able to serve the 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 the stakeholders: How much response time is ok for you? If they say, we will accept the response if it's within 2 seconds, then this is your requirement measure. Freeze this requirement and carry the same procedure for the next requirement too.

We just learned how to measure the requirements and freeze those in Design, Implementation and Testing phases.

Now let's take another example: I was working on a Web-Based project. Client (stakeholders) specified the project requirements at the initial phase of the project development. My manager circulated all the requirements in the team for review. When we started the discussion on these requirements, we were just shocked!

Everyone was having his or her own conception about the requirements. We found a lot of ambiguities in the ‘terms’ specified in the requirement documents, which later on was sent to the client for review/clarification.

The client used many ambiguous terms, which were having many different meanings, making it difficult for us to analyze the exact meaning. The next version of the requirement doc from the client was clear enough to freeze for the design phase.

From this example, we learned that “Requirements should be clear and consistent”

Next criteria for testing the requirements specification is “Discover missing requirements”, let's take a look at it.

Discover Missing Requirements

Many times the project designers don't get a clear idea about each specific module and they simply assume some requirements in the design phase. Any requirement should not be based on assumptions. Requirements should be complete, covering each and every aspect of the system under development.

Specifications should state both types of the requirement i.e. what system should do and what it should not.

Generally, I use my own method to uncover the unspecified requirements. When I read the Software Requirements Specification document (SRS), I note down my own understanding of the requirements that are specified, plus other requirements that the SRS document is supposed to cover.

This helps me to ask the questions about the unspecified requirements thereby making it clearer.

For checking the completeness of the requirements, divide requirements into three sections, ‘Must implement' requirements, requirements that are not specified but are ‘assumed' and the third type is ‘imagination' type of requirements. Check if all the type of requirements is addressed before the software design phase.

Check If The Requirements Are Related To The Project Goal

Sometimes stakeholders have their own expertise, which they expect to come in the system under development. They don't even think whether that requirement would be relevant to the project in hand. Make sure to identify such requirements. Try to avoid all irrelevant requirements during the first phase of the project development cycle.

If not possible, then ask the questions to stakeholders like why do you want to implement this specific requirement? This will describe the particular requirement in detail, thereby making it easier for designing the system considering the future scope.

But how to decide whether the requirements are relevant or not?

Simple answer: Set the project goal and ask this question: If not implementing this requirement will cause any problem achieving our specified goal? If not, then this is an irrelevant requirement. Ask the stakeholders if they really want to implement these types of requirements.

In short, the Requirements Specification (SRS) doc should address the following:

  • Project functionality (What should be done and what should not be done).
  • Software, Hardware interfaces, and the user interface.
  • System Correctness, Security and performance criteria.
  • Implementation issues (risks) if any.


I have covered almost all aspects of requirement measurement. To be specific about requirements, I will summarize requirement testing in one sentence:

“Requirements should be clear and specific with no uncertainty, requirements should be measurable in terms of specific values, requirements should be testable having some evaluation criteria for each requirement, and requirements should be complete, without any contradictions”

Testing should start at the requirement phase to avoid further requirement related bugs. Communicate more and more with your stakeholders to clarify all the requirements before starting the project design and implementation.

Do you have any experience in Testing Software Requirements?

Please feel free to share them in the comments below.

Recommended Reading

148 thoughts on “How to Test Software Requirements Specification (SRS)?”

  1. Hey guys, Plz keep this article and discussions to the main topic Testing Requirement Specifications…ask your other questions in relative blogs…..dont mind otherwise

  2. Hi ,

    I need winrunner free Trial version ,can any one tell me the link to get the trial version.Its very urgent please reply.

  3. Hi guys !

    I am in bangalore searching for jobs in software testing field .my qualification is 10+2+3yrs(Dip in IT). can any one help me to get a job in this field .I am the freshers i have knowledge of both manual as well as automated pl help me .

    Advance Thanks.

  4. @ Manikandan,

    Bug Free Software ???
    Nothing like that exixts, if you know – please tell me know, i would love to look at it.

    Regards, Suhas M.

  5. Hi all,
    In the first time i come this page, I like it very much, thanks all.
    My company is out sourcing company, some time, us project has to create SRS document to know more requirement from customer.
    SRS is reviewed by QA group or experts, after modified it is approved by manager and announce for all project member (Tester is one member in this group).
    I agree with Vijay, SRS is importance so all project team have to read before create test plan, test case (to tester) or design (desginer) or coding (dev).
    Finally i want to share my opinion that: SRS is reviewed by experts before used.

  6. Well, SRS review is very much necessery. SRS followed by FS review would be carried out by the technical experts along with the BA. There is always very little involvement from the testers side.

    Best practice would be to involve test management in this phase we can stream-line testing along with development.


  7. Hi Vijay,

    I am Vishal, curently working as QA in a small company at Kolkata. I have done Bsc and currently persuing Msc IT from Sikkim Manipal. Pls advice me which certification should I go for to boost my carrer.


  8. For checking the requirements completeness, divide requirements in three sections, ‘Must implement’ requirements, requirements those are not specified but are ‘assumed’ and third type is ‘imagination’ type of requirements. Check if all type of requirements are addressed before software design phase.

    Here what is the difference between “Requirements those are not specified but are assumed” and “Imagination type of requirements”. Can you explain with an example.

  9. @Vikas Kumar
    this is very basic question ..and i believe it wont be ant problems if u know QTP..
    this is wt u learn very 1st in QTP dude,,
    so get basic right and enjoy automation..

  10. Hi,
    I want to know about the ISTQB
    The process of apply?How to register?the study Material?The palce of Test?Also the eligiblity criteria?
    Plz inform me….

  11. hi Ashish,

    i got your mail because of time matters,i unable to give reply.

    its better to call me directly,i will help you

    my number:9391395989

    ch.girish chander raju

  12. hai Vijay
    I am fresher in software testing field. I have been learning “How to test software requirements specification?”,but i don’t have mature to use your method to application?

  13. Hi all…
    Yr since three months(My First three months of First job) i have been working on a product and Mgmt asked to to prepare srs on a module on which i haven’t worked on.. though i got KT but i think practicing physical would be more helpful. Can u people help me out in defining Scope of Project..
    what pts shall i mention in it..
    Plz help me out

  14. Hi this is Dinesh i am working as Tech. Support govt Organisation.i am ISTQB certifed but still i am wating for testing job.
    what can i do.
    ( I want to change my profile)


  15. Vijay,

    I am Ramesh, curently working as QA in a small company at Pune. I have done Bsc and currently persuing Msc IT from chavan institute. Pls advice me which certification should I go for to boost my carrer.
    i am intrested in softwere testing

  16. The article is good enogh for Testers. But I have a question- If there is no document (SRS, SDD, UI etc.) how to test that application?

  17. Hi Sajib, #98

    It is too difficult to test the application without spec. It is just like a blind test. You can’t judge the user’s needs, thoughts and requirements.

    Starting a project with spec is the best practice on working with.

    In some cases, for micro level projects there are some chances to skip the spec. docs, on such cases try to document the discussions (MOM) from the initial phase, so that it will be much more helpful during the time of testing. From that you can derive the spec for your application for testing purpose.

  18. Nice info, the site is very helpful for me.

    I am about to appear for my istqb certification exam and I am very confused as how to derive testcases with some of the test techniques like statement, branch and condition coverages.

    Can anyone please help me.
    My email address is



Leave a Comment