When working with software requirements, it is sometimes useful to reflect about what exactly software requirements are? As with most software engineering terms, also for software requirements there doesn’t exist a generally agreed-upon definition. So one can best attain a deeper understanding through consulting and comparing multiple alternative definitions.
My favorite definition of software requirements is the one from Sommerville and Sawyer:
Requirements are […] a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system.
(I. Sommerville und P. Sawyer, Requirements Engineering: A Good Practice Guide, 1. Auflage. John Wiley & Sons, 1997.)
This definition is crisp, easy to read, and covering the most essential aspects of requirements. It does also not stipulate that requirements needed to be documented, which makes it cover also the use of requirements within agile software development.
Perhaps the most frequently cited definition has been developed by a committee of the IEEE Computer Society. It distinguishes three different meanings of requirements. So it is rather precise but also a bit difficult to read and comprehend:
(1) A condition or capability needed by a user to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
(3) A documented representation of a condition or capability as in (1) or (2).
(The Institute of Electrical and Electronics Engineers (IEEE), IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990. IEEE Publications,U.S., 1990. – First edition from 1983)
In the following you find several additional definitions in chronogical order of appearance. So you can also get an impression of how our view of software requirements has evolved.
Gause & Weinberg, 1989
If you employ other people to help you develop what you want, you’d describe what you want for them. That description is called a problem statement or a set of requirements […]. Obviously, requirements are important because if you don’t know what you want, or don’t communicate what you want, you reduce your chances of getting what you want.
(D. C. Gause und G. M. Weinberg, Exploring Requirements: Quality Before Design. Dorset House Publishing Co Inc.,U.S., 1989.)
Note: Most early literature on requirements does not explicitly define the requirements term but rather circumscribes requirements and their role in software development.
Robertson & Robertson, 1999
Something that the product must do, or a property that the product must have.
(S. Robertson und J. Robertson, Mastering the Requirements Process: Getting Requirements Right. Addison-Wesley Longman, Amsterdam, 1999.)
Wiegers, 1999
A statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective. A property that a product must have to provide value to a stakeholder.
(K. E. Wiegers, Software Requirements, Second Edition, 2nd Ed. Microsoft Press, 2003. – First edition from 1999)
Gottesdiener, 2002
The needs or conditions to be satisfied on behalf of users and suppliers.
(E. Gottesdiener, Requirements by Collaboration: Workshops for Defining Needs. Addison-Wesley Longman, Amsterdam, 2002.)
Cohn, 2004
Software requirements is a communication problem.
(M. Cohn, User Stories Applied: For Agile Software Development. Addison-Wesley Longman, Amsterdam, 2004.)
Note: Most literature on agile development avoids providing explicit definitions of requirements. The authors rather circumscribe agile requirements concepts, they describe the role of requirements-related information during the agile development cycle, or they explain requirements-related agile practices. This is surprisingly similar to the lack of explicit definitions in the early stages of the software engineering discipline during the 1980’ies and during the 1990’ies.
Robertson & Robertson, 2012
Something that the product must do, or a property that the product must have, that is needed or wanted by the stakeholders.
(S. Robertson und J. Robertson, Mastering the Requirements Process: Getting Requirements Right, 3rd revised edition. Addison-Wesley Longman, Amsterdam, 2012.)