2015 REEN.pdf (882.71 kB)

Repetition between stakeholder (user) and system requirements

Download (882.71 kB)
journal contribution
posted on 05.11.2015, 14:40 by Richard Ellis-Braithwaite, Russell Lock, Ray Dawson, Tim King
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.

History

School

  • Science

Department

  • Computer Science

Published in

Requirements Engineering

Citation

ELLIS-BRAITHWAITE, R. ... et al, 2017. Repetition between stakeholder (user) and system requirements. Requirements Engineering, 22(2) pp.167-190.

Publisher

© Springer Verlag

Version

AM (Accepted Manuscript)

Publisher statement

This work is made available according to the conditions of the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0) licence. Full details of this licence are available at: https://creativecommons.org/licenses/by-nc-nd/4.0/

Publication date

2017

Notes

The final publication is available at Springer via http://dx.doi.org/10.1007/s00766-015-0239-x

ISSN

1432-010X

Language

en

Exports