Nonfunctional requirements are those expectations that a system must obey (or should obey, if objectives instead of requirements) that are not functionality of the system. Functionality of a system is a change of some input state(s) to different output state(s). Examples of nonfunctional requirements include nearly all of software architectural goals/qualities, as itemized in the expanded description below.
Example nonfunctional requirements include:
- performance: effort to compute output state(s) in shortest amount of time;
- performance: effort to compute output state(s) under a maximum-% processor load;
- scalability: capacity to practically support large workloads without undue ill effect;
- availability: percent of up-time of the system to perform its full set of intended functions without impairment observable by the user—often expressed in nines: 4 nines = 99.99% up-time or less than 52½ minutes of total downtime per year, 5 nines = 99.999% up-time or less than 5¼ minutes of total downtime per year;
- reliability hours until failure, usually measured in arithmetic Mean of [usually thousands of] Hours Before Failure (MTBF);
- repairability or recoverability: hours from onset of failure until full repair, usually measured in arithmetic Mean of [usually single-digit] Hours To Repair (MTTR), where the term repair is used more for human-intervention repairs whereas the term recover is used more for fully-automated recovery without human intervention;
- data integrity: percent of spurious or suspect or wrong data, especially in an analog system or a digital system that can be affected by analog effects (e.g., gamma rays, power fluctuations), but also digitized data that was vetted by statistical techniques instead of rigorous deterministic decision-making.
