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.
9 thoughts on “Let’s Talk About Operational Features, not Non-Functional Requirements”
Yup – I was just saying the other day that if “development” or “the business” had ever taken “non-functional requirements” seriously then the need for “DevOps” would have been seriously reduced!!!
Even worse: Dev teams which think “DevOps” is somehow devs doing ops stuff (“how difficult can it be”, right?), or how “NoOps” means no operational capability within the team, as if “operations” is just some legacy overhead which the magical world of cloud renders obsolete! Complicated web systems don’t simply operate themselves, and product teams cannot magically achieve reliable systems without operational expertise, yet this seems to be the view in some places. Crazy.
Pingback: Questions to ask when applying for DevOps jobs | Matthew Skelton
Pingback: Joining up Agile and ITIL for DevOps success | Skelton Thatcher - Blog
Thanks Matthew. It’s a term i have been wanting a replacement for. Attempting to explain non-functional requirements to say a marketing team doesn’t get you too far. The next challenge i have though is elaborating the definitions. For example, if i look at scalability, what does it encompass? Databases, Compute, etc. What else would fall under databases? For instance sizing, etc. I would be extremely grateful if you had a matrix of sorts with descriptors you would be willing to share.
Thanks, Igor. I agree that elaborating the definitions is important if we’re to get better traction with budget-holders. There is some information in the Ford et al book ‘Patterns for Performance and Operability’ but that book is essentially pre-cloud, which is why I am writing a new book on operability with my colleague, Rob Thatcher: http://operabilitybook.com/ – we plan to publish the book in chunks from April/May 2015.
Dear Igor, there is nothing like a Scalability per se. Scalability tries to answer managment questions. What do I need to do if e.g. the number of online uses doubles? What do I need to do to e.g reduce latency to the half of the current value? and so on. If one talks about Scalability he or she Needs to specify the parameter it refers to (users, latency,…)
To get a graph for the specified parameter you need to run several tests with fixed parameters and plot it. You also can play with the things you might do: add a server to a cluster, add more memory,… to see how that plot is influenced.
Extrapolating your plots you get an estimate for your managers, but never state “this product scales” or handly scalability as a yes/no-question. Scalability is a statement about the effort to take when something changes that is likely to change.
Pingback: Random links from Operability.IO conference Part 2 | Yesterday I was wrong
Great post, most informative, didn’t realise devops were into this.