Beyond Functionality: The Importance of System Quality Attributes
Systems are not redesigned or restructured due to functional deficiencies or new functionality requirements, but because the existing system cannot perform fast enough, scale effectively to accommodate growing numbers of users or data, or, even more commonly, the system is difficult to maintain or keep secure due to its structure.
After a major redesign, the system typically offers the same or equivalent functionality as before. Therefore, it’s crucial to avoid such major redesigns by designing the system architecture to meet the required quality attributes from the beginning, with a feasible, sustainable, and scalable solution. This is a significant part of our job as architects, and it can help to mitigate the complexity of the system and unnecessary cost.
In this article, we will delve into the quality attributes of a system, also known as nonfunctional requirements (NFR). These attributes, as mentioned, play a fundamental role in dictating the software architecture of our system and have a direct impact on the proposed software solution for our client.
Quality attributes are characteristics that define the overall behavior and performance of a system beyond its functional requirements. Rather than describing what the system does, quality attributes provide a measure of the system’s effectiveness in specific areas and they provide a quality measure on how well our system performs on a particular dimension.
To provide further clarity on the definition, let’s take an example of an online store where users can search for products based on specific keywords. One functional requirement for the system could be that when a user clicks on the search button after entering the keywords, the system should display a list of relevant products within 100 milliseconds. The quality attribute associated with this requirement would be performance, as it measures the speed at which the system can provide the search results. In other words, quality attributes provide a measure of how well a system performs on a specific dimension, while functional requirements describe what the system should do in response to user input or other events.
Another example of a quality attribute that is not tied to a specific functional requirement is the availability of our online store. Our system must be available to users at least 99.9% of the time, which is a measure of the system’s reliability (dimension). This demonstrates that quality attributes are not only driven by the needs of the client, but may also need to satisfy the quality requirements of all or a diverse variety of stakeholders involved in the project.
To illustrate this, let’s take another example of a quality attribute, which is the ability of our development team to deploy a new version of our online store at least twice a week. This property pertains to the deployability dimension, which describes how easily and frequently our system can be deployed with new updates or changes. This attribute not only affects the development team’s workflow but also has a direct impact on the overall performance and functionality of the system, as it allows for continuous improvement and adaptation to changing requirements and business needs.
Measurable and testable
One of the most important considerations about quality attributes is that they have to be measurable and testable. If we can’t objectively measure and consistently test to prove that our system satisfies the required quality attributes, then we can’t actually know if our system performs well or performs poorly in regards to that requirement.
Imagine this requirement:
“When the user clicks on the Buy button, the purchase confirmation must be displayed quickly to the user.”
We respond to this requirements designing a system that displays the buy confirmation within 200 milliseconds. Is it good or bad? Since we couldn’t measure what quickly really meant, we basically can’t know and measure our system performance.
No one can be perfect
The second important consideration is that it’s not possible to achieve all the quality attributes with a single architecture. If such an architecture existed, there would be no need for software architects. The reason for this is that some quality attributes are mutually exclusive and cannot coexist. For example, high security can be achieved at the expense of performance, while high performance can be achieved at the expense of scalability.
Thus, different combinations of quality attributes require different trade-offs, making it necessary to carefully select and prioritize the quality attributes that are most important to the system and that will give us the highest chance for success based on the requirements of the business.
For instance, consider the conflicting requirements for our system’s login page. One requirement specifies that a user should be able to log in quickly, ideally in less than a second. However, to ensure the security of user accounts, we need to implement measures like SSL to protect their passwords from third-party interception. These measures can slow down the login process, which conflicts with the first requirement to make it as fast as possible. Therefore, it is not always possible to satisfy all quality attributes simultaneously, as some may contradict each other.
The feasibility of quality attribute requirements is the third important consideration to keep in mind. As system designers, it is our responsibility to ensure that the system we are designing and building can deliver what the client is requesting. Sometimes, due to the client’s lack of technical expertise, they may ask for something that is technically impossible or too expensive to implement. Therefore, we need to identify and communicate these challenges early in the process to avoid over promising, delays and disappointment.
Is the requirement feasible?
One common example of an unfeasible requirement is setting unrealistic expectations for low latency. For instance, if the network latency between a client in Europe and the closest data center where we run our system in the US is around 100–150 milliseconds, it is not possible to guarantee page loads within 100 milliseconds or less. This is because loading a page using HTTP involves multiple round trips and may require loading various assets, making it difficult to achieve such low latency. As software designers, we must identify such unfeasible requirements and work with the client to set realistic and achievable goals that align with the capabilities of the system.
Another example of an unfeasible requirement is a demand for 100% availability of the system. Achieving 100% availability means the system can never fail, and we will never have the opportunity to take it down for maintenance or upgrades. This is not a realistic expectation as it is impossible to completely eliminate the possibility of failures due to hardware, software, network, or other issues. We can, however, aim for high availability by implementing redundancy, failover mechanisms, and other measures to minimize downtime and ensure quick recovery in case of failures.
Other examples of unfeasible requirements can be full protection against all possible hacking attempts: is not realistic, as there is always a possibility of new vulnerabilities being discovered. Similarly, streaming high-resolution movies in areas with low bandwidth or requiring the system to rapidly increase its storage capacity beyond what is currently feasible may not be possible
Conclusion
As architects, it’s our responsibility to communicate these limitations to our clients and work with them to find more feasible solutions that still meet their needs. To ensure that the requirements are feasible and achievable, it is crucial to consult with people who have domain expertise before approving them. These experts can provide valuable insights into the technical limitations and challenges that may arise during the development process. By doing so, we can avoid unrealistic or unattainable requirements that could cause delays, increased costs, or even project failure. Therefore, seeking the advice of domain experts can help ensure that we deliver high-quality software that meets the client’s needs within the constraints of the available resources and technical capabilities.
