A nonfunctional requirement constrains how an ML system must perform its function. A functional requirement might specify inputs and a recommendation as output; a nonfunctional requirement might require that recommendation to arrive in under 200 ms and cost less than $0.0001. These constraints help determine whether a promising solution is practical, not merely accurate. section 3.1 section 2.3.2
Capture operational constraints early, then make them explicit enough to test:
- Record required latency, throughput, memory footprint, execution cost, and carbon impact. Throughput is not interchangeable with latency: cold starts and parallel hardware can change how many requests a system handles over time. section 8.2.7
- For data resources, document nonfunctional properties such as scale, speed, and history alongside statistical and system properties. Obtain a sample to investigate what implementation may be feasible. section 2.4
- Put model constraints on the story card with its business purpose, data resources, intended use, and issues. Check that the output can actually be used in the business process. section 5.3
Test these requirements when selecting models. A model that passes functional tests may still be unsuitable if it is too slow, costly, or difficult to deploy. The needed standard also depends on the system: an autonomous system requires more robust nonfunctional performance because a person may be unable to intervene when it fails. section 8.2.7 section 9.2
Carry the requirements into production data flows, model serving, logging, monitoring, and alerting. Record operational events and choose monitoring density with both performance overhead and support needs in mind; excessive alerts can hide meaningful failures. section 9.11 section 9.5
