You are on page 1of 2

Benefits of early involvement of QA

Requirements engineering is the initial part of a software development process, and all later steps of the development are influenced by the requirements, making the quality of the requirements an important factor for the overall quality of the developed system. If there is a mistake in requirement gathering, then it will be carried out in the design, product and its architecture. An issue that originates in the requirements runs the risk of affecting not only other requirements but also later phases and can cause follow-up defects in architecture, design, coding and testing. If the quality assurance is only performed in the test and maintenance phase, one is dependent on the ability of the requirements engineers, designers and programmers to produce good working products, suitable for the rest of the development. If QA is not done for the intermediate work products, it is most likely that the design and implementation are based on the wrong requirements. This, in consequence, leads to high rework effort as not only the code but most often the overall system architecture and design have to be revised due to requirements defects. Late QA leads to a stressful and costly test and maintenance phases. Issues should be resolved in the phase of their origin to avoid costly testing and rework. Testing and rework can account for up to 40-50 % of the development effort. In addition, removing defects early in the development process is more cost effective than addressing the defects during testing or maintenance. Correcting a defect late in the process gets more expensive as development effort has already been spent and more artifacts are affected. A requirements issue can become up to 100 times more expensive if it is detected in operation, compared to detecting it in the requirements phase. If we want to avoid the the mentioned critical situations and senarios then we need to involve QA into the requirement engineering process. The requirements deficiencies are the prime source of project failures, and that over 40% of problems in the software development cycle result from low quality requirements, QA techniques for requirements are one of the most promising and cost effective techniques to ensure successful development and to prevent avoidable rework in later phases. Independently of whether high quality is required or not, QA in the requirements phase pays of. But it does, of course, become even more important if high quality is a key success factor.

How can QA contribute to Requirement Engineering?

In Requirement Engineering process Quality Assurance can play a vital role. Some contributions that QA can provide in Requirement Engineering are: 1) The contributions QA can make in the requirements phase are style guidelines on how to specify requirements, templates for the requirements specification, elicitation approaches and prototyping. 2) QA can contribute by preventing requirements issues from being introduced (i.e. during elicitation) by the omissions and ambiguous requirements are addressed. 3) QA can take contribute in preparing interviews, in preparing questionnaires and in formal reviews of different Requirement Engineering activities. 4) QA can contribute in reviewing of various Requirement document produced during the Requirement activities and validate them according to documentation rules and Requirement Engineering best practices. 5) QA can contribute by evaluating the attributes of requirements like Completeness, Correctness, Traceability, Feasibility, Consistency and ambiguity. 6) QA can contribute in developing the clear and measurable requirement to ne documented in the SRS document which can be tested in a quantifiable manner.