Requirements volatility and defect density

Malaiya, Yashwant K.; Denton, J.

doi:10.1109/issre.1999.809334

Cited by 44 publications

(46 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…These changes in requirements come about for reasons such as changing customer needs over the lifecycle of a project, and increased understanding of the domain by the development team (Nurmuliani, Zowghi, & Powell, 2004). It has been found that increased volatility of requirements lead to an increased amount of defects introduced into the software, especially when requirements are changed closer to the release date (Javed, Maqsood, & Durrani, 2004;Malaiya & Denton, 1999). The changes in requirements result in changes made to code for which its extended use is not fully understood.…”

Section: Introductionmentioning

confidence: 99%

Why do software developers practice test-driven development?

Kayongo

Chigona

Mabhena

2016

2016 International Conference on Advances in Computing and Communication Engineering (ICACCE)

View full text Add to dashboard Cite

This dissertation describes research that has been undertaken to understand factors influencing software developers' intention to perform test driven development (TDD). Unit tests are a form of testing, where tests are written for small units of software being developed. TDD is a practice where these tests are written before the functionality is written, so as to guide the design of the code for the functionality, as well as to ensure test coverage for all functionality. There has been some research conducted to understand TDD by looking at its effects on both the outcomes and the practice of software development. It has been found to increase quality by decreasing defects, while also increasing the maintainability and the changeability of the code. On the other hand, some research has also found it to increase time spent on completing tasks. Despite this, to the best of the researcher's knowledge, there hasn't been research done to understand the behavioural components of TDD, and in particular, why developers choose to practice TDD.A conceptual model based on the Theory of Planned Behaviour (TPB) is described and used as a lens to understand intention. TPB proposes that intention to perform a behaviour (TDD in this case) is influenced by three factors: attitude towards the behaviour, subjective norm, and perceived behavioural control. This dissertation seeks to build onto this model for the purpose of understanding TDD, and proposes the following determinants of the influences of intention: attitude is influenced by attitude towards time taken, differences in quality, maintainability and developer efficiency; subjective norm is influenced by the perceived perception of the environment regarding changes in quality, time taken, and maintainability of the code. Lastly, perceived behavioural control is posited to be made up of perceived difficulty of TDD, and how much experience a developer has.This model is then tested based on data collected from an online survey distributed around the world. 779 responses were collected from developers in various countries around the world. The majority of the respondents to practice TDD, allowing us to gain greater insight into why those that practice TDD actually do so. Because the study is a psychographic study, perceptions were understood from the developers using an ordinal Likert scale. To analyse this data in order to prove the hypotheses, Chi--square tests with contingency tables, Kruskal--Wallis tests and ordinal logistic regression were used as statistical methods. It is found the data collected does not conform to the model, and recommendations are made for a future study to form a more comprehensive model. III PLAGIARISM DECLARATION

show abstract

Section: Introductionmentioning

confidence: 99%

Why do software developers practice test-driven development?

Kayongo

Chigona

Mabhena

2016

2016 International Conference on Advances in Computing and Communication Engineering (ICACCE)

View full text Add to dashboard Cite

show abstract

“…Requirements volatility can also present risks to a project [6], [7]. There are many causes of requirements volatility.…”

mentioning

confidence: 99%

Toward the Decision Tree for Inferring Requirements Maturation Types

Nakatani

Kondo

Shirogane

et al. 2012

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

SUMMARYRequirements are elicited step by step during the requirements engineering (RE) process. However, some types of requirements are elicited completely after the scheduled requirements elicitation process is finished. Such a situation is regarded as problematic situation. In our study, the difficulties of eliciting various kinds of requirements is observed by components. We refer to the components as observation targets (OTs) and introduce the word "Requirements maturation." It means when and how requirements are elicited completely in the project. The requirements maturation is discussed on physical and logical OTs. OTs Viewed from a logical viewpoint are called logical OTs, e.g. quality requirements. The requirements of physical OTs, e.g., modules, components, subsystems, etc., includes functional and non-functional requirements. They are influenced by their requesters' environmental changes, as well as developers' technical changes. In order to infer the requirements maturation period of each OT, we need to know how much these factors influence the OTs' requirements maturation. According to the observation of actual past projects, we defined the PRINCE (Pre Requirements Intelligence Net Consideration and Evaluation) model. It aims to guide developers in their observation of the requirements maturation of OTs. We quantitatively analyzed the actual cases with their requirements elicitation process and extracted essential factors that influence the requirements maturation. The results of interviews of project managers are analyzed by WEKA, a data mining system, from which the decision tree was derived. This paper introduces the PRINCE model and the category of logical OTs to be observed. The decision tree that helps developers infer the maturation type of an OT is also described. We evaluate the tree through real projects and discuss its ability to infer the requirements maturation types.

show abstract

“…If a requirement has changed more than ten times, the volatility values for all requirements are quantified on a 10-point scale. Requirements volatility is an assessment of the requirements change once the implementation begins [17].…”

Section: Prioritization Factorsmentioning

confidence: 99%

“…The biggest cause for project failures happens to be lack of user input, and changing or incomplete requirements [15,18,22]. Roughly 25% of the requirements for an average project change before project completion [22], and volatile requirements tend to make the testing activities difficult and cause the software to contain high defect density [17]. Changing requirements result in re-design, the addition or deletion of existing functions, and often an increase in the fault density in the program [17].…”

Section: Prioritization Factorsmentioning

confidence: 99%

“…Roughly 25% of the requirements for an average project change before project completion [22], and volatile requirements tend to make the testing activities difficult and cause the software to contain high defect density [17]. Changing requirements result in re-design, the addition or deletion of existing functions, and often an increase in the fault density in the program [17]. Severe defects that escape into the field can cost 100 times more to fix after delivery than correcting the problem in the requirements phase [26].…”

Section: Prioritization Factorsmentioning

confidence: 99%

See 1 more Smart Citation