One thing I’ve noticed over the last few years working in software development is that I really do not like the phrase “non-functional requirements”, which seem to often be called out separately from “functional” requirements.

To me, the phrase gives out the wrong vibes:

  • It’s pretty straightforward to make something non-functional
  • Usually, the focus is only on page load times, which is certainly part of the process but there need to be other considerations
  • There’s often an implication that they are somehow not core to the product or experience; that they are somehow nice to have, and liable to be the first thing cut from scope

I generally much prefer the idea of “Operating Requirements” - these might be parameter-based, regulatory, or documentary, but they are clearly a key part of the requirements.

  • Performance with specific bounds and expectations - a single breach of a p90 target might not result in a critical incident, but consistent breaching of the p90 target would
  • Accessibility - clearly this could be driven by legislation as well as just general usability
  • Regulatory - any other legislation or regulatory conditions that must be met
  • Support - any tools that might be used to support the feature or capability (e.g., manual cache invalidation)
  • Documentation, especially for a new capability, whether that’s customer facing docs, internal customer support documentation, a playbook for how the new capability works, and so on

In fact, I wonder if it’s just the fact these are treated separately at all, rather than as part of a cohesive and complete set of requirements, that I find frustrating.