Requirements Engineering: Best Practice



Many software solutions have failed because they did not meet stakeholder needs. In response to this problem a massive amount of techniques were developed to elicit stakeholder needs, to analyze the implications of these needs on the software, to specify proposed software products, and to check acceptance of these proposals. However, many of these techniques did not become industrial practice because they were not practicable or ineffective when used in real-world projects. To obtain an overview of what common practice is and to understand which techniques reflect best practice because they are particularly effective, we have surveyed a large number of industry projects. Based on 419 valid answers, this chapter gives an overview of commonly used requirements engineering techniques. It also shows which of the techniques, when used in a software project, correlate with requirements engineering success. The chapter concludes with recommendations for software projects and future research to improve requirements engineering practice.


Requirement Engineering Software Project Business Case Quality Function Deployment Requirement Engineer 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


  1. 1.
    Standish Group International (1995) The CHAOS report. Standish Group International, Inc.Google Scholar
  2. 2.
    Hassenzahl M, Beu A, Burmester M (2001) Engineering Joy. IEEE Software 18(1):70–76CrossRefGoogle Scholar
  3. 3.
    Gorschek T, Wohlin C (2006) Requirements abstraction model. Requirements Eng 11(1):79–101CrossRefGoogle Scholar
  4. 4.
    Glinz M, Fricker S (2013) On shared understanding in software engineering, Software engineering 2012. Aachen, GermanyGoogle Scholar
  5. 5.
    Eveleens L, Verhoef C (2010) The rise and fall of the chaos report figures. IEEE Software 27(1):30–36CrossRefGoogle Scholar
  6. 6.
    Davis A, Zowghi D (2006) Good requirements practices are neither necessary nor sufficient. Requirements Eng 11(1):1–3CrossRefGoogle Scholar
  7. 7.
    Neill C, Laplante P (2003) Requirements engineering: the state of the practice. IEEE Software 20(6):40–45CrossRefGoogle Scholar
  8. 8.
    Paech B, Koenig T, Borner L, Aurum A (2005) An analysis of empirical requirements engineering survey data. In: Aurum A, Wohlin C (eds) Engineering and managing software requirements. Springer, New York, pp 427–452CrossRefGoogle Scholar
  9. 9.
    Rouibah K, Al-Rafee S (2009) Requirements engineering elicitation methods: a Kuwaiti empirical study about familiarity, usage and perceived value. Inform Manag Comput Security 17(3):192–217CrossRefGoogle Scholar
  10. 10.
    Potts C, Takahashi K, Antón AI (1994) Inquiry-based requirements analysis. IEEE Software 11(2):21–32CrossRefGoogle Scholar
  11. 11.
    Cheng B, Atlee J (2007) Research directions in requirements engineering. Future of software engineering (FOSE’07). Washington, DC, USAGoogle Scholar
  12. 12.
    Pohl K, Rupp C (2011) requirements engineering fundamentals: a study guide for the certified professional for requirements engineering exam—foundation level—IREB compliant. Rocky Nook ComputingGoogle Scholar
  13. 13.
    Fricker S, Glinz M (2010) Comparison of requirements hand-off, analysis, and negotiation: case study. 18th IEEE international requirements engineering conference (RE’10). Sydney, AustraliaGoogle Scholar
  14. 14.
    Glinz M, Fricker S (2014) On shared understanding in software engineering: an essay. Computer Science - Research and Development. doi: 10.1007/s00450-014-0256-x. See also:
  15. 15.
    Hickey A, Davis A (2004) A unified model of requirements elicitation. J Manag Inform Syst 20(4):65–84Google Scholar
  16. 16.
    Zowghi D, Coulin C (2005) Requirements elicitation: a survey of techniques, approaches, and tools. In: Aurum A, Wohlin C (eds) Engineering and managing software requirements. Springer, BerlinGoogle Scholar
  17. 17.
    Hickey A, Davis A (2003) Elicitation technique selection: how do experts do it? 11th IEEE international requirements engineering conference. Monterey Beach, CA, USAGoogle Scholar
  18. 18.
    Davis A, Dieste O, Hickey A, Juristo N, Moreno A (2006) Effectiveness of requirements elicitation techniques: empirical results derived from a systematic review. 14th IEEE international requirements engineering conference (RE’06). Minneapolis, MN, USAGoogle Scholar
  19. 19.
    Dieste O, Juristo N, Shull F (2008) Understanding the customer: what do we know about requirements elicitation? IEEE Software 25(2):11–13CrossRefGoogle Scholar
  20. 20.
    Pérez-Castillo R, Garciía-Rodríguez de Guzmán I, Piattini M (2011) Business process archeology using MARBLE. Inform Software Technol 53(10):1023–1044CrossRefGoogle Scholar
  21. 21.
    Maiden N, Gizikis A, Robertson S (2004) provoking creativity: imagine what your requirements could be like. IEEE Software 21(5):68–75CrossRefGoogle Scholar
  22. 22.
    Gorschek T, Fricker S, Palm K (2010) A lightweight innovation process for software-intensive product development. IEEE Software 27(1):37–45CrossRefGoogle Scholar
  23. 23.
    Cleland-Huang J, Mobasher B (2008). Using data mining and recommender systems to scale up the requirements process. 16th IEEE international requirements engineering conference (RE’08). Barcelona, SpainGoogle Scholar
  24. 24.
    Alvarez R, Urla J (2002) Tell me a good story: using narrative analysis to examine information requirements interviews during an ERP implementation. Data Base Adv Inform Syst 33(1):38–52CrossRefGoogle Scholar
  25. 25.
    Vermersch P (2009) Describing the practice of introspection. J Conscious Stud 16(10–12):20–57Google Scholar
  26. 26.
    Beyer H, Holtzblatt K (1995) Apprenticing with the customer. Commun ACM 38(5):45–52CrossRefGoogle Scholar
  27. 27.
    Ng L, Barfield W, Mannering F (1995) A survey-based methodology to determine information requirements for advanced traveler information systems. Transport Res C Emerg Technol 2:113–127CrossRefGoogle Scholar
  28. 28.
    Lam W, McDermid J, Vickers A (1997) Ten steps towards systematic requirements reuse. Requirements Eng 2(2):102–113CrossRefGoogle Scholar
  29. 29.
    Gottesdiener E (2002) Requirements by collaboration: workshops for defining needs. Addison-Wesley ProfessionalGoogle Scholar
  30. 30.
    Mylopoulos J, Chung L, Yu E (1999) From object-oriented to goal-oriented requirements analysis. Commun ACM 42(1):31–37CrossRefGoogle Scholar
  31. 31.
    van de Weerd I, Brinkkemper S, Nieuwenhuis R, Versendaal J, Bijlsma L (2006) Towards a reference framework for software product management. 14th IEEE international requirements engineering conference (RE’06). Minneapolis, MN, USAGoogle Scholar
  32. 32.
    Martin RC, Meinik G (2008) Tests and requirements, requirements and tests: a möbius strip. IEEE Software 25(1):54–59CrossRefGoogle Scholar
  33. 33.
    Danevas P, Garva G (2012) Domain driven development and feature driven development for development of decision support systems. 18th international conference on information and software technologies (ICIST 2012). Kaunas, LithuaniaGoogle Scholar
  34. 34.
    Holtmann J, Meyer J, von Detten M (2011). Automatic validation and correction of formalized, textual requirements. IEEE fourth international conference on software testing, verification and validation workshops (ICSTW 2011). Berlin, GermanyGoogle Scholar
  35. 35.
    Glinz M (2010) Very lightweight requirements modeling. 18th IEEE international requirements engineering conference (RE’10). Sydney, AustraliaGoogle Scholar
  36. 36.
    Arlow J, Neustadt I (2005) UML 2 and the unified process: practical object-oriented analysis and design. Addison-Wesley Pearson Education, NJ, USA See also:
  37. 37.
    Rettig M (1994) Prototyping for tiny fingers. Commun ACM 37(4):21–27CrossRefGoogle Scholar
  38. 38.
    Chung L, Nixon B, Yu E, Mylopoulos J (2000) Non-functional requirements in software engineering. Kluwer Academic Publishers, BostonzbMATHCrossRefGoogle Scholar
  39. 39.
    Ross D (1977) Structured analysis (SA): a language for communicating ideas. IEEE Trans Software Eng 3(1):16–34CrossRefGoogle Scholar
  40. 40.
    DeMarco, T. (1979). Structured Analysis and System Specification, Yourdon Press.Google Scholar
  41. 41.
    Schmidt M (2002) The business case guide. Solution Matrix, BostonGoogle Scholar
  42. 42.
    Achimugu P, Selamat A, Ibrahim R, Mahrin MNR (2014) A systematic literature review of software requirements prioritization research. Inform Software Technol 56(6):568–585CrossRefGoogle Scholar
  43. 43.
    Svahnberg M, Gorschek T, Feldt R, Torkar R, Bin Saleem S, Shafique MU (2010) A systematic review on strategic release planning models. Inform Software Technol 3:237–248CrossRefGoogle Scholar
  44. 44.
    Phaal R, Farrukh C, Probert D (2003) Technology roadmapping—a planning framework for evolution and revolution. Technol Forecast Soc Change 71:5–26CrossRefGoogle Scholar
  45. 45.
    Fricker S, Schumacher S (2012) Release planning with feature trees: industrial case. Requirements engineering: foundations for software quality (RefsQ 2012). Essen, GermanyGoogle Scholar
  46. 46.
    Davis A (2005) Just enough requirements management. Dorset House Publishing, New YorkGoogle Scholar
  47. 47.
    McGrath ME (2001) Product strategy for high technology companies: accelerating your business to web speed. McGraw-Hill, New YorkGoogle Scholar
  48. 48.
    Whittle J, Schumann J (2000) Generating statechart designs from scenarios. IEEE international conference on software engineering (ICSE 2000). Limerick, IrelandGoogle Scholar
  49. 49.
    Berard B, Bidoit M, Finkel A, Laroussinie F, Petit A, Petrucci L, Schnoebelen P (2010) Systems and software verification: model-checking techniques and tools. Springer, BerlinGoogle Scholar
  50. 50.
    IEEE (1990) IEEE standard glossary of software engineering terminology 610.12-1990Google Scholar
  51. 51.
    Myers B (1989) User-interface tools: introduction and survey. IEEE Software 6(1):15–23CrossRefGoogle Scholar
  52. 52.
    Chung J-Y, Lin K-J, Mathieu R (2003) Web services computing: advancing software interoperability. IEEE Comput 36(10):35–37CrossRefGoogle Scholar
  53. 53.
    Melão N, Pidd M (2000) A conceptual framework for understanding business processes and business process modelling. Inform Syst J 10(2):105–129CrossRefGoogle Scholar
  54. 54.
    ISO/IEC (2010) Systems and software quality requirements and evaluation, ISO/IEC. ISO/IEC FDIS 25010Google Scholar
  55. 55.
    Alexander I, Maiden N (2005) Scenarios, stories, use cases: through the systems development life-cycle. Wiley, HobokenGoogle Scholar
  56. 56.
    Alexander I, Robertson S (2004) Understanding project sociology by modeling stakeholders. IEEE Software 21(1):23–27CrossRefGoogle Scholar
  57. 57.
    van Lamsweerde A (2001) Goal-oriented requirements engineering: a guided tour. 5th IEEE international symposium on requirements engineering (RE’01). Toronto, CanadaGoogle Scholar
  58. 58.
    Denger C, Berry D, Kamsties E (2003) Higher quality requirements specifications through natural language patterns. IEEE international conference on software: science, technology and engineering (SwSTE’03). Herzelia, IsraelGoogle Scholar
  59. 59.
    Dwarakanath A, Ramnani R, Sengupta S (2013) Automatic extraction of glossary terms from natural language requirements. 21st IEEE international requirements engineering conference (RE’13). Rio de Janeiro, BrazilGoogle Scholar
  60. 60.
    Bajec M, Krisper M (2005) A methodology and tool support for managing business rules in organisations. Inform Syst 30(6):423–443CrossRefGoogle Scholar
  61. 61.
    Easterbrook S, Lutz R, Covington R, Kelly J, Ampo Y, Hamilton D (1998) Experiences using lightweight formal methods for requirements modeling. IEEE Trans Software Eng 24(1):1–11CrossRefGoogle Scholar
  62. 62.
    Porter A, Votta L, Basili V (1995) Comparing detection methods for software requirements inspections—replicated experiment. IEEE Trans Software Eng 21(6):563–575CrossRefGoogle Scholar
  63. 63.
    Glinz M, Seybold C, Meier S (2007) Simulation-driven creation, validation and evolution of behavioral requirements models. Dagstuhl-workshop MBEES: Modellbasierte Entwiclung eingebetteter Systeme III (MBEES 2007). Braunschweig, GermanyGoogle Scholar
  64. 64.
    Fricker S (2009) Pragmatic requirements communication: the handshaking approach. Shaker, GermanyGoogle Scholar
  65. 65.
    Fricker S, Gorschek T, Byman C, Schmidle A (2010) Handshaking with implementation proposals: negotiating requirements understanding. IEEE Software 27(2):72–80CrossRefGoogle Scholar
  66. 66.
    Raiffa H (2007) Negotiation analysis: the science and art of collaborative decision making. Harvard University Press, CambridgeGoogle Scholar
  67. 67.
    Milne A, Maiden N (2012) Power and politics in requirements engineering: embracing the dark side? Requirements Eng 17(2):83–98CrossRefGoogle Scholar
  68. 68.
    Schobbens P-Y, Heymans P, Trigaux J-C, Bontemps Y (2007) Generic semantics of feature diagrams. Comput Networks 51(2):456–479zbMATHCrossRefGoogle Scholar
  69. 69.
    Boehm B, Grünbacher P, Briggs R (2001) Developing groupware for requirements negotiation: lessons learned. IEEE Software 18(3):46–55CrossRefGoogle Scholar
  70. 70.
    Conradi R, Westfechtel B (1998) Version models for software configuration management. ACM Comput Surv 30(2):232–282CrossRefGoogle Scholar
  71. 71.
    Kobayashi A, Maekawa M (2001) Need-based requirements change management. 8th annual IEEE international conference and workshop on the engineering of computer based systems (ECBS 2001). Washington, DC, USAGoogle Scholar
  72. 72.
    Petersen K, Wohlin C (2010) Measuring the flow in lean software development. Software Pract Experience 41(9):975–996CrossRefGoogle Scholar
  73. 73.
    Kniberg H, Skarin M (2010) Kanban and scrum—making the most of both. lulu.comGoogle Scholar
  74. 74.
    Cleland-Huang J, Settimi R, Romanova E, Berenbach B, Clark S (2007) Best practices for automated traceability. Computer 40(6):27–35CrossRefGoogle Scholar
  75. 75.
    El Emam K, Madhavji N (1985) A field study of requirements engineering practices in information systems development. 2nd IEEE international symposium on requirements engineering (RE’95). York, EnglandGoogle Scholar
  76. 76.
    Rea L, Parker R (2005) Designing and conducting survey research: a comprehensive guide. Jossey-Bass, San FranciscoGoogle Scholar
  77. 77.
    Holm S (1979) A simple sequential rejective multiple test procedure. Scand J Stat 6(2):65–70zbMATHMathSciNetGoogle Scholar
  78. 78.
    Cockburn A (2001) Writing effective use cases. Addison-Wesley Professional, BostonGoogle Scholar
  79. 79.
    Wohlin C, Runeson P, Host M, Ohlsson C, Regnell B, Wesslén A (2000) Experimentation in software engineering: an introduction. Springer, BerlinCrossRefGoogle Scholar
  80. 80.
    Khurum M, Fricker S, Gorschek T (2014) The contextual nature of innovation—an empirical investigation of three software intensive products. Inform Software Technol. doi: 10.1016/j.infsof.2014.06.010. See also:
  81. 81.
    Thuemmler C, Fricker S, Mival O, Benyon D, Buchanan W, Paulin A, Fiedler M, Koops B-J, Kosta E, Grottland A, Schneider A, Jell T, Gavras A, Barros M, Magedanz T, Cousin P, Ispas I, Petrakis E (2013) Norms and standards in modular medical architectures. IEEE 15th international conference on e-health networking, applications and services (Healthcom 2013). Lisbon, PortugalGoogle Scholar
  82. 82.
    Fricker S, Gorschek T, Glinz M (2008). Goal-oriented requirements communication in new product development. International workshop on software product management (IWSPM 2008). Barcelona, SpainGoogle Scholar

Copyright information

© Springer International Publishing Switzerland 2015

Authors and Affiliations

  1. 1.Software Engineering Research LaboratoryBlekinge Institute of TechnologyKarlskronaSweden
  2. 2.Zühlke Engineering AGSchlierenSwitzerland
  3. 3.SwissQ Consulting AGZürichSwitzerland

Personalised recommendations