There’s a ongoing debate about non-functional requirements: Non-Functional Requirements Are Not Nonsense and it’s a debate I’ve had within my teams as well.
In most consulting projects I’ve seen, non-functional requirements are listed as a nice to have, rather than a must have. It’s not a matter of business logic vs. performance either. In one rare exception, I’ve had a requirement for an import function to load and validate millions of records within a 48 hour period. If the import wasn’t correct and wasn’t fast enough, the requirement was not met. We made it with room to spare.
I think one of the key problems developers have with non-functional requirements is that they aren’t tasks to be achieved then ticked off, they’re cross cutting concerns, and are often best effort, so don’t need to be 100% complete to be ready to ship. They can be continually refined.
This can be hard for binary developers to grasp. Tests pass or fail, requirements are complete or not. And in a pre-devops world, many of the factors affecting them are outside the control of the developers. You can’t have 99% uptime on a VM that’s off for 30 minutes a day to be backed up.
Good testers help to bridge the gap by turning an aspiration into a target. They hear the customer wants the website to be fast, and they write 95% of requests return in under 250ms. Browser compatibility goes in the test log, because “the current version of…” is a moving target.
Not that we pass responsibility for meeting the requirements from developers to testers, but we get the testers to turn something vague and system wide into something tangible and testable that the business owners and developers can agree on. After all, if it can’t be tested, there’s no way to measure of it’s done.
Most of all, it’s about explaining to business owners that an aspiration is not a requirement.