**2. Software architecture: it's all about non-functional requirements**

Software requirements, as defined by the IEEE [8], are "a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document." As we can see, no explicit mention is made as of the *character* of the said condition or capability. Traditionally, the software industry showed a tendency to focus on functional requirements, which are defined as combinations of behaviors between inputs and outputs [9]. Requirement elicitation and other software development and software life cycle management practices provided support for functional requirements in terms of formalisms like use cases, user stories, etc. The focus was on *what* software had to do, rather on *how* it was supposed to do it.

It is the definition of software architecture as a critical part of the software development process [10] which brings attention to non-functional requirements. Non-functional requirements (sometimes referred to as "quality requirements") are defined as criteria to be used to judge the operation of the system, rather than specific behaviors. It is this system-wide relevance that makes most non-functional requirements *architecturally significant* [11], since they impose constraints on the

## *Software Design for Success DOI: http://dx.doi.org/10.5772/intechopen.86538*

design or implementation. **Figure 1** shows a common taxonomy of non-functional requirements.

However, we are still failing to systematically build a software that is a success, at least in the terms we were discussing in the previous section. Both what things our systems do and how they do them reveal those omissions, biases, and plain discrimination we would very much like to eradicate.

From the software architecture perspective, this is because **Figure 1** shows a very narrow view of non-functional requirements. Compare this with **Figure 2**, which presents a more exhaustive relation of parameters of interest for any software application.

In the following subsections, we will traverse the taxonomy in **Figure 2** that extends that of **Figure 1** beyond the shadowed area, to provide insights on what might be missing from our products if we overlook them.
