Last updated on December 9th, 2022 at 02:54 am

The following resources will help you to build a solid understanding of the quality attributes and how to use them to make better architecture decisions.


Imagine you are buying a car. What essential features do you need in it? A vehicle should deliver a person from point A to point B. But we also check on safety, Comfort, Maintainability, Ease of repair, or better mileage.

Similarly, just like a car, motorcycle, or House, the software has its non-functional requirements called “Architectural Characteristics.” Whether a website, a mobile or a desktop app, it should have a set of quality attributes to meet end-user needs.

One of the mistakes that new architects make is underrating the effect of the quality attributes on the architecture decisions. They don’t capture the quality attributes at all or much later in the project, and when they do, they only dedicate a short time and put less effort into accomplishing this critical task. Probably, the reason is that the quality attributes are vaguely understood and poorly specified.

In software engineering, a tight relationship exists between non-functional requirements (NFRs) and software architectures (SAs). As early as 1994, Rick Kazman and Len Bass asserted that SA is intimately connected to non-functional requirement (NFR) achievement. This idea has pervaded software development over the years and explains why development projects invest a lot into fulfilling NFRs.


Business users and architects must use a common language to communicate business goals and objectives properly. However, architects talk in “-ilities” or non-functional quality attributes, and business users speak regarding business needs. Using these two languages leads to confusion and, ultimately, business goals that are not met by the architecture. In this lesson, Mark Richards answers a question from a software architecture training class – how does an architect translate non-functional quality attributes (“-ilities”) to business users?

Architecture characteristics – otherwise known as “ilities,” non-functional requirements, and system quality attributes – define the qualities an architecture must support, whether it be performance, scalability, reliability, etc. They form the basis for selecting the right architecture style and analyzing tradeoffs to make architecture decisions. In this lesson, Mark Richards answers some of the questions he frequently gets regarding architecture characteristics.

Rob Wojcik describes the Quality Attribute Workshop as a scenario-based approach for eliciting requirements for quality attributes (non-functional system qualities such as performance, availability, and security).


I strongly recommend the following two books:

About the Author

My name is Adel Ghlamallah and I’m an architect and a java developer.

View Articles