'Non-Functional Requirements' Are STUPID

Non-Functional Requirements or NFRs is a terrible name for some very important things. This has nothing at all to do with Functional vs Non-Functional, if the requirements really were “Non Functional” why would we bother working on them? This is really about the more complex aspects of software development. Complex because they are difficult to estimate and hard to localise in our designs.

In this episode Dave Farley author of best selling books “Continuous Delivery” and “Modern Software Engineering” explores why “NFRs” are treated differently and why they are often more problematic than Functional requirements, and describes how best to deal with the complexities of solving the problems posed by these cross-cutting problems that we wrongly pigeon-hole as being “Non-Functional”.

-

⭐ PATREON:

Join the Continuous Delivery community and access extra perks & content!

-

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-

🖇 LINKS:

-

BOOKS:

and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-

CHANNEL SPONSORS:

#softwareengineer #software #developer

[PaulWebb-ef]

Totally agree. This video is reading my mind! I've battled with this stupid term across several projects where PO's and "the business" consider NFR's "the optional things to do at the end of the project". In almost all cases the product has required expensive re-writes or has been hit with the "not fit for purpose" tag by customers. NFR's are almost always the first things to be de-prioritised by the non technical folk when cost/time is an issue. ... and yet, a sure-fire way to vastly exceed your time and budget, is by avoiding things that simply must be done.

[sasukesarutobi]

It's a great irony that projects that neglect the "non-functional" requirements frequently end up being just that.

It's why I prefer the three types of requirements that Kevlin Henney talks about: functional, operational, and developmental. The functional requirements are the same as we know -- specific behaviours or tasks we want the system to be able to perform -- but the other two define other requirements rather than hand-waving it as "that other stuff". For example, response time would be an operational requirement, and maintainability would be a developmental requirement.

Edit: fixed a typo

[stevenleonmusic]

Thank you! I'm experimenting with just using different terminology for a web app class I'm teaching this semester: Constraints. I'm even ditching "Functional Requirements" for "Capabilities". I think Capabilities and Constraints makes sense semantically and avoids the issue of requirements that blur the line between functional and "non-functional". A capability might be a functional task that a user can do or it might be a passive reaction to something; the app is capable of executing a task and capable of notifying the user if the task fails. A constraint is some limiting factor like a rule or environment that the app is bound by (must work on OSX, must use HTTP, etc.).

[Kalisparo]

Lawyer working in IT here. The concept of NFR is a hammer for the customer it can use to hit the Supplier in the head if it wants. The I see in my daily work are typically written in the form of legal requirements such as "The solution must enable the customer to comply with NIS2, applicable local laws (typically tax and accounting), GxP, SOX, etc. They're cross-cutting single requirements where the customer has often been too lazy to specifically define these requirements individually, so they will instead have these completely unreasonable umbrella requirements that are often incredibly difficult to measure. Basically the customer moves liability from it self to the supplier, to which the supplier often have little to no expertise in, nor control over. The downright ridiculous NFRs I often come across are requirements like "it must work", "must improve efficiency", "solution must perform to the customer's expectations", and probably the worst of all "fit for purpose"...

I would argue that NFRs as a concept needs to be dealt with during the contract negotiations and/or while responding to customer requirements. If that fails, provisions should be established in the contract to deal with all NFRs during the design and have the customer approve a particular design prior to implementation, thereby approving that the NFRs are met by the actual design. No competent lawyer/supervisor/salesperson should ever just agree to these unmeasurable atrocities and pass them on to the unsuspecting implementation team.

[garethpatterson]

I was angry at the title, because I find that NFRs tend to be the most important requirements... most critical to get right... most traditionally ignored. You redeemed yourself almost immediately! The term has always been stupid!!! I do think that internet-scale has changed the thinking.... but we've been at "internet scale" for a couple of decades now... so maybe it is time to find a better term! Hoping to see it soon!

[georgehelyar]

We don't even call out these "NFRs". Needs to be secure? Needs to be fast enough? If it isn't then we just can't ship it. If you ship something that is not fast enough it will just hit prod, fail monitors and roll back, and then you will have to do it again, so you just get used to baking these in from the start. They are things that you always need to do, so much so that they are just implicit for us.

[lost-prototype]

Love this one. Totally agree. Every time I hear NFR, I feel like I'm having a discussion about future blame.

[nmprecious]

I agree, but. For functional requirements, we write FUNCTION as part of the application logic to carry out a particular task. For NON-FUNCTIONAL requirements, we do everything else that doesn't require direct api interactions with users through apis. I don't know if i'm right, but that's how I get it.

[nezbrun]

YES!!! I've been banging this drum for 20 years. Putting something in the NFR pile inevitably risks it being descoped or being put to the bottom of the pile in priority, so you end up having to do potentially massive, risky and expensive rework very late in the project life cycle. NFRs need to be integrated and considered from the beginning.

[simonboland]

Good topic but I recommend thinking about it this way. Functional requirements are those requirements that are discussed between a product manager/owner/business analyst and the software team. For example, "You need us to build a frontend that supports a form to input user data and we store this in order to support a specific feature". The conversation is finished and there's clear understanding of the feature. Then the real work for the software team starts. They work on the overarching set of requirements which include latency, security, resilency, monitoring and lots of other stuff that the product manager/owner will not specify nor should have to specify. This just comes with good engineering practice and best practices. You can call this non-functional because it's areas that are not covered in the first conversation. The only time I've seen friction here is when a product manager drifts into the world of engineering and starts to delve in MVP discussions on how the business can't afford to do high-availability etc. because of schedule or cost constraints. There is a where a good engineering team will push back and explain why it's needed.

[antoniorocha]

This clip title is misleading, but happy to learn it covers the topic quite good. It is not hard to work on functional requirements, but the non-functional is really a huge challenge, especially on not small or targeted system.

[kbabiy]

The reasoning starts about bad/misleading name for the important system attributes requirements, but the alternative name is not suggested.

Perhaps, something like Quality Attribute Requirements - QARs - would do the job. And don't forget about Constraints by the way, which are not the same.

QARs are the requirements on system quality attributes (e.g. Performance, Maintainability, Security etc.)

Constraints are the requirements that don't necessarily about system (quality) attributes. They can be business constraints (e.g. cost, time, team structure etc.), technology constraints (e.g. technology stack, hosting provider etc.)

[Noname-rjpq]

Non functional requirements are critical to isolate and identify from the outset because they are often overlooked and require specific testing tools and resources to develop. that's why Non-functional testing exists in ISEB and ISTQB.

[etherweb]

Personally I don't see the big deal in using the term. Nomenclature is secondary. In the simplest terms non-functional requirements are requirements that don't directly dictate the function (intended purpose) of the software. You can call them whatever you like - business requirements, security requirements, benchmark requirements, etc - the key word is requirement. Functional vs non-functional is simply a description of the type of requirement (a requirement of how software does something vs what it does). This video assumes that the term "non-functional" is saying a requirement is not important, which it is not.

[blackZ]

I've been a developer for over 20 years. I don't think I've even heard the term before. But I would agree -- there's no distinction between security, responsiveness, et. al. If those specifications are given by the client, they are simply product requirements. Period.

[michaelchester]

Excellent article, as always.

Years ago, I had a scrum master who told us off whenever people on the team used the terms functional or non-functional. His view, which I adopted, is that everything is functional to someone. Even requirements such as insisting a system must use some particular piece of tech. A technology constraint on a system could be a commercial, legal, accounting or operational function. If you think it's non-functional, then you probably just don't have the whole story yet.

Thank you for providing a framework for dealing with these types of requirements, Dave. That was really thought-provoking and helpful.

[petebrown]

I agree the term is dumb - but I always associate them to 'performance requirements'. E.g. system must boot within 2s. It's not a 'feature' but is a regulatory requirement (automotive).

[andrewsutton]

My problem is that because they are so negatively termed, they get left to the end, when we should be considering them from the start.

[follantic]

Get on a talk with Prime. Would be cool. A talk about naming and value of certain types of tests would be interesting. What are even integration tests?

[Veretax]

I believe it was Cem Kaner years ago suggested we stop calling them 'non functional requirements', because these types of requirements go beyond input/output expectations, but deal with behavior, texture, timing, security etc. I believe he at the time suggested para-functional requirements.... since these abilities are only really testable if the functional requirements are met, but they parallel the functional behavior in ways that may matter.