Software developers may learn what a requirement is by their experience with representations of requirements. But they would be mistaken if they thought that the word ‘requirement’ refers to something that any of them has ever seen. 1
Abstract
Requirements representations are often confused with requirements. This confusion is not just widespread in practice, but it exists even in the latest requirements engineering research and theory, leading to a number of negative consequences. In this article, we discuss these negative consequences, and present a solution based on a strict distinction between requirements per se and requirements representations. We elaborate on this distinction and classify different forms of representations in a unified requirements representations ontology, including a refinement of descriptive and model-based requirements representations.
Similar content being viewed by others
References
Davis AM (2005) Just Enough Requirements Management: Where Software Development Meets Marketing. Dorset House Publishing Company, New York
IEEE Standards Board (1990) IEEE Standard Glossary of Software Engineering Terminology. The Institute of Electrical and Electronics Engineers, New York
INCOSE (2006) Systems Engineering Handbook, Version 3.0. International Council on Systems Engineering, Seattle
Jureta IJ, Mylopoulos J, Faulkner S (2008) Revisiting the core ontology and problem in requirements engineering. In: Proc. 16th IEEE International Requirements Engineering Conference, Sept. 2008, pp 71–80
Hinds C (2008) The case against a positivist philosophy of requirements engineering. Requir Eng 13:315–328
Kaindl H (1997) A practical approach to combining requirements definition and object-oriented analysis. Annals Softw Eng 3:319–343
Kaindl H (1999) Difficulties in the transition from OO analysis to design. IEEE Softw 16:94–102
Kaindl H (2005) A scenario-based approach for requirements engineering: experience in a telecommunication software development project. Syst Eng 8(3):197–209
Kaindl H, Svetinovic D (2008) Requirements vs. software design: An explanation based on the distinction between concepts and their representations. In Proc. Third International Multi-Conference on Computing in the Global Information Technology (ICCGI 2008). IEEE Xplore, pp 102–106
Roman G-C (1985) A taxonomy of current issues in requirements engineering. IEEE Comput 18(4):14–22
Zave P, Jackson M (1997) Four dark corners of requirements engineering. ACM Trans Softw Eng Methodol (TOSEM) 6(1):1–30
Acknowledgments
Part of this work has been funded by the EU in the ReDSeeDS (Requirements Driven Software Development System) project (contract number IST-33596 under the 6th framework programme), see www.redseeds.eu.
Author information
Authors and Affiliations
Corresponding author
Additional information
1This quote is taken from “The Allegory of the Cave” as given at the time of this writing under http://faculty.washington.edu/smcohen/320/cave.htm. However, it is actually modified through the following textual substitutions: (1) “The prisoners” → “Software developers”, (2) “book” → “requirement”, (3) “shadows” → “representations”.
Rights and permissions
About this article
Cite this article
Kaindl, H., Svetinovic, D. On confusion between requirements and their representations. Requirements Eng 15, 307–311 (2010). https://doi.org/10.1007/s00766-009-0095-7
Received:
Accepted:
Published:
Issue Date:
DOI: https://doi.org/10.1007/s00766-009-0095-7