Reasons to Involve Testing Team In Project During Requirements Gathering Phase

No votes yet.
Please wait...

In order to accelerate the software production process, the development and all types of test activities should be closely integrated. This integration process should begin in early stages of the development process, while formulating requirements for the software product together with the users. To design a software system, a development team needs to have a clear set of requirements, while a debugging team also needs to be provided with clearly formulated, unambiguous requirements based on which the participants will be able to create a test plan and test project. If both teams enter into cooperation in the early stages of the development process, then it is likely that they will be able to formulate the necessary requirements already at the early stages of the project. Software testing services companies are involved in improving quality of manufactured digital products by verifying their parameters at each phase of the life cycle.

Another reason to attract a team of testing specialists to come to work on the project during requirements gathering phase is dictated by the need to carry out a static analysis of these requirements. The Standish Group’s report on a survey of more than 350 companies published in 1994 says that only 9% of over 8,000 software projects were completed on time and met the budget. Thirty-one percent of all projects were canceled without being completed. Subsequent studies were conducted to identify the causes of unsuccessful projects. An examination of the main factors that caused costoverrun in product development or project failure in general showed that in more than 50% of cases these factors are related to software requirements development process. The main factors that are relevant to requirements formulation process are listed below, including the same percentage of projects, for which the corresponding problem is the factor that caused the failure of the project:

– Incompleteness of requirements (13.1%)
– Non-participation of the user in the development of requirements (12.4%)
– Unrealistic expectations (9.9%)
– Change in requirements and specifications (8.7%)
– The need for a system has disappeared (7.5%).

One of the results of this report is the conclusion that a large number of defects can be introduced into the product already at the requirements formulation stage.

Comments are closed.