I read this in a blog that Most of the bugs in software are due to incomplete or inaccurate functional requirements

I think the main reason for this due is less some lagging in the requirement analysis phase so in this question, I want to know the best practice to analyze the requirement & How much time a tester should devote to go through the requirement.


5 Answers 5


It is not answerable. Answer is: "QA should devote as much time as needed to find out all inconsistencies in requirements, but don't waste anything beyond that". So you are back on square one.

  • To avoid mistakes, good judgement is necessary
  • Good judgement is based on experience
  • Experience is based on learning from past mistakes

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

  • 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.

Testers should:

  • Write Test Cases based on the requirements
  • Clarify any assumed requirements
  • Begin Testing at the requirement phase

Requirements should be:

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

The requirements specification doc should address:

  • Project functionality (What should be done & what should not be done).
  • Software Interfaces
  • Hardware interfaces
  • The User interface.
  • System Correctness
  • Security and performance criteria.
  • Implementation issues / risks if applicable
  • 1
    "with no uncertainty", really? You do know that software development is a profession with one of the highest uncertainties during implementation. What you describe is very old-school and even when it was the best practise it didn't lead to the best results. Dec 18, 2017 at 20:12

When I read the word requirement my spline shivers. It is just an idea, probably a flawed one, it is definitely not required. What that blog describes is traditional waterfall, where the costs go up if defects are found in later stages. Nor does it give any proof that lack of requirements analysis leads to the most defects, I just don't believe it.

Instead of analysing requirements I would say build and deliver the smallest part of an application that would generate some value for its users. Get the feedback cycle going to validate you build the right thing the right way. Then deliver something valuable again in a couple of weeks. Practising Agile principles is way more effective then testing requirements.

The Standish group says 64% of the features are rarely or never used. This does not mean it has bugs or was implemented wrong, just that it was not needed. Also 20% of the features deliver 80% of the value. Building less software is the best way to have less defects and go faster. Keeping complexity low and value high. Once you hit the high-end of the value curve, wonder if you still need to add more functionality. I think it is easier to get proof for increased complexity leading to more defects than lack of requirements testing.

I think the developers, testers and stakeholders should spend around 15-60 minutes on a particular feature face-to-face. Make it smaller and build the simplest thing that might work with Test-Driven Development. Maybe another 5 minutes to write the first test. Spending more time is just an waste. Validating real working software with real users is the only way to get the functionality right. This might sounds harsh, but people have no idea what they really need until the see what they got.

Sure this might not be valid in certain niche life-and-death software products, but probably works for 99% of all other products.

  1. Ensure the requirements address the objective or its purpose.
  2. Ensure negative scenarios or conflicting workflows of the requirements.
  3. Define scope of the requirements. What is covered and what is out of reach and why.
  4. Define performance parameters, unit test requirements, pre and post conditions of the environment.
  5. Define additional or supported libraries required. Identify their advantages, risks/dependencies and alternatives.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.