Using the term ‘non-functional requirements’ to describe aspects of software systems which are invisible to the end-user but essential for effective service operation is counter-productive; we should instead use ‘operational requirements’ or ‘operational features’, and schedule these for delivery alongside end-user features.

Update: the Experience DevOps workshop series now has sessions on Software Operability – find out more at http://experiencedevops.org/

One of the most important steps an organisation can make towards improving the operability of its software is to prioritize end-user and operational aspects together in the same way. This means that backlog items (stories) for operational features need to be prioritized alongside the backlog items for end-user (or so-called ‘business’) features, because this helps to communicate to the business that the operational aspects of the software also require specific features if the business requirements are going to be met.

Damon Edwards emphasises the importance of addressing operational requirements as first-class citizens:

However, many organisations use terminology which is unhelpful and counter-productive: ‘features’ or ‘business requirements’ for aspects related to what the end-user experiences, but ‘non-functional requirements’ for aspects of the software which are not visible to the end-user or relate to the (apparently) dark and murky world of IT Operations. It’s clear that the term ‘non-functional’ has been problematic for software development for some time; software guru Tom Gilb is sceptical about the term ‘non-functional requirements’ (preferring ‘quality requirements’ instead), and Agile expert Rachel Davies is also skeptical of the term:

Non-functional is probably a bad name because it sounds like these requirements are intangible, simply properties of a static system

I find the term ‘non-functional’ to be problematic for (at least) three reasons. First, applying the term ‘non-functional’ to aspects of the software invisible to end-users but essential for the operations team is to ignore the operations team as a valid user group, which makes no sense given the amount of time spent by the operations team working with (or often against) the software. That is, from the viewpoint of the operations team, the way in which a component logs messages or sends data to Graphite is the very essence of functionality.

The second reason why using the term ‘non-functional’ is problematic is that by using polarising language (‘functional’ vs. ‘non-functional’), it becomes difficult to avoid seeing non-functional requirements as somehow opposed to functional requirements:

A similar thing happens with words like ‘essential’ and ‘non-essential’, ’employed’ and ‘unemployed’, and ‘confrontational’ and ‘non-confrontational’; each half of the pair is seen as opposing the other in some way. To set up ‘functional’ against ‘non-functional’ requirements is to characterise them incorrectly as fundamentally different, when in fact they are both simply features which enable effective on-going product delivery to end-users, even if end-users do not see every feature.

Thirdly, many so-called non-functional requirements very much affect the functionality of the software as a whole if not correctly addressed: for example, if the capacity or scalability of the software is not substantial enough, parts of the software application might begin to fail for end-users, thus directly affecting ‘functionality’. In effect, ‘functionality’ is often erroneously seen as a collection of independent features, rather than the effective operation of the whole system; therefore, splitting requirements into ‘functional’ and ‘non-functional’ shows a lack of systems thinking.

I think a more effective terminology is ‘end-user features’ (instead of functional requirements) and ‘operational features’ (instead of non-functional requirements), and we should treat these two groups as essentially equally valid candidates for user stories (people like Mike Cohn have been advocating this for some time).

Clearly, changing the terminology from ‘non-functional requirements’ to ‘operational features’ in itself will not have an immediate impact on software operability, but I believe that this change is an enabler for a more effective dialogue about software products and services, one which recognises the need to address operational concerns alongside those visible to end-users.