Article Preview
TopIntroduction
Requirements engineering is the first and crucial phase of software development and all the subsequent phases are influenced by requirements (Denger & Olsson, 2005). It is a systematic approach to understand, formally describe, evaluate/validate and attain an agreement on the nature of the problem (Lamsweerde, 2000). Thus, making quality of requirements as one of the important factors for overall quality of the project (Alshazly, Elfatatry & Abougabal, 2014). To improve quality, requirements should be gathered, analysed, validated precisely and properly which really leads to determine the success of the project. Otherwise, the project ends up with poor requirements resulting in a crude design followed by wrong or unwanted focus in product development directly affecting the product and customers (Firesmith, 2007). Poorly specified, incorrect or missing requirements lead to defects in the system (Blackburn, Busser & Nauman, 2001). In fact, the most common types of defects in software development are requirement defects which are among the major sources of failure constituting 32.65% (Hamill & Katerina, 2009) and these defects have high severity problem which affect software maintainability (Chen & Huang, 2009). Durability of the project also comes into question when any software lifecycle stage cannot be backtracked to the root requirement fault. Hence, it becomes essential to work on requirement defects and its real causes at the early stage of software development.
In 1998, Card (Card, 1998) stated that if problems are classified or grouped, it becomes easy to identify the clusters in which errors are likely to be found. There are several classifications or taxonomies available for classifying requirements defects which help in creating more accurate and efficient defect prevention and detection techniques (Alshazly et al., 2014; Beizer, 1990; Chillarege et al., 1992; Grady, 1992; Margarido, Faria, Vidal & Vieira, 2011; Walia & Carver, 2009; Hayes, 2003). Historically, there has been lot of research on validating requirements using various techniques and some through defect taxonomies (Ackerman, Buchwald & Lewski,1989; Sommerville, 2004; Laitenberger, Atkinson, Schlich & Emam, 2000; Felderer & Beer, 2013, 2015). In practice, most defect taxonomies are used in the later stages of software development life cycle but the use of these taxonomies to validate requirements have not been fully exploited (Felderer & Beer, 2013, 2015) and only little has been done in the direction of linking and validating the requirements with defect taxonomy. Here, the focus is on relating the requirements which are categorized with the defect taxonomy and finding the risk associated with the core requirements.