Obsolete software requirements

Abstract

Context. Requirements changes are unavoidable in any software project. Requirements change over time as software projects progress, and involved stakeholders (mainly customers) and developers gain better understanding of the final product. Additionally, time and budget constraints prevent implementing all candidate requirements and force project management to select a subset of requirements that are prioritized more important than the others so as to be implemented. As a result, some requirements become cancelled and deleted during the elicitation and specification phase while other requirements are considered not important during the prioritization phase. A common scenario in this situation is to leave the excluded requirements for being considered in the next release. The constant leaving of the excluded requirements for the next release may simply render them obsolete. Objectives. In this master thesis, a preliminary investigation is conducted to study the phenomenon of obsolete software requirements (OSRs). The major objectives of the thesis are:1. To find if OSRs exist in reality and how serious they are. 2. To define an OSR. 3. To propose processes to discover OSRs and to take possible actions against them when they are discovered. 4. To examine the effects of OSRs on project's type and size. 5. To insert/inject OSRs into the requirements engineering life-cycle. 6. To develop a classification for requirements that can help finding OSRs. 7. To find empirical evidence regarding OSRs in the industry about all the above mentioned objectives. Methods. A systematic literature review (SLR) is conducted to find relevant information about OSRs. The articles were retrieved from a number of sources including Compendex, Inspec, IEEE Xplore, and ACM Digital Library. Besides, a web-based questionnaire was distributed to experts from both of the industry and the academia in order to collect empirical information about OSRs. The data retrieved from the questionnaire was analyzed mainly using descriptive analysis and chi-square test of significance.Results. The phenomenon of OSRs exists in reality and is deemed serious by the questionnaire respondents. Moreover, the thesis suggests a definition for OSRs based on the results of the questionnaire. Another contribution is proposing several processes to find OSRs in the requirements' documents, as well as suggesting possible actions to be taken against them. Additionally, OSRs are found to have negative effects on software projects. These effects vary depending on the project's type and size. Conclusions. In conclusion, the phenomenon of OSRs does exist in reality, and is considered serious by the majority of the questionnaire respondents. The respondents also believe that OSRs have negative effects on software projects depending on the size of the projects (measured in number of requirements) and the type of the project (outsourced, market-driven, and bespoke projects). In addition to, this thesis presents the definition of OSRs based on the experience of the author a...

Regression testing for large-scale embedded software development – Exploring the state of practice

“…Surprisingly, our respondent pointed good verification tools as a necessary improvement despite developing in-house and heavily tailored solutions themselves. Another interesting aspect is the identification of irrelevant or obsolete test cases that appears to be a similar challenge that the identification of obsolete software requirements surveyed by Wnuk et al where over 80% of the respondents confirmed negative influence of obsolescence on their processes [32].…”

BAM - Backlog Assessment Method

“…Often the backlog items vary greatly, and there are seldom any formal checkpoints for ensuring conformity or quality. In addition, obsolete backlog items are common to be found in backlogs in industry [17], meaning that information in form of obsolete requirements is visible in backlogs to a large extent in practice [17]. The obsolete backlog items may lead to, e.g.…”

Assessing refactorings for usability in e-commerce applications

“…There are other authors such as Moody et al or Jönsson and Wohlin that have applied arithmetical operation to data extracted from a Likert questionnaire (Moody et al 2003;Jönsson and Wohlin 2004). Other authors such as Bruun et al or Wnuk et al use also the average to aggregate items of a Likertscale (Bruun et al 2014;Wnuk et al 2013). Therefore, the possible values for satisfaction in use in our experiment are numbers between 1 and 5.…”