In traditional software engineering, criteria like usability are said to be“quality” requirements, that affect functional goals but cannot stand alone (Chung et al., 1999). For decades, these non-functional requirements (NFRs), or “-ilities”, were considered second class requirements. They defied categorization, except to be non-functional. How exactly they differed from functional goals was never made clear (Rosa et al., 2001), yet most modern systems have more lines of interface, error and network code than functional code, and increasingly fail for “unexpected” non-functional reasons (Cysneiros & Leite, 2002, p. 699).
The logic is that because NFRs such as reliability cannot exist without functionality, they are subordinate to it. Yet by the same logic, functionality is subordinate to reliability as it cannot exist without it, e.g. an unreliable car that will not start has no speed function, nor does a car that is stolen (low security), nor one that is too hard to drive (low usability).
NFRs not only modify performance but define it. In nature, functionality is not the only key to success, e.g. viruses with no ability to reproduce in themselves simply hijack this function from other cells. Functionality differs from the other system requirements only in being more obvious to us. It is really just one of many requirements. The distinction between functional and non-functional requirements is a bias, like seeing the sun going round the earth because we live on the earth. There is no difference at all between functional and non-functional requirements – they are all just requirements.