**2.1 Revisiting product requirements**

The fact that product-focused non-functional requirements have received more attention than the rest of the extended taxonomy of non-functional requirements shown in **Figure 2** does not mean they cannot and should not be revisited under the "societal success" mindset. We now see how.

*Usability*. In software engineering, usability is meant to quantify the quality of user experience and as such is typically described in terms of effectiveness (i.e., number of goals that can be achieved using the software) and efficiency (i.e., time required to complete said goals), alongside with other less objective parameters such as

**Figure 1.**

*Traditional taxonomy of non-functional requirements.*

**Figure 2.** *Extended taxonomy of non-functional requirements.*

satisfaction or perceived elegance. Usability should, however, be measured for different types of users, instead of a "regular user" or "normal user," which is often the case. The recommendation here is to look beyond our idea of typical user and consider the widest user base possible, featuring users with different levels of acquaintance with technology, from different age ranges, and health conditions (including transitory states such as pregnancy) and identifying with different gender options, with different socioeconomic backgrounds, and different sensor, motor, and mental skills.

*Performance*. Although different meanings can be associated with the term, the most common one is that of software responsiveness and is usually quantified in terms of requests or actions per unit of time. There are different and well-known approaches to controlling performance: from resource demand management (i.e., adjusting the ratios at which a component or subsystem generates events or polls or the context for information, explicitly limiting execution time, etc.) and resource arbitration (i.e., fixed or dynamic priorities) to its effective management (i.e., exploiting concurrency, duplicating data, or processes). Performance should, however, also take into account the consequences of these well-known strategies beyond the improvement or preservation of certain response times. When such response times have a human user at the other end, all the same we ought to take into account their expectations and perceptions of responsiveness. In this case, these can vary widely, providing further chances for improvement by alleviating the performance demands in some cases, which can be advantageously used to tend to other user profiles. Additionally, the consequences of performance degradation should also be contemplated under the light of the people that would suffer them, since depending on the kind of service we are providing and to whom, it might be more or less critical to comply.

*Resource consumption*. Similar to performance, resource consumption (be it computing power, volatile or nonvolatile storage, network access, bandwidth, etc.) has two sides to it. Whenever our system or software product needs to preserve resources and we aim to optimize them, unexpected consequences on the widest possible use base should be scrutinized. It is more likely that the problem is the reverse, since it is when we increase the demand for resources (or simply do not limit them) that we are more likely to implicitly exclude sectors of the population which might not have access to them. But in the context of excess of energy consumption that surrounds us, to which the prevalence of technology is no foreign actor (rather the contrary), every system and software should be as energy-aware as possible. Treating resources as unlimited is never a good idea, and it is not socially responsible either.

*Availability*. The most commonly understood definition of availability in the context of software engineering is the proportion of time a system or application is in a functioning condition, that is to say, capable of providing to its users the answer or services it is meant to, within acceptable conditions (i.e., usability, performance). The definition of this non-functional requirement makes sense considering that error-free software is virtually nonexistent. When we assume there will be errors, we need to define to which extent the presence of this errors can or will affect the normal operation of the system. For some systems, it is okay to be down for a few minutes, hours, or even days (if it is, e.g., software used in a factory which is down during the weekend). How flexible we can be about availability with regard to our software product depends on both the expectations of the users about it and the consequences of violating those expectations. In some cases, not being available might mean the users will turn to use our competitors' product instead (with the risk of not coming back); in others, it might affect their lives, threaten their security, or putting them on harm's way. Once more, we need to consider the broad population when leveraging said expectations and not only our "normal user."

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

*Fault tolerance*. Closely related to availability, fault tolerance is the capability of operating properly in the event of (internal) failure(s). The term usually helps us to stress that availability is not a black vs. white kind of situation, since the operating quality (i.e., performance, resource consumption) of a system might decrease proportionally to the severity of the failure(s). When we design for success with fault tolerance in mind, we aim to avoid that no undiscovered error in the software should be able to cause a total breakdown. With regard to societal success, the same considerations as with general availability apply.

*Safety*. Of course we never mean for our software to pose a risk to its users nor actively nor as a consequence of malfunctioning or unavailability, but actively considering this possibility during the whole development process involves considering safety as one of its requirements. Formally, however, safety includes not only not harming (no matter how severely) people but also goods and/or the environment [12, 13]. In a way, this links back to resource consumption in the energy-awareness aspect that we mentioned before. We could even argue whether introducing new technology where it does not bring societal progress, just for the sake of it, is not *safe*, since the environmental impact of the volume of technology we consume is already too high [14, 15]. Better approaches would always involve reusing or repurposing already existing technology, which is also less likely to exclude less privileged groups of population.

*Security*. Admittedly one of the major challenges in software engineering nowadays, we can informally define security as the resistance of a system or application to unauthorized uses, while operation is still granted for legitimate ones. There are several aspects of this claim that might be jeopardized if the diversity of the population is not properly accounted for, the most important of which would be to wrongly classify a legitimate request for an unauthorized one [16, 17].

### **2.2 Refocusing organization requirements**

In the previous subsection we have gone over the "classical" non-functional requirements that we have more specifically labeled as product non-functional requirements. There are two more categories of non-functional requirements to consider, one of them being those non-functional requirements derived from our organization. We discuss them next.

*Business context*. Whether our organization is a startup, fast-growing spin-off, an enterprise with sustained trajectory, or a business in trouble has a big influence on the goals, value, and time-to-market elements that define success in traditional terms. From this lens, a critical look is also needed, in order to detect room for improvement within. In this case, we think in terms of the people who form our teams, their profiles, and the roles they play. And, different from what we have seen in the previous section, we aim not only to reflect societal diversity, but we should strive to improve it in terms of equality and representation. Diverse teams and people from unrepresented groups in positions of decision-making and power can be our most strategic business advantage.

*Operational*. How and why we organize the internal functioning of our organization will have an impact in our products and their quality. Identifying the essential capabilities (or lack thereof), performance measures, and actions to be taken for improvement cannot be done without explicitly accounting for diversity and worklife balance, which in turn are key to workplace satisfaction and commitment. If so, we risk coding into the so-called "company culture" a set of barriers for employees that "are not the norm." But why, if we have agreed there is not one "normal user," should we assume there is one "normal employee"? The answer is easy: we should definitely not.

*Development*. Among the different product development methodologies and life cycles that have been defined in software engineering, there is arguably no silver bullet. It is more a matter of finding the most suitable match between product requirements, business needs, and operational structure. When referring to the literature on software development, this is often remarked as being the case, but then we straightaway proceed to talk about iterations, sprints, stakeholders, minimum viable products, etc. without ever relating these concepts to the composition of our development teams. Software products are made by people and same as shoes or clothing, hardly ever one size fits all. In other words, the best software development approach will be that in which all of our diverse (see operational requirements) development team can be most productive at.

#### **2.3 Advancing external requirements**

In this last section of this chapter, we turn to external factors. We do this because none of us technology makers live in the vacuum, and our actions are subjected to societal norms and laws and in turn influence how societal norms and laws evolve. This means we share a double responsibility: on the one hand, diligently complying with the former, and on the other hand, challenging the status quo when it is necessary and advancing it.

*Standards*. Whether they dictate norms, conventions or requirements for data format, storage or exchange, or for service provision, interfacing, or requirements, standards play a fundamental role in software interoperation, especially if they are internationally recognized and publicly available (i.e., open). As software creators, we are responsible not only for being aware of which standards affect the areas we are deploying our software on and/or the activities it provides support to. What is more, implication of software agents of all sizes, small included, in standardization processes, is very much needed in a world in which, more often than not, conventions are imposed by big players or agreed upon among few of them behind closed doors. Paradoxically, non-functional product requirements are not usually enforced for standards themselves, which have a reputation for lacking usability, for instance. When referring to executable or interactive elements, standards or standardization efforts should always be accompanied by software tests. Implementing tests for standard specifications is a way of disambiguating them and stress-testing them. And of course, whenever a standard features or refers to any aspect of what a persona is, the assumptions that may be underlying need to be contrasted against the widest definition possible.

*Ethical*. When we discussed safety, we mentioned that introducing new technology just for the sake of it could not be considered *safe*. Hence, nor can it be considered *ethical*, we add now. More and more it is the case that CS studies feature courses that introduce future professionals to the concepts of professional ethics in the context of technology and software. However, many universities and academic institutions still do not offer them, and it is not reasonable to assume that every professional involved in technology and software creation has or will have a university background. The lack of a universal ethics, so to speak, is likely to make this the most subjective and controversial non-functional requirement of all. However, it is undeniable that we cannot look at software as a mere tool anymore, but rather a piece of technology that embodies the ethical commitments of those who make it and those who decide it should be made and used. The ethical aspects surrounding software products have two aspects to them: (a) whether the development of the product itself is contextually right or wrong or (b) whether the development of the product significantly affects the life or balance of power of or between individuals. Focusing on the latter case, we here advocate once more for a holistic approach to

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

what individuals we bear in mind when analyzing the issue. As for the former, there are two main perspectives: (a) use software in particular, and technology in general, to eliminate or reduce suffering and maximize well-being and happiness for the greatest number of people and (b) use software in particular, and technology in general, to follow society's universal rules. The first, however, poses a great opportunity that the second misses: the chance to challenge the status quo and advance society's rules themselves, by pursuing the common and greater good. Paraphrasing a renowned Sci-Fi series, "the need of the many outweigh the need of the few," but the need of the few cannot be consistently overlooked: that's the way minorities are forever discriminated. Our non-functional ethic requirements need to address whether our software is *right*, but also whether it is *just* and *fair*.

*Financial regulations*. The prevalence of technology, when applied to software that runs as a service, means that we might be providing services to an international use base before we actually give some thoughts to the financial implications of this in terms of tax declarations, client rights, anti-monopoly legislation, etc. These are much specific issues than those of ethical non-functional requirements but still need us to explicitly identify and decide how to take care of them, from the different possibilities that we might have before us.

*Security regulations*. In line with the financial non-functional requirements, user-privacy and user-data preservation laws might affect our software products regardless of whether we operate beyond the scope of a single country or not. Furthermore, cybersecurity and privacy awareness is on the rise, so the context and actual rules we might need to oblige to or enforce are subjected to far greater dynamism that those of financial nature. This needs to be considered in terms of maintenance and product life.
