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.