According to the Standish Group's Chaos Report, 90% of IT projects are delivered late and 66% of them are not considered successful. Surveys show that more than 50% of the project failures can be attributed to problems stemming from Requirements Elicitation and Management and more than 20% are due to Ineffective Testing.

This situation can be best explained with a simple analogy from nature. The software development lifecycle is like a river with requirements at its source. If you can't clean the river at its source, you will have a dirty river flowing down the hill. A reactive rather than a proactive approach to clean the river will increase the costs and risks exponentially. The proactive way to overcome this situation is by integrating Requirements and Test Management activities and formulating a Requirements Driven Test Management Process. To build a RDTM Process the following critical success factors should be in place:

• Early Testing. The testing activities should start in parallel to requirements definition without waiting for coding. Finding and fixing the requirement defects will lead to early prevention of flaws in design and coding process. Applying Early Testing as a principle will also have a positive quality assurance impact on business analysis activities.
• Use Case vs. Test Cases. In most of the projects, use cases are used as test cases. But these test cases only contain positive cases lacking forced error (negative) test scenarios which help in identifying most of the defects. In good practice approaches test cases should be prepared as a combination of use case scenarios and negative scenarios. Negative test cases are best developed by using test design techniques like equivalence partitioning, decision tables, boundary value analysis etc.
• Independent Test Teams. Positioning testing as a nice to have rather than a must have, last minute, additional task for developers or BAs resulted in incomplete and ineffective testing of applications. In order to avoid this problem, independent test teams with test automation capabilities should be established in organizations. Nowadays, CIOs are investing in Centers of Excellence for Requirements Engineering and Test Engineering teams as separate disciplines.
• Requirements Traceability and Test Coverage. The traceability matrix is a helpful tool to ensure that requirements have been met and all changes are addressed. By using traceability matrices, requirements can be referenced beside relevant test cases and test coverage ratio can be monitored at each stage of the project. Requirements coverage should be also used as a Key Performance Indicator for test teams and should be evaluated as test exit criteria.
• Requirements vs. Test Automation Tools. Requirements Driven Test Management necessitates the integration of requirement management and test automation tools. In the selection of test automation tools, the requirements coverage monitoring abilities should be a selection criteria, in addition to standard test case and bug tracking functionalities.

Beyond all the critical success factors discussed above, most companies require a paradigm shift in their culture to put requirements driven test management into reality.

-Don't forget to leave your comments below

Emrah Yayici is the Managing Partner of Ba-Works Business Analysis Services. He is the president of IIBA Turkey Istanbul Chapter. He has worked as a consultant for Arthur Andersen and Accenture on various international technology and management consulting projects. He studied Industrial Engineering and Economics in Middle East Technical University. He has published many articles and participated as a speaker at various conferences on business analysis and software testing. He is a strong supporter of business analysis and software testing professions and supports this vision with active roles in global and local non profit organizations.

Comments (3)

Subscribe to this comment's feed

...
written by Laxman Bista, January 27, 2010

good article.

• 
• +0
• 
• 

...
written by Rizwan Khurshid, January 31, 2010

I really like the example you have given here and is very much true that if requirements are incomplete or inaccurate mostly likely your IT project will fail and/or will not fulfill the needs your customer was expecting.

But I am suite concern that will people agree to implement the process of "Testing the requirements" and who will be the ideal candidate for doing this either stake holder or peer review? Given that every one is now trying to adopt agile methodologies and trying to cut the time spent on documentation and/or modeling.

• 
• +1
• 
• 

...
written by John Talbot, February 02, 2010

Thanks Emrah, I am a fan of Early testing, however it is described or done.

I have found on a number of projects that the sooner one starts to produce test scenarios, whether from use cases or a statement of requirements, the sooner defects are found. At this stage they will be ambiguities in requirements or outright missing requirements. Within an agile context, the users would contribute to the test scenario construction and a defect found there would, if well managed, feed in to the backlog for an (objective) assessment of the defect.

• 
• +1
• 
•