Requirements Engineering

, Volume 18, Issue 3, pp 293–296 | Cite as

The illusion of requirements in software development

  • Paul RalphEmail author


This viewpoint explores the possibility that many software development projects may have no useful requirements. Specifically, for problems (e.g., knowledge worker burnout) with two completely different solutions (e.g., better tool support or hire more employees), an analyst may state a goal (e.g., decrease work hours) but more specific desiderata are contingent on the chosen solution. Furthermore, without fully exploring the design space, the designer cannot be sure whether there exists another approach, which would achieve the goal without any commonality with known approaches. In these situations of sparse requirements, analysts may misrepresent design decisions as requirements, creating an illusion of requirements in software development.


Requirement Goal Design Fundamentals Philosophy Ontology Epistemology 


  1. 1.
    Boehm B (1991) Software risk management: principles and practices. IEEE Softw 8(1):32–41CrossRefGoogle Scholar
  2. 2.
    Jacobson I, Booch G, Rumbaugh J (1999) The unified software development process. Addison-Wesley Longman Publishing Co., Inc., BostonGoogle Scholar
  3. 3.
    Ewusi-Mensah K (2003) Software development failures. MIT Press, CambridgeGoogle Scholar
  4. 4.
    Standish Group (2009) CHAOS summary 2009. Boston, MA, USA
  5. 5.
    IEEE (1998) IEEE Standard 830-1998: recommended practice for software requirements specifications.
  6. 6.
    Topi H, Valacich JS, Wright RT, Kaiser KM, Nunamaker JF, Sipior JC, Vreede GJd (2010) IS 2010: curriculum guidelines for undergraduate degree programs in information systems. Communications of association for information systems 26:Article 18.
  7. 7.
    Joint Task Force on Computing Curricula (2004) Software engineering 2004: curriculum guidelines for undergraduate degree programs in software engineering. In: Díaz-Herrera JL, Hilburn TB (eds).
  8. 8.
    Simon HA (1996) The sciences of the artificial, 3rd edn. MIT Press, CambridgeGoogle Scholar
  9. 9.
    Brooks FP (2010) The design of design: essays from a computer scientist. Addison-Wesley Professional, ReadingGoogle Scholar
  10. 10.
    Ralph P (2011) Introducing an empirical model of design. Paper presented at the 6th Mediterranean conference on information systems, Limassol, Cyprus, 3–5 SepGoogle Scholar
  11. 11.
    Davis AM, Zowghi D (2006) Good requirements practices are neither necessary nor sufficient. Requir Eng 11(1):1–3CrossRefGoogle Scholar
  12. 12.
    Shenhar AJ, Dvir D, Levy O, Maltz AC (2001) Project success: a multidimensional strategic concept. Long Range Plan 34(6):699–725CrossRefGoogle Scholar
  13. 13.
    van Lamsweerde A (2001) A goal-oriented requirements engineering: a guided tour. In: Proceedings of the fifth IEEE international symposium on requirements engineering, Aug, pp 249–262Google Scholar
  14. 14.
    Sutcliffe A, Thew S, Jarvis P (2011) Experience with user-centred requirements engineering. Requir Eng 16(4):267–280CrossRefGoogle Scholar
  15. 15.
    Chung L, Nixon BA, Yu E (2000) Non-functional requirements in software engineering. Kluwer international series in software engineering, vol 5. Springer, BerlinCrossRefGoogle Scholar
  16. 16.
    Fuxman A, Liu L, Mylopoulos J, Pistore M, Roveri M, Traverso P (2004) Specifying and analyzing early requirements in tropos. Requir Eng 9(2):132–150CrossRefGoogle Scholar
  17. 17.
    Ralph P, Wand Y (2009) A proposal for a formal definition of the design concept. In: Lyytinen K, Loucopoulos P, Mylopoulos J, Robinson W (eds) Design requirements engineering: a ten-year perspective. Lecture notes on business information processing, vol 14. Springer, Berlin, pp 103–136CrossRefGoogle Scholar
  18. 18.
    Bahill AT, Dean FF (2009) Discovering system requirements. In: Sage AP, Rouse WB (eds) Handbook of systems engineering and management, 2nd edn. Wiley, New York, pp 205–266Google Scholar
  19. 19.
    Bourque P, Dupuis R (eds) (2004) Guide to the software engineering body of knowledge (SWEBOK). IEEE Computer Society Press, Silver SpringGoogle Scholar
  20. 20.
    Yu E (1997) Towards modelling and reasoning support for early-phase requirements engineering. In: Proceedings of the third IEEE international symposium on requirements engineering, pp 226–235Google Scholar
  21. 21.
    Roman G-C (1985) A taxonomy of current issues in requirements engineering. Computer 18(4):14–23CrossRefGoogle Scholar
  22. 22.
    Gotel O, Finkelstein A (1994) An analysis of the requirements traceability problem. In: First international conference on requirements engineering, Colorado Springs, CO, USA, IEEE Computer Society Press, pp 94–101Google Scholar
  23. 23.
    Ramesh B, Jarke M (2001) Toward reference models for requirements traceability. IEEE Trans Softw Eng 27(1):58–93CrossRefGoogle Scholar
  24. 24.
    Gregor S (2006) The nature of theory in information systems. MIS Q 30(3):611–642Google Scholar
  25. 25.
    Parsons J, Saunders C (2004) Cognitive heuristics in software engineering: applying and extending anchoring and adjustment to artifact reuse. IEEE Trans Softw Eng 30:873–888CrossRefGoogle Scholar
  26. 26.
    Jansson DG, Smith SM (1991) Design fixation. Des Stud 12(1):3–11CrossRefGoogle Scholar
  27. 27.
    Oswald ME, Grosjean S (2004) Confirmation bias. In: Pohl RF (ed) Cognitive illusions: a handbook on fallacies and biases in thinking, judgement and memory. Psychology Press, Hove, pp 79–96Google Scholar
  28. 28.
    Ralph P (2011) Toward a theory of debiasing software development. In: Wrycza S (ed) Research in systems analysis and design: models and methods: In 4th SIGSAND/PLAIS EuroSymposium 2011. LNBIP, vol 93. Springer, Gdansk, Poland. pp 92–105Google Scholar

Copyright information

© Springer-Verlag London Limited 2012

Authors and Affiliations

  1. 1.Department of Management ScienceLancaster UniversityLancasterUK

Personalised recommendations