I Say Requirement, You Say Functionality, They Say Feature!
Afnan AlSubaihin | On 09, May 2016
You might be surprised by the number of times the word feature crops up in Software Engineering research. In ICSE alone, there are 3,232 publications containing the word feature(s) in their title and/or abstract (out of 7,008 publications total). However, regardless of the unified research domain (i.e. software engineering), the term ‘feature’ means different things in different contexts. Too many different things.
These differences can be drastic, but more dangerously, the difference can be unnoticeably slight. The danger is even prominent when different stakeholders hold different conceptions of the same term. To prevent any brains from exploding, I am excluding here the meaning of the term ‘feature’ in machine learning and AI contexts which mean a ‘characteristic’ of the data point to be recorded and fed into the machine learning model. Rather, we shall limit the discussion to the term feature pertaining to software systems and engineering in general.
Thus, I have taken it upon myself to gather this list of definitions, some are conflicting, and some are defining different aspects of the same thing. I shall list here all the definitions I was able to find and the context in which I found them:
The Guide to the Software Engineering Body of Knowledge (a.k.a the bible of software engineering) defines a feature to be a functional requirement:
“An essential property of all software requirements is that they be verifiable as an individual feature as a functional requirement or at the system level as a nonfunctional requirement.”
“Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities or features.”
In the IEEE’s 829 Standard for Software and System Test Documentation, released in 2008, they define a feature as follows:
“A distinguishing characteristic of a software item (e.g., performance, portability, or functionality).”
I am particularly partial to this definition:
“For systems with a large number of internal states, it is easier, and more natural, to modularize the specification by means of features perceived by the customer.” –A. M. Davis
All definitions agree that a feature is a software attribute ultimately present in the solution domain that represents a cohesive set of system functionality. The disagreement is observed with regard to its origin, whether it encapsulates non-functional requirements, the level of granularity of a feature towards functionalities, and the level of visibility to the user in the end product. These ultimately are implicitly agreed-upon depending on the research field.
One aspect of conflict in features are the origin and location in which it is observed. The origin of a feature maybe either in the problem domain or the solution domain . Different lines of research adopt either of these views. In the line of work concerned with feature-oriented software engineering, features are a subset of system requirements. On the other hand, in the literature concerned with feature identification and location, features are assumed to be a subset of system implementation.
In defining the relationship between features and requirements, we observe two different definitions as to whether a feature also represents non-functional requirements. The Institute of Electrical and Electronics Engineers (IEEE)’s definition observed above draws a one-to-one mapping between a feature and both a functional or a non-functional requirement.
On the other hand, the Guide to the Software Engineering Body of Knowledge (SWEBOK) synonymises it with functional requirements as they both represent a software capability than can be tested and verified. This particular definition is used in feature identification and location line of work, as it aims to identify the set of statements that implements a certain feature which can be impossible for non-functional requirements.
Another possible implicit constraint on the usage of the term ‘feature’ is its user-centrality. Turner et al., surmises that features, as opposed to functionalities, are visible properties of a software system: They represent the set of functionality that are specifically user-centric . This particular aspect of the definition of features is observed when reading works pertaining to feature modelling. On the other hand, work on feature identification, not only disregard this aspect, but add their own: a feature is unit of functionality that is optional or incremental to the system .
While navigating through the literature pertaining to software features, a basic knowledge of the different aspects of the meaning of the word is crucial for understanding.
 A. M. Davis, “The design of a family of application-oriented requirements languages,” Computer, vol. 5, no. 15, pp. 21-28, 1982.
 C. R. Turner, A. L.Wolf, A. Fuggetta, and L. Lavazza, “Feature Engineering,” p. 162, Apr. 1998
 B. Dit, M. Revelle, M. Gethers, and D. Poshyvanyk, “Feature location in source code: a taxonomy and survey,” Journal of Software: Evolution and Process, vol. 25, pp. 53-95, Jan. 2013.
(Article photo taken by Filip Federowicz)