Understanding changes in use cases: A case study

Basirati, Mohammad R.; Femmer, Henning; Eder, Sebastian; Fritzsche, Martin; Widera, Alexander

doi:10.1109/re.2015.7320452

Cited by 11 publications

(8 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…• Review protocols that indicate the effort that was invested during QA of the RE artifacts (as we, for example, did in an earlier paper [13]) • Incorrect test cases or incorrect test results that show that the test case engineer misunderstood the RE artifacts • Requirements change requests, or defects in bug tracking systems that can be traced back to RE artifacts, to understand defects in the RE artifact that are discovered during development or further activities • Concrete changes that have been performed on the RE artifacts to understand maintenance efforts (as for example performed by Basirati et al [14]) 3) Create a taxonomy of impacts that provides a list of well-examined effects of quality factors on activities.…”

Section: B What Is Left For Research?mentioning

confidence: 99%

See 1 more Smart Citation

Requirements Quality Is Quality in Use

Femmer¹,

Vogelsang

2019

IEEE Softw.

Self Cite

View full text Add to dashboard Cite

The quality of requirements engineering artifacts is widely considered a success factor for software projects. Currently, the definition of high-quality or good RE artifacts is often provided through normative references, such as quality standards, textbooks, or generic guidelines. We see various problems of such normative references: (1) It is hard to ensure that the contained rules are complete, (2) the contained rules are not context-dependent, and (3) the standards lack precise reasoning why certain criteria are considered bad quality. To change this understanding, we postulate that creating an RE artifact is rarely an end in itself, but just a means to understand and reach the project's goals. Following this line of thought, the purpose of an RE artifact is to support the stakeholders in whatever activities they are performing in the project. This purpose must define high-quality RE artifacts. To express this view, we contribute an activity-based RE quality meta model and show applications of this paradigm. Lastly, we describe the impacts of this view onto research and practice.

show abstract

Section: B What Is Left For Research?mentioning

confidence: 99%

“…To evaluate impacts, one may use interviews [15], case studies [14], or experiments [12]. Practitioners will benefit from this community effort only if the necessary effort for tailoring the reference model and taxonomies is reasonable.…”

Section: B What Is Left For Research?mentioning

confidence: 99%

Requirements Quality Is Quality in Use

Femmer¹,

Vogelsang

2019

IEEE Softw.

Self Cite

View full text Add to dashboard Cite

show abstract

“…One such mechanism is the use of requirement engineering artifacts, such as use cases. The research done by Basirati et al [46] establishes a taxonomy of common changes based on their observation of changing use cases that can then be used in other projects to predict and understand RCs. They also contribute to this research space by identifying which parts of use cases are prone to change as well as what changes would create difficulty in application, contributing also to the impact analysis of change.…”

Section: )mentioning

confidence: 99%

“…Limitations What our methods can address Basirati et al [46] and Ecklund [42] Can only be applied if use cases are available or used in the development process.…”

Section: Techniquementioning

confidence: 99%

Managing software requirements changes through change specification and classification

2018

View full text Add to dashboard Cite

Software requirements changes are often inevitable due to the changing nature of running a business and operating the Information Technology (IT) system which supports the business. As such, managing software requirements changes is an important part of software development. Past research has shown that failing to manage software requirements changes effectively is a main contributor to project failure. One of the difficulties in managing requirements changes is the lack of effective methods for communicating changes from the business to the IT professionals. In this paper, we present an approach to managing requirements change by improving the change communication and elicitation through a method of change specification and a method of classification. Change specification provides a way such that communication ambiguities can be avoided between business and IT staff. The change classification mechanism identifies the type of the changes to be made and preliminary identification of the actions to be taken. We illustrate the usefulness of the methods by applying them to a case study of course management system.

show abstract

“…"Understanding Changes in Use Cases: A Case Study," by Mohammad Basirati and his colleagues, argues that we need a deeper understanding of which changes in requirements artifacts, such as use cases, are problematic in terms of difficulty or risk. 3 Basirati and his colleagues manually inspected more than 400 changes in 32 use cases over 15 months in a software project at Munich Re, a reinsurance company. This research provided empirical evidence about specific maintenance risks and suggests the need to continuously analyze local and temporal dispersion.…”

Section: How Use Cases Changementioning

confidence: 99%