Change analysis: a step towards meeting the challenge of changing requirements

Strens, M. R.; Sugden, Robert

doi:10.1109/ecbs.1996.494539

Cited by 48 publications

(28 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A change request has many attributes apart from the requested change itself. Among the important attributes for a change request are type of change < add, delete and modify > (Strens and Sugden, 1996;McGee and Greer, 2009), the importance of change (O'Neal and Carver, 2001), the reasons and justification and the source of change (Nurmuliani et al, 2004;McGee and Greer, 2009). It may not be possible to collect and document all the attributes for a given change request but the more , pp.70-81, © 2012 the information available on these attributes, the easier it is to handle them.…”

Section: Rm In Softwarementioning

confidence: 99%

“…Conducting impact analysis helps answer many questions related to the impact of implementing this change. Among the important aspects are, when in development cycle the change needs to be implemented (Ramzan and Ikram, 2006;Imtiaz et al, 2008;Strens and Sugden, 1996), what artifacts are impacted by this change (Ramzan and Ikram, 2006;De Lucia et al, 2008;O'Neal and Carver, 2001;Imtiaz et al, 2008), the degree of change (De Lucia et al, 2008;O'Neal and Carver, 2001;Strens and Sugden, 1996) and who among the stakeholders are impacted by the change (Ramzan and Ikram, 2005;O'Neal and Carver, 2001). Figure 5 shows the impact of change affecting different phases and artifacts.…”

Section: Rm In Softwarementioning

confidence: 99%

“…There are various techniques employed for automation ranging from heuristics, information retrieval, data mining, domain knowledge and this is a hot area in research (Imtiaz et al, 2008). Moreover, the relationship between artifacts and entities can be direct, where an artifact or an entity is directly affected by the change, or indirect, where an artifact or an entity may be affected indirectly due to its relationship to other artifacts and entities that are affected directly by the proposed change (Strens and Sugden, 1996). This phenomenon is sometimes termed as "ripple effect", and the chain of this ripple effect may not be limited to only one level but to a number of levels with different degree of effect (Bohner, 2002, De Lucia et al, 2008, Ramzan and Ikram, 2005.…”

Section: Figure 5 Ripple Effect On Artifacts and Phases Due Tomentioning

confidence: 99%

See 2 more Smart Citations

Design Requirements in Software and Engineering Systems

Eleiche

Ahmad²,

Elish³

2012

Industrial Engineering and Management Systems

View full text Add to dashboard Cite

The subject of "Design Requirements" (DR) is central to the design of software and engineering systems. The main reason for this is that quality aspects are usually closely tied to requirements, among other things. In this review paper, we consider how the subject of requirements is being managed in these two seemingly different design disciplines. Two important aspects are covered, namely: (a) requirements development, describing various activities leading to requirements documentation, and (b) requirements change management, describing various activities needed for the proper treatment of the inevitable changes in requirements. Similarities and differences on how these two aspects are handled in software and engineering systems are highlighted. It is concluded from this literature survey that the management of software requirements is quite coherent and well established as a science. On the other hand, management of engineering systems requirements suffer from being unstructured, in particular when requirements changes are involved. Important gaps and future important research areas are identified.

show abstract

Section: Rm In Softwarementioning

confidence: 99%

Section: Rm In Softwarementioning

confidence: 99%

Section: Figure 5 Ripple Effect On Artifacts and Phases Due Tomentioning

confidence: 99%

See 1 more Smart Citation

Design Requirements in Software and Engineering Systems

Eleiche

Ahmad²,

Elish³

2012

Industrial Engineering and Management Systems

View full text Add to dashboard Cite

show abstract

“…Requirements changes can be classified according to their origins, which are related to development environments, stakeholders, development processes, understanding of requirements, and relations between requirements [22]. We do not reconstruct the requirements changes classification, but build analysis space of requirements elicitation with two factors: requirements accessibility, and requirements stability.…”

Section: Related Workmentioning

confidence: 99%

Estimation of the Maturation Type of Requirements from Their Accessibility and Stability

Nakatani

Hori

Katamine

et al. 2014

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

SUMMARYThe success of any project can be affected by requirements changes. Requirements elicitation is a series of activities of adding, deleting, and modifying requirements. We refer to the completion of requirements elicitation of a software component as requirements maturation. When the requirements of each component have reached the 100% maturation point, no requirement will come to the component. This does not mean that a requirements analyst (RA) will reject the addition of requirements, but simply, that the additional requirements will not come to the project. Our motivation is to provide measurements by which an RA can estimate one of the maturation periods: the early, middle, or late period of the project. We will proceed by introducing the requirements maturation efficiency (RME). The RME of the requirements represents how quickly the requirements of a component reach 100% maturation. Then, we will estimate the requirements maturation period for every component by applying the RME. We assume that the RME is derived from its accessibility from an RA to the requirements source and the stability of the requirements. We model accessibility as the number of information flows from the source of the requirements to the RA, and further, model stability with the requirements maturation index (RMI). According to the multiple regression analysis of a case, we are able to get an equation on RME derived from these two factors with a significant level of 5%. We evaluated the result by comparing it to another case, and then discuss the effectiveness of the measurements.

show abstract

“…Betterquality requirements can be developed when they are generated by ongoing client interaction, with a constantly improving prototype to reduce ambiguity [16,22,22]. Users must be carefully listened to and implicit assumptions must never be made [8], as they are not shared by stakeholders and thus may increase the uncertainty of the requirements [5,15].…”

Section: Requirements Engineeringmentioning

confidence: 99%