The change and evolution of requirements as a challenge to the practice of software engineering

Harker, Susan; Eason, Ken; Dobson, John

doi:10.1109/isre.1993.324847

Cited by 100 publications

(105 citation statements)

References 6 publications

Supporting

Mentioning

101

Contrasting

Unclassified

Order By: Relevance

“…For instance, requirements changes are categorized as high effort, medium effort, low effort and no effort changes based on the magnitude of effort involved criterion by the practitioners. Harker et al [40] describe a classification of changing requirements where each changing requirement type could be reformulated as a change type. Lam et al [53] propose a change maturity model that reflects an organization's capability at managing change.…”

Section: Change Classificationmentioning

confidence: 99%

Change impact analysis for requirements: A metamodeling approach

Göknil

Kurtev²,

Berg

et al. 2014

Information and Software Technology

View full text Add to dashboard Cite

a b s t r a c tContext: Following the evolution of the business needs, the requirements of software systems change continuously and new requirements emerge frequently. Requirements documents are often textual artifacts with structure not explicitly given. When a change in a requirements document is introduced, the requirements engineer may have to manually analyze all the requirements for a single change. This may result in neglecting the actual impact of a change. Consequently, the cost of implementing a change may become several times higher than expected. Objective: In this paper, we aim at improving change impact analysis in requirements by using formal semantics of requirements relations and requirements change types. Method: In our previous work we present a requirements metamodel with commonly used requirements relation types and their semantics formalized in first-order logic. In this paper the classification of requirements changes based on structure of a textual requirement is provided with formal semantics. The formalization of requirements relations and changes is used for propagating proposed changes and consistency checking of proposed changes in requirements models. The tool support for change impact analysis in requirements models is an extension of our Tool for Requirements Inferencing and Consistency Checking (TRIC). Results: The described approach for change impact analysis helps in the elimination of some false positive impacts in change propagation, and enables consistency checking of changes. Conclusion: We illustrate our approach in an example which shows that the formal semantics of requirements relations and change classification enables change alternatives to be proposed semi-automatically, the reduction of some false positive impacts and contradicting changes in requirements to be determined.

show abstract

Section: Change Classificationmentioning

confidence: 99%

Change impact analysis for requirements: A metamodeling approach

Göknil

Kurtev²,

Berg

et al. 2014

Information and Software Technology

View full text Add to dashboard Cite

show abstract

“…A categorisation of change types thus focused is presented by Harker [18] who divides empirically gathered requirements changes occurring during software development into five categories depending upon the source of the change-fluctuations in the organisation and product market environment, increased understanding of requirements, consequences of system usage, and changes necessary due to customer migratory or adaptation issues. Based on Harker's study, an appraisal by Sommerville [19] includes compatibility requirements relating to business process change in place of migratory and adaptation issues.…”

Section: Requirements Change Classificationmentioning

confidence: 99%

“…The derivation of the taxonomy, which is the focus for the case studies presented in this paper, used the expert knowledge of experienced project managers to consolidate and classify 73 change source constructs elicited from the cause-focused classifications described above [18,19,21] in addition to other empirical studies including [2,9]. Using individual card sorting and workshops, a classification of change sources was derived comprising the five change domains illustrated in Table 1.…”

Section: Requirements Change Classificationmentioning

confidence: 99%

Towards an understanding of the causes and effects of software requirements change: two case studies

McGee

Greer

2012

Requirements Eng

View full text Add to dashboard Cite

Changes to software requirements not only pose a risk to the successful delivery of software applications but also provide opportunity for improved usability and value. Increased understanding of the causes and consequences of change can support requirements management and also make progress towards the goal of change anticipation. This paper presents the results of two case studies that address objectives arising from that ultimate goal. The first case study evaluated the potential of a change source taxonomy containing the elements 'market', 'organisation', 'vision', 'specification', and 'solution' to provide a meaningful basis for change classification and measurement. The second case study investigated whether the requirements attributes of novelty, complexity, and dependency correlated with requirements volatility. While insufficiency of data in the first case study precluded an investigation of changes arising due to the change source of 'market', for the remainder of the change sources, results indicate a significant difference in cost, value to the customer and management considerations. Findings show that higher cost and value changes arose more often from 'organisation' and 'vision' sources; these changes also generally involved the co-operation of more stakeholder groups and were considered to be less controllable than changes arising from the 'specification' or 'solution' sources. Results from the second case study indicate that only 'requirements dependency' is consistently correlated with volatility and that changes coming from each change source affect different groups of requirements. We conclude that the taxonomy can provide a meaningful means of change classification, but that a single requirement attribute is insufficient for change prediction. A theoretical causal account of requirements change is drawn from the implications of the combined results of the two case studies.

show abstract

“…In any case, the degree of requirements change will significantly affect the success of the project. The gross number of requirement changes made to the project's requirements and severity of these changes are examples of dependent variables used at the project level [41][42][43][44]. (4) Mismanagement.…”

Section: Related Researchmentioning

confidence: 99%

Requirements engineering: In search of the dependent variables

Gorschek

Davis

2008

Information and Software Technology

View full text Add to dashboard Cite

When software development teams modify their requirements engineering process as an independent variable, they often examine the implications of these process changes by assessing the quality of the products of the requirements engineering process, e.g., a software requirements specification (SRS). Using the quality of the SRS as the dependent variable is flawed. As an alternative, this paper presents a framework of dependent variables that serves as a full range for requirements engineering quality assessment. In this framework, the quality of the SRS itself is just the first level. Other higher, and more significant levels, include whether the project was successful and whether the resulting product was successful. And still higher levels include whether or not the company was successful and whether there was a positive or negative impact on society as a whole.

show abstract

The change and evolution of requirements as a challenge to the practice of software engineering

Cited by 100 publications

References 6 publications

Change impact analysis for requirements: A metamodeling approach

Change impact analysis for requirements: A metamodeling approach

Towards an understanding of the causes and effects of software requirements change: two case studies

Requirements engineering: In search of the dependent variables

Contact Info

Product

Resources

About