This is a bug. No, this is a requirement.

This is a defect. No, this is a change request.

This is a true incident. Our client was a large bank in one of the Middle Eastern countries. They had entrusted a large IT services organization to develop their banking system.  Bank’s business analysts had taken 3 months to prepare comprehensive requirements documents running into few hundred pages. The vendor delivered the system after 10 months of off-shore development.

Once the banks end users started testing the product, in just about 2 weeks’ time, they discovered 600+ bugs and the count was increasing with each day of testing.

On enquiring with the vendor organization, the vendor organization said these are NOT bugs but change requests. They said the requirements were not stated explicitly, hence these are not defects.

It was for sure that the product quality was not at all acceptable and the project team may need another 6 month’s extra time to fix all these issues.

Why did this happen?

This happened because the defect has indeed different understanding for different stakeholders.

For users, if something did not behave as they expected it to behave, then that’s a defect.

For supplier, something can be a defect only if it was specified explicitly and not fulfilled.

Unfortunately, there can a large gap between what stakeholders really expect and what business analysts specify in the specifications document.

Can there be techniques which can help us to minimize these gaps?

Of course there are. But that’s for my next blog folks.

Do keep an eye for my next blog.

 About me

I am a professional BA, trainer, coach and author.

If you like my posts please like/share/comment and spread the word in your network.

Would love to connect with fellow professionals.

You can also reach me at LN@AdaptiveUS.com

About my organization, Adaptive US

Adaptive US provides training, study guides, question banks, necessary PDUs for ECBA, CCBA, CBAP certifications.