Skip to main content
SpringerLink
Log in

Repetition between stakeholder (user) and system requirements

  • Original Article
  • Published:
Requirements Engineering Aims and scope Submit manuscript

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.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6

Similar content being viewed by others

References

  1. Marinelli V, Laplante PA (2008) Requirements engineering: the State of the practice revisited. Penn State University, University Park

    Google Scholar 

  2. Buede DM (2000) The engineering design of systems: models and methods. Wiley, New York

    Google Scholar 

  3. Juergens E, Deissenboeck F, Feilkas M et al (2010) Can clone detection support quality assessments of requirements specifications? In: Proceedings of the 32nd ACM/IEEE international conference on software engineering, vol 2, pp 79–88

  4. IEEE (1998) IEEE Std 830-1998: IEEE recommended practice for software requirements specifications. IEEE-SA Standards Board

  5. Hunt A, Thomas D (1999) The pragmatic programmer: from journeyman to master, 1st edn. Addison-Wesley Professional, Boston

    Google Scholar 

  6. Juergens E, Deissenboeck F, Hummel B, Wagner S (2009) Do code clones matter? In: 31st IEEE international conference on software engineering, pp 485–495

  7. Davies P (2004) Ten questions to ask before opening the requirement document. In: 14th Annual international symposium systems engineering: managing complexity and change

  8. Forsberg K, Mooz H (1995) The relationship of systems engineering to the project cycle. Eng Manag J 4:36–43

    Article  Google Scholar 

  9. Jureta IJ, Mylopoulos J, Faulkner S (2008) Revisiting the core ontology and problem in requirements engineering. In: 16th IEEE international requirements engineering conference, pp 71–80

  10. Lin D (1998) An information-theoretic definition of similarity. In: ICML, pp 296–304

  11. Hull E, Jackson K, Dick J (2011) Requirements engineering, 3rd edn. Springer, London

    Book  MATH  Google Scholar 

  12. Herzwurm G, Schockert S, Pietsch W (2003) QFD for customer-focused requirements engineering. In: 11th IEEE international requirements engineering conference, pp 330–338

  13. Clements P, Bass L (2010) Using business goals to inform a software architecture. In: 18th IEEE international requirements engineering conference, pp 69–78

  14. Kovitz BL (1998) Practical software requirements: a manual of content and style. Manning Publications, Greenwich

    Google Scholar 

  15. Alexander I (2002) Being clear: requirements are either needs or specifications. Newsl BCS Requir Eng Spec Group 25:10–12

    Google Scholar 

  16. Ellis-Braithwaite R (2014) GoalViz tool. In: GoalViz tool. http://www.goalviz.info/DUP/index.html. Accessed 5 Jun 2014

  17. Harwell R, Aslaksen E, Hooks I et al (1993) What is a requirement? In: 3rd Annual international symposium of NCOSE, pp 17–24

  18. Wieringa RJ (2005) Requirements researchers: are we really doing research? Requirements Eng 10:304–306. doi:10.1007/s00766-005-0013-6

    Article  Google Scholar 

  19. Davis AM (1993) Software requirements: objects. Prentice Hall, Functions and States

    MATH  Google Scholar 

  20. Stevens R, Brook P, Jackson K, Arnold S (1998) Systems engineering: coping with complexity. Pearson Education, New york

    Google Scholar 

  21. Sommerville I (2011) Software engineering, 9th edn. Pearson Education, Boston

    MATH  Google Scholar 

  22. IEEE (2011) ISO/IEC/IEEE 29148:2011 Systems and software engineering—life cycle processes—requirements engineering. In: IEEE-SA Standards Board

  23. Pyster A, Olwell D (2013) The guide to the systems engineering body of knowledge (SEBoK), v. 1.2. The Trustees of the Stevens Institute of Technology, Hoboken, NJ

  24. IIBA (2009) A guide to the business analysis body of knowledge (BABOK guide). International Institute of Business Analysis, Whitby, ON

  25. Van Lamsweerde A (2009) Requirements engineering: from system goals to UML models to software specifications. Wiley, New York

    Google Scholar 

  26. Alexander I (1999) Is there such a thing as a user requirement? Requirements Eng 4:221–223. doi:10.1007/s007660050022

    Article  Google Scholar 

  27. Jackson MA (1995) Software requirements and specifications: a lexicon of practice, principles, and prejudices. ACM Press, New York

    Google Scholar 

  28. Sage AP, Rouse WB (2009) Handbook of systems engineering and management, 2nd edn. Wiley, Hoboken

    Google Scholar 

  29. Boehm BW, Basili VR (2001) Software defect reduction top 10 list. Computer 34:135–137

    Article  Google Scholar 

  30. MoD (2012) ISO15288 Technical process: what is the relationship between requirements and design? “Engineering” acquisition operating framework (AOF). https://www.aof.mod.uk/aofcontent/tactical/engineering/content/tech_process/se_proc_req_design.htm. Accessed 11 Jul 2013

  31. MoD (2012) User requirements principles “Requirements and acceptance” acquisition operating framework (AOF). https://www.aof.mod.uk/aofcontent/tactical/randa/content/urprinciples.htm. Accessed 24 Sep 2012

  32. MoD (2012) System requirements document (SRD) principles “Requirements and acceptance” acquisition operating framework (AOF). https://www.aof.mod.uk/aofcontent/tactical/randa/content/srdprinciples.htm. Accessed 24 Sep 2012

  33. MoD (2012) User requirements (ur): recommended core attributes “Requirements and acceptance” acquisition operating framework (AOF). https://www.aof.mod.uk/aofcontent/tactical/randa/content/urdcoreattributes.htm. Accessed 15 Mar 2014

  34. MoD (2012) System requirements principles “Requirements and acceptance” acquisition operating framework (AOF). https://www.aof.mod.uk/aofcontent/tactical/randa/content/srprinciples.htm. Accessed 24 Sep 2012

  35. MoD (2012) System requirements document (SRD) “Requirements and acceptance” acquisition operating framework (AOF). https://www.aof.mod.uk/aofcontent/tactical/randa/content/srdstructure.htm. Accessed 15 Mar 2014

  36. Jackson MA (2000) Problem frames and methods: structuring and analyzing software development problems. Addison-Wesley, Harlow

    Google Scholar 

  37. Berry DM (2009) What, Not how?: the case of specifications of the New York Bagel. Ann Improbable Res 15:6–10

    Google Scholar 

  38. Zimmerman MJ (2010) Intrinsic vs. extrinsic value. In: Stanford encyclopedia of philosophy. http://plato.stanford.edu/entries/value-intrinsic-extrinsic. Accessed 2 Oct 2013

  39. Zave P, Jackson MA (1997) Four dark corners of requirements engineering. ACM Trans Softw Eng Methodol 6:1–30

    Article  Google Scholar 

  40. Kaindl H, Svetinovic D (2010) On confusion between requirements and their representations. Requirements Eng 15:307–311. doi:10.1007/s00766-009-0095-7

    Article  Google Scholar 

  41. Amyot D, Horkoff J, Gross D, Mussbacher G (2009) A lightweight GRL profile for i* modeling. Advances in conceptual modeling-challenging perspectives. Springer, Berlin, pp 254–264

    Chapter  Google Scholar 

  42. Dardenne A, van Lamsweerde A, Fickas S (1993) Goal-directed requirements acquisition. Sci Comput Program 20:3–50. doi:10.1016/0167-6423(93)90021-G

    Article  MATH  Google Scholar 

  43. Kavakli E (2002) Goal-oriented requirements engineering: a unifying framework. Requir Eng 6:237–251

    Article  MATH  Google Scholar 

  44. Aurum A, Wohlin C (2007) A value-based approach in requirements engineering: explaining some of the fundamental concepts. In: Sawyer P, Paech B, Heymans P (eds) Requirements engineering: foundation for software quality, pp 109–115

  45. Robertson S, Robertson J (2012) Mastering the requirements process, vol 3. Addison-Wesley Professional, Reading

    Google Scholar 

  46. Glinz M (2007) On non-functional requirements. In: 15th IEEE international requirements engineering conference

  47. Rost J (2006) Are “best practices” requirements documents a myth? IEEE Softw 23:103–104

    Article  Google Scholar 

  48. MoD (2012) System requirements document (SRD) part 3: System requirements “Requirements and acceptance” Acquisition operating framework (AOF). https://www.aof.mod.uk/aofcontent/tactical/randa/content/srdpart3.htm. Accessed 15 Jan 2014

  49. Ministry of Defence (2005) MODAF community of interest deskbook. MoD, UK

  50. Monperrus M, Baudry B, Champeau J et al (2011) Automated measurement of models of requirements. Software Qual J 21:3–22

    Article  Google Scholar 

  51. Asuncion HU, Francois F, Taylor RN (2007) An end-to-end industrial software traceability tool. In: 6th Joint meeting of the european software engineering conference and the ACM SIGSOFT symposium on the foundations of software engineering, pp 115–124

  52. Bouillon E, Mäder P, Philippow I (2013) A survey on usage scenarios for requirements traceability in practice. In: Proceedings of the 19th international conference on requirements engineering: foundation for software quality. Springer, Berlin, pp 158–173

  53. Boehm BW (2005) Value-based software engineering: overview and agenda. In: Biffl S et al (eds) Value-based software engineering. Springer, Berlin, Heidelberg

  54. Ncube C, Lockerbie J, Maiden N (2007) Automatically generating requirements from i* models: experiences with a complex airport operations system. In: 13th international working conference on requirements engineering: foundation for software quality. Springer, Berlin, pp 33–47

  55. Kanaris I, Kanaris K, Houvardas I, Stamatatos E (2007) Words versus character n-grams for anti-spam filtering. Int J Artif Intell Tools 16:1047–1067

    Article  Google Scholar 

  56. Manning CD, Schutze H (2001) Foundations of statistical natural language processing. MIT Press, Cambridge

    MATH  Google Scholar 

  57. Runeson P, Alexandersson M, Nyholm O (2007) Detection of duplicate defect reports using natural language processing. In: 29th International conference on software engineering. IEEE computer society, Washington, DC, USA, pp 499–510

  58. Rajaraman A, Ullman JD (2012) Data mining. Mining of massive datasets. Cambridge University Press, Cambridge

  59. Apache (2012) StopAnalyzer (Lucene 4.0.0 API). http://lucene.apache.org/core/4_0_0/analyzers-common/org/apache/lucene/analysis/core/StopAnalyzer.html. Accessed 24 Mar 2014

  60. Mavin A, Wilkinson P, Harwood A, Novak M (2009) Easy approach to requirements syntax (EARS). In: 17th IEEE international requirements engineering conference, pp 317–322

  61. Falessi D, Cantone G, Canfora G (2013) Empirical principles and an industrial case study in retrieving equivalent requirements via natural language processing techniques. IEEE Trans Softw Eng 39:18–44

    Article  Google Scholar 

  62. tfidf.com (2010) Tf-idf: a single-page tutorial—information retrieval and text mining. http://www.tfidf.com/. Accessed 16 Nov 2014

  63. Ellis-Braithwaite R (2013) Analysing the assumed benefits of software requirements. In: 19th International working conference on requirements engineering: foundation for software quality, proceedings of the workshops and the doctoral symposium, pp 207–214

  64. Runeson P, Höst M (2008) Guidelines for conducting and reporting case study research in software engineering. Empir Softw Eng 14:131–164. doi:10.1007/s10664-008-9102-8

    Article  Google Scholar 

  65. Flyvbjerg B (2006) Five misunderstandings about case-study research. Qual Inq 12:219–245. doi:10.1177/1077800405284363

    Article  Google Scholar 

  66. Berk RA, Freedman DA (2003) Statistical assumptions as empirical commitments. In: Blomberg TG, Cohen S (eds) Law, punishment, and social control: essays in honor of Sheldon Messinger, 2nd edn. Aldine de Gruyter, New York, pp 235–254

  67. Hair JFJ, Wolfinbarger M, Money AH et al (2015) Essentials of business research methods. Routledge, London

    Google Scholar 

  68. Easterbrook S (2006) Doctoral symposium keynote: you gotta have a theory. ACM SIGSOFT Foundations of Software Engineering, Portland, OR

  69. Tversky A, Kahneman D (1973) Availability: a heuristic for judging frequency and probability. Cogn Psychol 5:207–233

    Article  Google Scholar 

  70. Umbach PD (2004) Web surveys: best practices. New Dir Inst Res 2004:23–38. doi:10.1002/ir.98

    Google Scholar 

  71. Gerring J (2006) Case study research: principles and practices, 1st edn. Cambridge University Press, New York

    Book  Google Scholar 

  72. Goknil A, Kurtev I, van den Berg K (2008) A metamodeling approach for reasoning about requirements. In: Model driven architecture–foundations and applications, pp 310–325

  73. Adedjouma M, Dubois H, Terrier F (2011) Requirements exchange: from specification documents to models. In: 16th IEEE international conference on engineering of complex computer systems. IEEE, pp 350–354

  74. Alias-i (2011) LingPipe 4.1.0. http://alias-i.com/lingpipe/. Accessed 24 Feb 2014

  75. Fraser N (2012) Google-diff-match-patch—diff, match and patch libraries for plain text. http://code.google.com/p/google-diff-match-patch/. Accessed 25 Jan 2014

  76. Ellson J, Gansner ER, Koutsofios E et al (2003) Graphviz and dynagraph–static and dynamic graph drawing tools. Graph Draw Softw 127:148

    Google Scholar 

  77. Core Team R (2014) R: a language and environment for statistical computing. R Foundation for Statistical Computing, Vienna

    Google Scholar 

  78. The Standish Group (2010) CHAOS summary for 2010. Standish Group International, Boston, MA

  79. Cao L, Ramesh B (2008) Agile requirements engineering practices: an empirical study. IEEE Softw 25:60–67. doi:10.1109/MS.2008.1

    Article  Google Scholar 

  80. Ott R, Longnecker M (2015) An introduction to statistical methods and data analysis. Cengage Learning, Boston, US

  81. Levenshtein VI (1966) Binary codes capable of correcting deletions, insertions, and reversals. Sov Phys Dokl 10:707–710

    MathSciNet  MATH  Google Scholar 

  82. Peppard J, Ward J, Daniel E (2007) Managing the realization of business benefits from IT investments. MIS Q Exec 6:1–11

    Google Scholar 

  83. Dorfman M (1999) System and software requirements engineering. In: Thayer RH, Dorfman M (eds) SEI interactive. IEEE Computer Society Press, Los Alamitos, CA, pp 7–22

  84. Gilb T, Graham D (1993) Software inspection. Addison Wesley, Boston

    Google Scholar 

  85. Spolsky J (2000) Painless functional specifications—part 4: tips—Joel on software. http://www.joelonsoftware.com/articles/fog0000000033.html. Accessed 3 Dec 2012

  86. Ambler SW (2012) Examining the “Big Requirements Up Front (BRUF) Approach.” In: Agile Modeling. http://www.agilemodeling.com/essays/examiningBRUF.htm. Accessed 3 Dec 2012

  87. Berry DM, Damian D, Finkelstein A et al (2005) To do or not to do: if the requirements engineering payoff is so good, why aren’t more companies doing it? In: 13th IEEE international requirements engineering conference, p 447

  88. Atkinson MT, Dhiensa J, Machin CHC (2006) Opening up access to online documents using essentiality tracks. In: International cross-disciplinary workshop on web accessibility (W4A): building the mobile web: rediscovering accessibility? ACM, New York, NY, USA, pp 6–13

  89. Abelein U, Paech B (2013) Understanding the influence of user participation and involvement on system success—a systematic mapping study. Empir Softw Eng. doi:10.1007/s10664-013-9278-4

    Google Scholar 

  90. Damian D, Chisan J (2006) An empirical study of the complex relationships between requirements engineering processes and other processes that lead to payoffs in productivity, quality, and risk management. IEEE Trans Softw Eng 32:433–453. doi:10.1109/TSE.2006.61

    Article  Google Scholar 

  91. Verner J, Cox K, Bleistein S, Cerpa N (2005) Requirements engineering and software project success: an industrial survey in Australia and the US. Australas J Inf. doi:10.3127/ajis.v13i1.73

    Google Scholar 

  92. Favaro J (2002) Managing requirements for business value. IEEE Softw 19:15–17

    Article  Google Scholar 

  93. Boehm BW (2000) Requirements that handle IKIWISI, COTS, and rapid change. Computer 33:99–102

    Article  Google Scholar 

  94. Cohn M (2005) Agile estimating and planning. Prentice Hall, Upper Saddle River, NJ

    Google Scholar 

  95. Karlsson L, Dahlstedt ÅG, Regnell B et al (2007) Requirements engineering challenges in market-driven software development—an interview study with practitioners. Inf Softw Technol 49:588–604. doi:10.1016/j.infsof.2007.02.008

    Article  Google Scholar 

  96. DeMarco T (2009) Software engineering: an idea whose time has come and gone? IEEE Softw 26:96. doi:10.1109/MS.2009.101

    Article  Google Scholar 

  97. Wieringa RJ (2009) Design science as nested problem solving. In: Proceedings of the 4th international conference on design science research in information systems and technology, p 8

  98. Natt och Dag J, Regnell B, Gervasi V, Brinkkemper S (2005) A linguistic-engineering approach to large-scale requirements management. IEEE Softw 22:32–39. doi:10.1109/MS.2005.1

    Article  Google Scholar 

  99. Juristo N, Moreno AM, Silva A (2002) Is the European industry moving toward solving requirements engineering problems? IEEE Softw 19:70–77. doi:10.1109/MS.2002.1049395

    Article  Google Scholar 

  100. Cleland-Huang J, Settimi R, Romanova E et al (2007) Best practices for automated traceability. Computer 40:27–35. doi:10.1109/MC.2007.195

    Article  Google Scholar 

  101. Lami G (2005) QuARS: a tool for analyzing requirements. Carnegie Mellon Software Engineering Institute, Pittsburgh, PA

  102. Park S, Kim H, Ko Y, Seo J (2000) Implementation of an efficient requirements-analysis supporting system using similarity measure techniques. Inf Softw Technol 42:429–438. doi:10.1016/S0950-5849(99)00102-0

    Article  Google Scholar 

  103. Ferrari A, Gnesi S, Tolomei G (2013) Using clustering to improve the structure of natural language requirements documents. In: 19th International working conference on requirements engineering: foundation for software quality. Springer, Berlin, Heidelberg, pp 34–49

  104. Wiegers K (2000) 10 Requirements traps to avoid. Softw Test Qual Eng J 2

  105. Google Google Trends—Web Search interest—Worldwide (2004)—present. https://www.google.co.uk/trends/explore. Accessed 16 Jul 2015

  106. Buckley K (2010) Manifesto for half-arsed Agile software development. http://www.halfarsedagilemanifesto.org/. Accessed 5 Sep 2014

  107. Brooks FP (1987) No silver bullet: essence and accidents of software engineering. IEEE Comput 20:10–19

    Article  Google Scholar 

  108. Turner R (2007) Toward Agile systems engineering processes. Crosstalk J Def Softw Eng 20:11–15

    Google Scholar 

  109. Merisalo-Rantanen H, Tuunanen T, Rossi M (2005) Is extreme programming just old wine in new bottles. J Database Manag 16:41–61. doi:10.4018/jdm.2005100103

    Article  Google Scholar 

  110. Cohn M (2008) Advantages of the “As a User, I Want” user story template. http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-template. Accessed 25 Feb 2014

  111. Matson E (1997) Please don’t feed the consultants. http://www.fastcompany.com/32476/please-dont-feed-consultants. Accessed 12 Jun 2014

  112. Bhatia J, Sharma R, Biswas KK, Ghaisas S (2013) Using grammatical knowledge patterns for structuring requirements specifications. In: 2013 IEEE third international workshop on requirements patterns (RePa), pp 31–34

  113. Mylopoulos J (2006) Goal-oriented requirements engineering, part II. (Slides). In: 14th IEEE international requirements engineering conference

Download references

Acknowledgments

The authors are grateful to LSC Group for allowing data collection and publication of results. Special thanks are owed to LSC Group’s Chris Lambert, Dr. James Nyambayo, and Dr. Ann Meads for the insightful discussions on the topic. Warm thanks are due to the reviewers of this paper whose suggestions resulted in the clarification of many points, and to both Springer’s editors and Sachi Jain for proofreading and copy-editing.

Author information

Authors and Affiliations

  1. Computer Science, Loughborough University, Loughborough, Leicestershire, UK

    Richard Ellis-Braithwaite, Russell Lock & Ray Dawson

  2. LSC Group, Lichfield, Staffordshire, UK

    Tim King

Authors
  1. Richard Ellis-Braithwaite
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Russell Lock
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Ray Dawson
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Tim King
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Richard Ellis-Braithwaite.

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Ellis-Braithwaite, R., Lock, R., Dawson, R. et al. Repetition between stakeholder (user) and system requirements. Requirements Eng 22, 167–190 (2017). https://doi.org/10.1007/s00766-015-0239-x

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-015-0239-x

Keywords

Search

Navigation