Loughborough University
Leicestershire, UK
LE11 3TU
+44 (0)1509 263171
Loughborough University

Loughborough University Institutional Repository

Please use this identifier to cite or link to this item: https://dspace.lboro.ac.uk/2134/19303

Title: Repetition between stakeholder (user) and system requirements
Authors: Ellis-Braithwaite, Richard
Lock, Russell
Dawson, Ray
King, Tim
Keywords: User requirements
Stakeholder requirements
System requirements
Duplicate detection
Issue Date: 2015
Publisher: © Springer Verlag
Citation: ELLIS-BRAITHWAITE, R. ... et al, 2015. Repetition between stakeholder (user) and system requirements. Requirements Engineering, DOI: 10.1007/s00766-015-0239-x
Abstract: Stakeholder requirements (also known as user requirements) are defined at an early stage of a software project to describe the problem(s) to be solved. At a later stage, abstract solutions to those problems are prescribed in system requirements. The quality of these requirements has long been linked to the quality of the software system and its development or procurement process. However, little is known about the quality defect of redundancy between these two sets of requirements. Previous literature is anecdotal rather than exploratory, and so this paper empirically investigates its occurrence and consequences with a case study from a UK defense contractor. We report on a survey of sixteen consultants to understand their perception of the problem, and on an analysis of real-world software requirements documents using natural language processing techniques. We found that three quarters of the consultants had seen repetition in at least half of their projects. Additionally, we found that on average, a third of the requirement pairs’ (comprised of a system and its related stakeholder requirement) description fields were repeated such that one requirement in the pair added only trivial information. That is, solutions were described twice while their respective problems were not described, which ultimately lead to suboptimal decisions later in the development process, as well as reduced motivation to read the requirements set. Furthermore, the requirement fields considered to be secondary to the primary “description” field, such as the “rationale” or “fit criterion” fields, had considerably more repetition within UR–SysR pairs. Finally, given that the UR–SysR repetition phenomena received most of its discussion in the literature over a decade ago, it is interesting that the survey participants did not consider its occurrence to have declined since then. We provide recommendations on preventing the defect, and describe the freely available tool developed to automatically detect its occurrence and alleviate its consequences.
Description: The final publication is available at Springer via http://dx.doi.org/10.1007/s00766-015-0239-x
Version: Accepted for publication
DOI: 10.1007/s00766-015-0239-x
URI: https://dspace.lboro.ac.uk/2134/19303
Publisher Link: http://dx.doi.org/10.1007/s00766-015-0239-x
ISSN: 1432-010X
Appears in Collections:Published Articles (Computer Science)

Files associated with this item:

File Description SizeFormat
2015 REEN.pdfAccepted version882.71 kBAdobe PDFView/Open


SFX Query

Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.