Definition
Having a site dedicated to Non-Functional Requirements (NFR) requires to give a clear definition of the actual concept.
I have looked all over for a definition that encompasses my view and comprehension. I consulted Google, Wikipedia, many sites dedicated to business analysis and software engineering, the Business Analysis Body of Knowledge (BABOK), to name a few. Call me picky if you like, but nothing made it to the finishing line. They all had a certain centricity on either operation, constraints or qualities, which is for me too restrictive.
On Non-Functional Requirements
Who can pretend to be able to write a definition myself. I was comforted by a white paper called “On Non-Functional Requirements” [1] presented at the very serious 15th IEEE International Requirements Engineering Conference. Some excerpts are transcribed below and the conference proceeding is available for download at the end of this post.
Try to keep in mind that whatever a project team has for a “definition” of Non-Functional Requirements they must be considered seriously.
Abstract
Although the term “non-functional requirement” has been in use for more than 20 years, there is still no consensus in the requirements engineering community what non-functional requirements are and how we should elicit, document, and validate them. On the other hand, there is a unanimous consensus that non-functional requirements are important and can be critical for the success of a project.
Definitions of Non-Functional Requirements
| Definitions |
|---|
| Describe the nonbehavioral aspects of a system, capturing the properties and constraints under which a system must operate. [2] |
| The required overall attributes of the system, including portability, reliability, efficiency, human engineering, testability, understandability, and modifiability. [3] |
| The term is not defined. The standard distinguishes design requirements, implementation requirements, interface requirements, performance requirements, and physical requirements.[4] |
| The term is not defined. The standard defines the categories functionality, external interfaces, performance, attributes (portability, security, etc.), and design constraints. Project requirements (such as schedule, cost, or development requirements) are explicitly excluded. [5] |
| A requirement that specifies system properties, such as environmental and implementation constraints, performance, platform dependencies, maintainability, extensibility, and reliability. A requirement that specifies physical constraints on a functional requirement. [6] |
| Requirements which are not specifically concerned with the functionality of a system. They place restrictions on the product being developed and the development process, and they specify external constraints that the product must meet. [7] |
| “… global requirements on its development or operational cost, performance, reliability, maintainability, portability, robustness, and the like. (…) There is not a formal definition or a complete list of nonfunctional requirements.” [8] |
| The behavioural properties that the specified functions must have, such as performance, usability. [9] |
| A property, or quality, that the product must have, such as an appearance, or a speed or accuracy property. [10] |
| A requirement on a service that does not have a bearing on its functionality, but describes attributes, constraints, performance considerations, design, quality of service, environmental considerations, failure and recovery. [11] |
| A description of a property or characteristic that a software system must exhibit or a constraint that it must respect, other than an observable system behaviour. [12] |
| Requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviours. [13] |
| Requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints). [14] |
Works Cited
| # | Reference | Barnes & Noble | Amazon |
|---|---|---|---|
| [1] | M. Glinz, “On Non-Functional Requirements,” 15th IEEE International Requirements Engineering Conference (RE 2007), Delhi, India, 2007, pp. 21-26, doi: 10.1109/RE.2007.45. | ||
| [2] | Ana I. Anton. 1997. Goal identification and refinement in the specification of software-based information systems. Ph.D. Dissertation. Georgia Institute of Technology, USA. Order Number: UMI Order No. GAX97-35409. | ||
| [3] | A. Davis (1993). Software Requirements: Objects, Functions and States. Prentice-Hall. | ||
| [4] | |||
| [5] | |||
| [6] | |||
| [7] | |||
| [8] | |||
| [9] | |||
| [10] | |||
| [11] | |||
| [12] | |||
| [13] | |||
| [14] |
=
A. Davis (1993). Software Requirements: Objects, Functions and States. Prentice-Hall.
[4]
IEEE (1990). Standard Glossary of Software Engineering Terminology. IEEE Standard 610.12-1990.
[5]
IEEE (1998). IEEE Recommended Practice for Software Requirements Specifications. IEEE Std. 830-1998.
[6]
I. Jacobson, G. Booch, and J. Rumbaugh (1999). The Unified Software Development Process. Reading, Mass.: Addison Wesley.
[7]
G. Kotonya, I. Sommerville (1998). Requirements Engineering: Processes and Techniques. John Wiley & Sons.
[8]
J. Mylopoulos, L. Chung, B. Nixon (1992). Representing and Using Nonfunctional Requirements: A Process-Oriented Approach. IEEE Transactions on Software Engineering 18, 6 (June 1992). 483-497.
[9]
C. Ncube (2000). A Requirements Engineering Method for COTS-Based Systems Development. PhD Thesis, City University London.
[10]
S. Robertson and J. Robertson (1999). Mastering the Requirements Process. ACM Press.
[11]
SCREEN (1999). Glossary of EU SCREEN Project. http://www.screen-lab.eu/index2.html (visited 2007-07-05)
[12]
K. Wiegers (2003). Software Requirements, 2nd edition. Microsoft Press.
[13]
Wikipedia: Non-Functional Requirements http://en.wikipedia.org/wiki/Non-functional_requirements (visited 2007-07-05)
[14]
Wikipedia: Requirements Analysis http://en.wikipedia.org/wiki/Requirements_analysis (visited 2007-07-05)