Features vs Capabilities

I have read tens of thousands of pages on these subjects. I will be touching on this subject a great deal in my channel, UML Operator.

We tend to use "Features" and "Capabilities" a lot, but don't necessarily understand what they mean. I see this in scope documents, and it is sometimes clear that folks are confused or confusing.

I once saw on Quora, A capability is the ability to do something, normally it is provided by the infrastructure of the software system and makes features possible. 

The author was not using it in the sense of a high level possible goal to be achieved using the system, but rather as an enabler that makes features and high level possible goals capable of being accomplished through their existence. In other words I am not using the term here as a collection of features that might be used to achieve something. That is another meaning of the term.

As for feature, a feature is something that the system does that is visible to the user and thus part of the superstructure of the system normally associated with the user interface.

Features are possible but Capabilities as enablers of Features are necessary. That is why I too distinguish them in terms of being either in the superstructure (built on top of something) or infrastructure (foundation) of the software system.

Features may be collected together to make high level capabilities that aim to achieve goals or missions possible.

Both are captured by functional requirements of the system normally, but they may be associated with non-functional requirements as well. Traditionally we would just talk about different types of functional requirements.

This term Feature has come to prominence in Agile terminology because the focus is on adding features in sprints, but many times features cannot be added until capabilities as enablers are added to the infrastructure of the software that allow for the features.

This feature oriented software development can be a huge problem if the need to design the capabilities of the infrastructure are ignored and features outrun capabilities of the system.

There is a difference between the capability of the software as an enabler for actions based on exposed features and the capabilities given to users through providing infrastructural support for the accomplishment of high level goals or missions.

This terminology I happen to be using here has its roots in Agile development and the idea that stories capture features but normally Epics address instilling the capabilities in the infrastructure that makes the features possible. See Features and Capabilities - Scaled Agile Framework Notice here what I am calling a infrastructural functional capability is called an enabler.

Using this distinction between super-structural features and infrastructural functional capabilities is just a crude way to talk about what is essential to systems, for example the systems central and most important part of what has internal relations and connects features and capabilities. Features relate to what is beyond the system, and capabilities as enablers are what relate to the internal necessities of the functioning of the system. Both of these are related to External relations either with other systems or among components of systems. Neither of these really address internal relations which must exist for the system to have an intrinsic nature of its own, which here some call its 'nucleus'.

The whole purpose of making this distinction is to point out what is missing that is not captured by the external relations among components of the infrastructural support, and the external relations between other systems to which the superstructure of features appear. What is missing is the internal relations of the 'nucleus' of the system that interfaces between these two sets of external relations at different levels of differentiation.

There is a difference between the capabilities of a system and the capabilities of the users of a system. Here I am talking about the capabilities of the system that make features possible. Based on features of the system supplied to the Users as affordances they then become capable of accomplishing goals and objectives.  In design, affordance has a narrower meaning, it refers to possible actions that an actor can readily perceive. Note that the term affordance normally refers to the emergent properties of the system and things made possible that without the system would remain impossible to accomplish for users. The term then affordance indicates that the users are relating to what is absolutely necessary of the system and properties that become apparent resulting from various interacting components within a system, and are properties that do not belong to the individual components themselves. 

I would like to note that this distinction between features and capabilities as functional enablers within the infrastructure of the software taken from Agile Software Development and turned to my own purposes is inessential to my argument.