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.