1.9 Introduction to Non-Functional Attributes

IT infrastructures provide services to applications. Some of these infrastructure services can be well defined as a function, like providing disk space, or routing network messages. Non-functional attributes, on the other hand, describe the qualitative behavior of a system, rather than specific functionalities. Some examples of non-functional attributes are 

• Availability

• Scalability

• Reliability

• Stability

• Testability

• Recoverability

In my experience, the most important non-functional attributes for most IT infrastructures are security, performance, and availability.

Non-functional attributes are very important for the successful implementation and use of an IT infrastructure, but in projects, they rarely get the same attention as the functional services.

There is much confusion about the value of pursuing non-functional attributes. The name suggests they have no function. But of course, these attributes do have a function in the business process, and usually a fairly large one. For instance, when the infrastructure of a corporate website is not performing well, the visitors of the website will leave, which has a direct financial impact on the business. When credit card transactions are not stored in a secure way in the infrastructure, and as a result leak to hackers, the organization that stored the credit card data will have a lot of explaining to do to their customers.

So, non-functional attributes are very functional indeed, but they are not directly related to the primary functionalities of a system. Instead of using the term non-functional attribute, it would be much better to use the term quality attributes. While this term much better represents the nature and importance of, for instance, performance, security, and availability, the term non-functional attribute (as expressed in non-functional requirements or NFRs) is more frequently used and widely known. Therefore, in this book I keep on using the term non-functional attribute, although I do realize that the term could be misleading.

While architects and certainly infrastructure specialists are typically very aware of the importance of non-functional attributes of their infrastructure, many other stakeholders may not have the same feelings about them. Users normally think of functionalities, while non-functional attributes are considered a hygiene factor and taken for granted (“of course, the system must perform well”). Users of systems most of the time don’t state non-functional attributes explicitly, but they do have expectations about them.

An example is the functionality of a car.

A car has to bring you from A to B, but many quality attributes are taken for granted.

For instance, the car has to be safe to drive in (leading to the implementation of anti-lock brakes, air bags, and safety belts) and reliable (the car should not break down every day), and the car must adhere to certain industry standards (the gas pedal must be the right-most pedal).

All of these extras cost money and might complicate the design, construction, and maintenance of the car. While all clients have these non-functional requirements, they are almost never expressed as such when people are ordering a new car.