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.
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.
It’s better to catch the requirement ambiguities and fix them in the early development life cycle itself.
Testers should:
Requirements should be:
The requirements specification doc should address:
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.
