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:

  1. performance: effort to compute output state(s) in shortest amount of time;
  2. performance: effort to compute output state(s) under a maximum-% processor load;
  3. scalability: capacity to practically support large workloads without undue ill effect;
  4. 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;
  5. reliability hours until failure, usually measured in arithmetic Mean of [usually thousands of] Hours Before Failure (MTBF);
  6. 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;
  7. 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.