The Standish Group’s 2009 CHAOS Summary report stated that only 32% of IT projects were successful; 44% were challenged and 24% failed outright (project success was defined as on-time and on budget while meeting all functional needs). It appears that project failure is a sad fact of life in IT.
Further research indicates that requirements are the source of 56 percent of all defects identified in projects1. Of these, about half are down to poorly written, ambiguous, unclear and incorrect requirements. The other half are due to requirements that never made it into the specification at all. Project failure it appears has less to do with the traditional quality processes that the QA and development teams have employed and more to do with the requirements processes used by the organization.
If requirements are the source of the problem, you could argue that this is hardly a QA problem. But the results of a Micro Focus survey of attendees during a requirements-based testing webinar tell a very different story.