Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
Repetition between stakeholder (user) and system requirements
Ellis-Braithwaite R., Lock R., Dawson R., King T. Requirements Engineering22 (2):167-190,2017.Type:Article
Date Reviewed: Aug 10 2017

While stakeholder or user requirements (URs) should have corresponding system requirements (SysR), the purpose of these requirements is fundamentally different. URs are focused more on defining the problem, while SysR define the solution to the problem. Repetition or even duplication of requirements between these two categories can indicate a lack of problem definition, and a predisposition to a solution that may not be ideal or even address primary stakeholder concerns. However, the phenomenon of URs and SysR repetition has not received much attention in the literature in recent years. This is surprising given that, as the paper demonstrates, redundancy between user and system requirements has not declined over that period.

Given the relative lack of attention to the problem of requirements repetition, the paper spends some time defining terms and mapping out the relationship between URs and SysRs, and the inherent problems in omitting one or the other. Ultimately, this results in the definition of a set of research questions around the prevalence of repetition, the reasons for it, and its impact. The authors employed a case study research methodology to address these questions, utilizing two methods. First, the authors distributed a questionnaire to experienced requirements engineering consultants in the defense industry, gauging their experiences with requirements repetition over their professional careers. Then, they used a software tool they developed to analyze UR-SysR requirements document pairs from two different software projects to provide a more robust foundation for answering their research questions. The bulk of the paper is spent answering the research questions using conclusions drawn from this questionnaire and automated analysis. This discussion has value beyond the problem at hand, illuminating the reasons behind requirements repetition and identifying new avenues for future exploration.

This paper will be of primary interest to software and requirements engineers in domains with robust requirements engineering standards like defense, and academic researchers. The authors take the time to apply their conclusions beyond the defense industry, to general requirements practice using other methodologies such as agile practices, which should prove valuable to anyone interested in the state of the art in requirements engineering.

Reviewer:  Nathan Carlson Review #: CR145473 (1710-0664)
Bookmark and Share
 
Requirements/ Specifications (D.2.1 )
 
Would you recommend this review?
yes
no
Other reviews under "Requirements/Specifications": Date

Moriconi M. (ed), Lansky A.Type: Article
Dec 1 1985
A unifying framework for structured analysis and design models
Tse T., Cambridge University Press, New York, NY, 1991. Type: Book (9780521391962)
Jun 1 1992
A skeleton interpreter for specialized languages
Steensgaard-Madsen J.  Programming Languages and System Design (, Dresden, East Germany,1861983. Type: Proceedings
Mar 1 1985
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy