"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!
JOIN HERE and start your free trial to see if you like it! There are then options from just £2 a month ➡️ bit.ly/ContinuousDeliveryPatreon
-
👕 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!
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-
🖇 LINKS:
AVOID COMMON PITFALLS PDF GUIDE | FREE DOWNLOAD ➡️ www.subscribepage.com/avoid-p...
“Non Functional Requirement”, Wikipedia ➡️ en.wikipedia.org/wiki/Non-fun...
“Non-functional Requirements: Examples, Types, How to Approach” ➡️ www.altexsoft.com/blog/non-fu...
-
BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
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:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Tricentis is an AI-powered platform helping you to deliver digital innovation faster and with less risk by providing a fundamentally better approach to test automation. Discover the power of continuous testing with Tricentis. ➡️ bit.ly/TricentisCD
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
#softwareengineer #software #developer

[@user-te8bj8ny7e]

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.

[@sasukesarutobi3862]

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

[@davidmartensson273]

I like this break down, I will try to establish that for us :)

[@soothcoder]

Ha general quality stuff like maintainability are nearly implicit and form another class again. I worked on a project where requirements were cataloged and numbered (it was Defence) so we started referring to a mythical requirement zero ‘The system shall be groovy’ :). NFRs are nearly statements of intent sometimes rather than real requirements but are important to shape the system. Was a good overview of the issues with them.

[@MahmoudAbduljawad]

What talk is that, @sasukesarutobi3862? Could you share a link or talk name?

[@garethpatterson1504]

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!

[@kbssanik]

We were click baited, my friend.

[@errrzarrr]

Quality requirements is the proper term. But whatever the name you chose, they are very useful and needed. Without them we are building a fast race car without brakes.

[@CoxJul]

"Service level requirements" or "Service qualities"? In the BCS Business Analysis discipline we compare "What the system needs to do" (fn) compared to "How or how well a system does it" (nfr), there are other types of requirement that deal with other high level aspects like compliance (general) and constraints on choice of technology (technical/architecture decisions). All are treated and need to be tested/accepted equally.

[@haxwithaxe]

He's so good at the rage baiting that I went for a couple years skipping over his videos because the titles looked like crazy talk.

[@edwardcullen1739]

​@@kbssanik No clickbait for me. I already came to this conclusion: NFR is an unhelpful term. Cross-functional would be better, but I don't think there's any meaningful distinction. The system must do what it must do, trying to split "requirements" into categories is just a distraction.

[@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.).

[@kbssanik]

Wow, that was usefull

[@colemichae]

But does not cover those wish list extras items, that are not required, still thinking of a good word

[@salvatoreshiggerino6810]

This is exactly the right idea. Unfortunately in my experience it has been extremely hard to convince people to think about and in terms of constraints, and I'm still trying to figure out why.

[@user-te8bj8ny7e]

Good points. I'm taking this a step further and just calling NFR's "requirements". There are plenty of systems that are "functional" from the point of view that they "do stuff" but are completely "unable to function" ( using this term over "non-functional" quite intentionally here), because they missed essentials such as performance, reliability etc. In my experience, avoidance of non-functionals tends to go hand in hand with avoidance of any essential complexity, especially in organisational cultures that look for things they can "work around" so as to hit arbitrary targets (like time and cost). Non functional can be perceived as "optional", "too hard", "low value" etc which is the kind of thing such places will latch on to. If we start treating NFR's as an "enabler of functionality", and stop using loaded terminology that implies they have nothing to do with functionality, then i think we're in a vastly better place. That said .. i vastly prefer "constraint" over NFR.

[@mikemarkoeVideo]

I think of a capability as something the system can do when used by a person. And a function is a system behavior.

[@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.

[@errrzarrr]

Agile development in a nutshell and their disparagement for quality. They are the quickest to build the fastest race car that have ever existed... _without brakes._

[@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.

[@r_j_p_]

wow - hugely important comment. Bravo for sharing the legal/contractual angle.

[@Kalisparo]

@@r_j_p_ What I generally see is that legal/presale do not have enough expertise to understand what the delivery team is actually doing to negotiate and write a proper contract. Similarly I see that contract management is mostly if not entirely absent on the side of the delivery team. Project managers either do not care or they lack the understanding to deliver in accordance with a written contract (don't get me started on change management here...). It depends a lot on the country and culture of course, but the more detached legall is from the delivery team, the worse situation you are going to end up in. I often see inhouse (customer) legals write standard contracts for use towards that particular company's suppliers, which the customer's own internal IT are unwilling to / incapable of living up to. This creates a ridiculous situation where the customer will faciliate a methodology or ways of working with the supplier that is by itself a breach of contract. This is caused by legals and management in those companies having big and smart (on paper) thoughts about how work should be structured. They do however forget that it is supposed to be followed by humans. The consequence of this is that the supplier will most often just go along with the customer's wishes (because suppliers have an aversion to conflict), as conflicts do not promote good corporation and rarely results in great projects. I work for a supplier of IT consultancy services, so I often face these problems. The only solution as I see it is for legals and presale to go back to school and get an understanding of what (and how) the delivery team actually work, which would enable them to negotiate and sign contracts that do not directly contradict human nature (and the delivery team). Hereafter there should be a handover and walkthrough of the signed contract with the delivery team's project management so that they may have a chance to actually deliver what has been agreed.

[@archie15900]

That's a viewpoint I hadn't considered - really interesting and valuable comment! Thank you.

[@lost-prototype]

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

[@nezbrun872]

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.

[@Noname-rj8pq]

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.

[@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.)

[@antoniorocha9438]

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.

[@PaulSebastianM]

8:00 how do we tackle so called NFRs, that are actually business requirements that we are too afraid to think about? Obviously by thinking about them through system design! Thank you Dave! ❤

[@andresgarciagarcia5727]

Sadly the big tech interview format perpetuates this understanding of functional vs non-functional requirements. The system design interview has a well know "playbook" where the candidate lists these requirements separately. Funny part is that often this doesn't go anywhere, as candidates rarely explain how to make their system more secure, extensible, etc. (scalability is an exception). It's just going to the motions to check the boxes of what interviewers expect.

[@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?

[@petebrown6356]

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).

[@andrewsutton1657]

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.

[@black350Z]

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.

[@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.

[@tiagodagostini]

The classic terminology from the 60's, ORTHOGONAL requirements is the best one. They are not laid upon the axis of actuation of the system, but they are Still requirements.

[@calkelpdiver]

Totally completely fully agree with you about the term "NFR". Unfortunately it is used as an "umbrella" term to encompass things such as Security, Load/Performance, Accessibility/Usability, Configuration, etc. I come from a long background in Software Testing, and have done Load/Performance Testing work where we talk about Service Level Agreements (SLA) and Service Level Indicators (SLI) / Metrics. Over the last few years I've heard people confuse SLA/SLI with NFR's, and it is frustrating. But this is Software, where everyone has to come up with new terms in order to sound modern and cool. We are our own worst enemies when it comes to terminology and meaning. Again, I agree with you and the stupidity of the term NFR (Not Freaking Real).

[@user-te8bj8ny7e]

Your last paragraph is spot on. A builder puts up walls and structures that hold up a building, they use simple terms like "structural beam" that clearly denotes that without it your building will fall down. However in our industry we give a fuzzy and dimissable terms to the things that hold up our software. We must remove terminology that hides criticality. The other obvious example is "microservices" ... ugh.

[@tiagodagostini]

The classic term from software engineering are ORTHOGONAL REQUIREMENTS. because they are orthogonal to the task the system performs (in the very algebric sense of the word). That terminology is way better.

[@username7763]

Dave is saying the opposite of what I feared he would say. Non-functional requirements are hugely important, I was worried he'd say to just concentrate on the functional stuff; I am very glad he didn't. The non-functional requirements are the difference between integrating with MS Excel in your application and writing the equivalent functionality of MS Excel from scratch. From a functional perspective they are the same, but from a business, product and effort perspective they are worlds apart. When I took requirements class in college, it stressed the importance of non-functional requirements. To me, I've always had the impression that the non-functional requirements are the most important when it comes to the how large of effort the project will be. This is why they are put in a special section, because they are so especially important. Sad to hear that people are dismissing them. The point of non-functional requirements are so they aren't dismissed. But yeah, maybe the name sucks.

[@ndewet]

Pretty sure it was Rick Kazman who suggested, some time ago, that the term NFR is a dysfunctional term and so suggests using the term "Quality Attribute Requirement". Just study Software Architecture material from the SEI at Carnegie Mellon. But even if you are terms such as security as a quality attribute requirement that is generally misunderstood, for example the CIA Triad (Confidentiality, Integrity and Availability) breaks down what Security means in terms of concerns. Ultimately it would be great if the discipline of Software Architecture gets more weight behind it, as well the SEI. We have the term "Solution Architecture" but that is also dysfunctional as there are no solutions, only trade-offs.

[@michaelchester3439]

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.

[@errrzarrr]

Yeah. The proper term is _quality requirements_ instead of NFR

[@ContinuousDelivery]

That is almost as bad, why would I implement a requirement that didn't represent a desirable quality of the system? I think that they are all just requirements, it is just that some requirements are trickier to plan than others, but at least as important and valuable to users.

[@ray89520]

I like to call them quality attributes or quality requirements because it reflects what we used from real products: quality is associated to the whole thing, not to an individual part. Additionally, I have never seen a client who said: I don't care at all about quality. Not all quality aspects are equal relevant, but that's fine and absolutely important to know, which aspects need our attention and which not.

[@matterexplorer]

If a quality-argument doesn't work, I've made good experiences calling the requirements you can't live without "hygiene-factors". The two-factor theory seems to be taught in business classes, so it helps get the point across (although it's somewhat different than NFRs)

[@BarjanTube]

Second time I hear this remark against the naming of these requirements this week. Maybe I missed it, but what the suggestion of naming them? Scott Moore mentioned operational requirements, but I doubt that covers it for all quality characteristics. In our performance engineering environment we simply use performance requirements, but that clearly doesn't cover others as well and honestly they suffer the same fate as mentioned for NFRs. Interesting topic to further discuss and find a new standard for.

[@anishcheriyan8673]

May be we can call Common Functional Requirements-CFR

[@stnhld2841]

Non-functional Requirements = Business didn’t properly defined the requirements Scope creep = Business ignored inconveniences to make the next one look good Over budget = See above and “budgets are like promises, like pie crusts, made to be broken”

[@fredhair]

Don't agree with you on everything Dave obviously but you're spot on about this. The first time I heard the term 'non functional requirements' I said.. these are functional requirements. What it means to a lot of teams is.. we hope that our software also fulfils these things but it's not what we're concentrating on.

[@PauloCardosoAguiar]

Always brilliant!

[@patt4876]

You should look into the Quality Attribute concept of SEI. What you say reflects in their Software Architecture in Practice.

[@branislav3800]

This terminology is mostly for not technical people working on a project, to let them know there are other requirements that need to be fulfilled, other than the features they want implemented.

[@Supreme_Lobster]

After many years I still have no idea what thw difference between functional and non-functional requirements is. Like, it's just requirements. What purpose does it serve to separate some requirements from others? In my experience, none. Requirements are requirements

[@draufunddran]

Hello Dave, i really like your videos and i'm a long time subscriber, but i find it really hard to understand you because of the echo or noise or whatever it is that's wrong with your sound. I find myself often not finishing your videos, and first i thought its because of the difficult topics, but I think a big part of it is also the poor sound quality. If i watch other video on the Tube with better audio, i usually stay longer ever on a difficult topic. Sorry for the rant, but maybe others have the same problem/feeling and it might help your channel.

[@evolagenda]

Thank you

[@dominikvonlavante6113]

I have only one NFR: have a functional CI/CD pipeline. Everything else becomes irrelevant after that if you use good software architecture of loosely coupled stateless systems.

[@thatsabug]

05:12 - Only if developers would put the same linguistic effort and importance when judging the term "automated testing" in the light of what testers actually do. For more info, see James Bach article: Testing 3.0

[@ArtemYakovlev]

Thanks

[@edwardcullen1739]

Hi, I came to the same conclusion about a year ago, but have real problems expressing myself. NFRs are a hangover from the early days of Software Engineering, which was copied by academics from other fields of engineering. As we're maturing as a discipline, this kind of thing is becoming clearer. Everything that the system must do is a requirement. There are no distinctions beyond this. I split it into _standards_ and _requirements._ Standards are the things that cut across and _inform_ requirements, but don't necessarily directly translate into 1:1 into requirements. I'd love to talk to you about NATIVE.

[@jimmyhirr5773]

What does the acronym NATIVE stand for?

[@edwardcullen1739]

@@jimmyhirr5773 Hey, can't expect me to give the game away 😉

[@alexanderpodkopaev6691]

Separating functional and non-functional requirements is indeed stupid. On a training I am used to ask to separate requirements to functional and non-functional for any ordinary thing like a cofee cup. Or a wheel. Or a chair. It's really funny to observe the process.

[@Aleks-fp1kq]

I didn't really understand his idea on Modeling 8:52 and deferring the details of "non-functional requirements". As in, how to avoid considering "non-functional requirements" for every functional requirement. How about you?

[@haxwithaxe]

I guess I've been lucky but I'd never heard of "non-functional requirements". Everywhere I've worked has just had "requirements" and we built things with all the relevant requirements in mind (or written in my notebook so I don't have to remember all of them at once).

[@spuzzdawg]

I feel like this is an symptom of the IT/DevOps/Software Engineering fields developing in parallel to the field of Systems Engineering with limited cross polination between fields. In my experience, this is a solved issue in systems engineering, which might categorise requirements as functional, performance, safety etc. but doesnt use that category to define requirement importance.

[@username7763]

I always thought non-functional requirements were the most important when it comes to understanding project scope. It is unfortunate that people are seeing it the wrong way. There was a special category for them so they wouldn't be forgotten.

[@InterdimensionalWiz]

so many programmers these days dont Test their software, simple things like 'cancel and Next buttons, off the screen, non scrollable! you tube has stuff like this, these new small videos, click on comments and a corner of a window pops up, the rest is off screen and has no comments. ive told you tube but they, like most companies....just dont care!

[@petersuvara]

Remind me to link this to the wiki page a reference to the criticism of “non-functional requirements”.

[@etherweb6796]

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.

[@Kreadus005]

Usability. Time efficiency of user tasks. Its a NFR. The service could respond in so many milliseconds, but if its designed in such a way that the USER fumbles and takes 10-minutes of error prone data entry... then the NFR could be defined for that task to take only 2-3 minutes. They're qualitative indicators that are hard to translate into quantitative, or even if they are quantitative, the business isn't exactly sure how to phrase the monkey's paw wish.

[@rolemodel99]

So can we rename NFRs as Operational requirements / Operational / Developmental Capabilities?

[@ContinuousDelivery]

I think that they are just "requirements". If I implement a "press this button and X happens" kind of requirement, then I expect that to remain true, and working, whatever else changes. If I implement an "achieve 99.999% uptime" retirement, I also expect that to keep being true whatever else changes. Where is the difference? I not sure that we learn anything useful from treating these things differently from one another.

[@Mrgreatestfreakout]

Literally the best video ever

[@MatthewRees7]

My preferred term is quality attributes

[@zbaktube]

What do you think about this definitions: "Functional requirements the one that generates income" and "non-functional requirements": are the ones that makes customer happy to stick with your product? Of-course, if you monetise your app.

[@ContinuousDelivery]

I don't agree with that, you don't "generate income" if your system is down. Your customer isn't happy if the system doesn't do something useful. My argument is less about the words we use to differentiate between these two things, but rather, in my view, the recognition that there aren't "two things". They are all requirements, it is only that one is difficult to estimate and the other is easier to estimate. I am not sure that I see another difference.

[@zbaktube]

@@ContinuousDelivery I meant you can generate income, if you sell. So, if you prove in a demo environment the usefulness of your service (even if behind the scenes only a secretary types the answers, what of course the potential client cannot see), you sell and generate income. But, if your client realises your service is not reliable (the secretary too grumpy before the first coffee, and cannot keep up with the requests) then the client just wont stick, and you have just lost your paying client. So the first group of requirements responsible for the usefulness, and the second is responsible for quality/usability in your business. And these two together gives you the business value.

[@ContinuousDelivery]

@@zbaktube I think that I understand you point, I just think that a user will be grumpy either way, so it doesn't seem to me to be a defining characteristic. I am probably being too pedantic here, I agree that in some, maybe most, cases, your distinction makes some sense. My reason for being pedantic though, is that I think that trying to make this distinction is only reinforcing bad ideas from project management, rather than helping us to face up to the complexities of real-world software development. The "non-functional" stuff is usually the difficult parts, and by compartmentalising this off, through nomenclature, we are in danger of marginalising it, at least for people who aren't thoughtful about software dev.

[@victorian1707]

Dope shirt.

[@alexandrucaraus233]

"The page isn’t redirecting properly" after clicking download the guide.

[@TheEvertw]

The importance of "NFR's" is huge. They determine all our design choices. If you disagree, consider this: we can program any functional requirement in Assembly Language. But we don't. Because of NFR's.

[@philipoakley5498]

"*Null* functional requirements" - Environmental non/null/no influences. Yes they are very badly explained and contrary to human cognition that loves positive 'success oriented' actions. A major issue is the problem of attempting to make predictions about what influences may affect the 'undisturbed' output measure.

[@FlaviusAspra]

So Dave, are you a mac user? BR

[@m.muzinski7842]

Cross functional requirements! This is the term!

[@HughCStevenson1]

Just write a story to make the response < 5 ms... :) Ha ha!

[@esra_erimez]

Are Non-Functional Requirements distinct from Supplemental Requirements?

[@sasukesarutobi3862]

It depends what you mean by "Supplemental Requirements", but if it's things like system performance and reliability, then it sounds like pretty much the same thing and with the same naming problem: it makes them sound like aspirations and "nice-to-haves" rather than hugely important requirements in their own right.

[@chat-1978]

Though at the end, i guess you find the requirements important, i disagree on some aspects because they the most important requirements with the least attention given to them. So my remarks are: 1. The examples are very one sided. Rto, RPO are non functional requirements. CTO or someone should define a couple of basic rules that are non negotiable. e.g. only open source. It's not the same i know but they do fall under the general bucket that is not functionality which brings me to 2ndv point 2. In most groups, there is a business analyst and or a functional requirements. Even ux guys focus only on the function and the rest is boring. But those boring stuff is what makes everything work. Add to that that modern day developers have no clue where there code executes and how they don't care about those aspects. Regardless of the naming, there are rules and requiments that don't need to be repeated on every other functional description. It makes the discussion easier, no room for interpretation and wiggle room. Their commonality make then the most important requirements. I guess the non part makes them indifferent. But in either case, historically they were the least understood requirements. All the major blunders I've seen in my life are because of them being ignored if they exist at all.

[@paulosullivan3472]

Okay so you dont like the term "non-functional". I must admit it seems like semantics to me but I didnt catch what you actually think it should be renamed too? NFR's are a well known term so while I dont disagree with what you have said in the video I dont see what term would be sufficiently better to replace an NFR?

[@KristoVaher]

This is why they should not be "non-functional". The tech requirements should be "cross-functional", as in you should have no tech requirement with no relation to business. But others are fine and actually important.

[@joaopauloleonidasfernandes5884]

Cross-functional requirements or CFRs.

[@mikkolukas]

The background whoosh-sounds (when graphics move in and out or you change position) are distracting in the video, and can seem "cheap". It worked much better in earlier videos without those sounds.

[@hoagy_ytfc]

0:57 Objective-C? In 2023?!

[@ContinuousDelivery]

I am not a big fan of "Quality Attributes" either, it too is a meaningless phrase, designed, I assume, too hide the complexities of software development away from those sensitive souls, the project managers. Well tough! Software is a complex thing to do well, get over it and recognise that some valuable features of the system don't easily fit into a pigeon-hole, and take more work, organised differently. And this work is cross-cutting, on-going and hard to plan. But "plan-ability" isn't the goal, good software is the goal. Just my 2c! 😉

[@a314]

We should stop calling Non functional requirements. We should call them operational requirements instead!

[@gediminasmorkys3589]

Holy click bait, Batman!

Non-functional requirement means a requirement without which the system will not function.

[@r_j_p_]

So, NFRs are not stupid - Dave is objecting to the name "non-functional". I concur, if only because people struggle with understanding what it means to them. NFRs are characterized by requiring continuous testing. NFRs are never "one and done" like functional requirements. Consider the impact on work tracking. If you're using an issue tracking system to track all of your user stories, how can you enter a user story for "system is secure?". When would you mark the story as "complete"? The answer is that you cannot. This is not a deficiency in NFRs - it is a deficiency in how we track work. So, let's change how we track work that must be done continuously. Hmm. Sounds like something Dave has written about before... continuous something...

[@Tiriondil]

I disagree on your take of non-functional requirements. They don't consist necessarily of complicated problems all over the project. I give you some pretty easy and standard examples for non-functional requirements: For a GPS system in a car, I had once the requirement: "The german voice shall be read by Mrs Whatshername." Yes, this is a requirement, and yes, this must be mentioned in the requirements, but this has nothing to do with functionality whatsoever. Grinning I imagined my testers calling this woman on the phone for every new software release and she going crazy over this, thus I classified this requirement as "not testable". Other examples: "The display shall have 80 characters in 40 rows" "The background of this textbox shall be black, the letters shall appear in white on it" "The device shall be cased in a metal box." "The available colors shall be red and blue." and so forth. Basically everything that deals with design or style is non-functional.

[@DinHamburg]

"The system shall provide clear and easy to understand error-messages"

[@Tiriondil]

@@DinHamburg Yep, this is another one. Practically every styleguide which is to follow is also non-functional. One might debate if the error messages are part of styleguides.

[@username7763]

@@DinHamburgI've had not such a good time trying to meet this requirement when the system didn't have a clue what went wrong. PM wanted us to tell the user if the network device wasn't connected, wasn't functioning, was busy, was misconfigured and so on. Yeah that'd be great if we could, but all we know is it didn't respond.

[@username7763]

I've always understood this as acceptance criteria or even as examples. There can be a requirement hiding behind it. Often-times getting someone to tell you what the damned need is will make you go crazy. e.g. why back background with white text? could be a high-contrast or readability requirement, could be a branding color requirement, could be a government regulation, could be an executive wanted to feel important. But you do need to know the real requirement behind it as engineering needs to be able to make trade-offs. If it is a branding color requirement, we might need to use a display available in multiple colors in the case of the inevitable re-branding. If it is contrast, maybe there are other properties of the display that also help contrast that should be considered.

[@Kostrytskyy]

Bitter... The pun was not intended, right? :)

[@hexchad765]

I'm not convinced that arguing about the meanings of words is important

[@testingcoder]

After wathcing 2 minutes of the video I really believe that author misses the point and makes an argument on the e false premise that "non-functional requirements" are "not important" or "not mandatory". Destinction between "functional" and "non functional" requirements is mostly about how one can verify those (if it all possible). There's no "hierarchy" of requirements. For example "durability" is extremely difficult to verify on the unit-test level. It is also not something I'd suggest having an automated test for (in this context by "automated" I mean "part of the pipeline", which isn't the best usage of the word, but still). May be author makes some valid points later in the video but I just could not bear watching it that long - as I believe that examples "how would users react if payment software leaks user data" are completely out of place and have no relevance to "non-functional requirements" term at all.

[@riccardo-964]

Functional = Features Non-Functional = Quality I don't see why not differentiate just as we do... For the first time I disagree with Farley.

[@chh4516]

I'm sorry Dave - half of your video I had my jaw wide open because I couldn't believe what you said. The second half was alright, but I think you completely missed the point on FR and NFR. Why didn't you read on in the wiki article? Next sentence: "They are contrasted with functional requirements that define specific behavior". Is reacting in one millisecond a specific behaviour? Of course! Your example doesn't fit at all!! The same goes with the security aspect. That too is a very functional requirement. But read on! "The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements". NFR is architecture! So an NFR would be "you have to use this particular programming laguage or this framework" if others would suffice to do the job. Let me give you an example. My team and I built a messaging system. The client wanted a particula middleware system. That system is a complete sh***show and is responsible for 99% of our bugs and could easiliy be replaced by a single class... but NO, Mr Moneyprovider wants that thing. That is an NFR and by GOD I HATE IT!!

[@errrzarrr]

Say no to non-functional requirements? Oh lord what's next? _Say no to car brakes? Say no to higiene?_ The only way I could agree with this is if you say _non-functional_ is a dumb term because they are what makes your product to actually function and therefore _quality requirements_ is the proper name. _Qualitt requirements_ are like the higiene of your system, the brakes of a fast car.

[@ContinuousDelivery]

Well I guess you never watched the video, because that is almost exactly what I am saying.

[@C00637]

I hate that I fell for this bait. Thankfully, you can mute channels nowadays.

[@ThomasLunsford]

It's pretty frustrating to keep seeing these clickbait arguments over wording without viable replacement terminology. Maybe put some effort into tackling "CD". Rather than continuing to propagate the mess of CD vs CD, please consider changing to SOMETHING OTHER THAN "D". It's hard to change from catchy phrasing now isn't it?