Specifying Changes Only --- A Case Study on Delta Requirements

Authors:
Andrea Herrmann;Armin Wallnöfer;Barbara Paech
Affiliations:
Fraunhofer IESE, Kaiserslautern, Germany 67663;ABB Corporate Research Center Germany, Ladenburg, Germany 68526;University of Heidelberg, Heidelberg, Germany 69120
Venue:
REFSQ '09 Proceedings of the 15th International Working Conference on Requirements Engineering: Foundation for Software Quality
Year:
2009

Citing 8
Cited 1

Extreme programming explained: embrace change

Extreme programming explained: embrace change
A Practical Guide to Feature-Driven Development

A Practical Guide to Feature-Driven Development
Requirements that Handle IKIWISI, COTS, and Rapid Change

Computer
Business-Driven Product Planning Using Feature Vectors and Increments

IEEE Software
The Art of Requirements Triage

Computer
Requirements Archaeology: From Unstructured Information to High Quality Specifications

RE '01 Proceedings of the Fifth IEEE International Symposium on Requirements Engineering
Feature-driven requirement dependency analysis and high-level software design

Requirements Engineering
The Incremental Funding Method: Data-Driven Software Development

IEEE Software

Requirements evolution drives software evolution

Proceedings of the 12th International Workshop on Principles of Software Evolution and the 7th annual ERCIM Workshop on Software Evolution

Quantified Score

Hi-index	0.02

Visualization

Abstract

[Context and motivation] Requirements engineering methods and examples presented in textbooks and scientific publications usually treat software which is developed - and therefore specified - from scratch. However, in the software development practice, this situation is very rare. In an industry case study, we encountered the situation that a software system in use had to be enhanced by a small delta. [Question/problem] Our objective was to specify these delta requirements without having to describe the complete system in detail. Therefore we explored how much of the existing system had to be specified in order to make the delta requirements understandable. [Principal ideas/results] We made an intensive literature search to proven practices. As we were not successful we applied the requirements engineering method TORE and extended it to capture the delta requirements. [Contribution] In this paper we describe a process for capturing delta requirements. To our knowledge, this is the first work about this practically relevant question. In our case study, hierarchical refinement of requirements top-down and iterative requirements prioritization successfully supported the specification of deltas, combined with a high-level specification of the existing system. We also present our experiences during the case study and propose ideas for further research.