Software Quality Attributes ‘aka’ Non-Functional Requirements and their considerations
Quality attributes, in other words, non functional requirements have direct effect on the software architecture.
Studies indicates that systems are often redesigned and restructured not primarily due to functional deficiencies or the need for new features, but because the current system fails to meet performance expectations. Issues such as slowness, poor scalability to accommodate growing user numbers or data volume, and a system structure that complicates development, maintenance, or security frequently drive these changes.
You may have heard such complains,
- This is not fast enough
- It does not scale
- Development is slow
- Hard to maintain
- Not secure enough etc…
In most instances, after a major redesign, the system ends up delivering the same or very similar functionality as before. So architecting our system in a way that provides us with the right quality attributes right from the start is extremely important to avoid such major redesigns.
What are the quality attributes?
Quality attributes are nonfunctional requirements that describe the qualities of the system’s functional requirements, or the overall properties of the system. In other words, the quality attributes do not say what the system does, but instead they provide a quality measure on how well our system performs on a particular dimension.
The quality attributes have direct correlation with the architecture of the system.
Example 1
Online store where users can look for products based on some search keywords. So one general requirement may be that when a user clicks on a Search button after they typed in a particular search keywords, the user will be provided with a list of products within at most 100 milliseconds.
So the functional requirement is the action that our system takes when a user clicks on the Search button.
The quality attribute, in this case, in the performance dimension, describes how fast this action is to be performed.
Example 2
Online store has to be available to the users at least 99.9% of the time.
So in this case, this quality attribute is in the availability dimension.
Example 3
Quality attributes dont only need to satisfy the needs of the client, it should satisfy the quality requirements of the all stakeholders.
Development team can deploy a new version of our online store at least twice a week.
This describes how system performs in the deploya-bility dimension.
Considerations about quality attributes
Measurability & Testability
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.
Example 4
When a user clicks on the Buy button, the purchase confirmation must be displayed quickly to the user.
Now, if we design a system such that it displays the confirmation within 200 milliseconds.
Now, since we couldn’t measure what the word quickly really meant, we can’t know if 200 milliseconds is good or bad.
There is no single architecture that can provide all the quality attributes
If there was such and architecture, then everyone would use it for every system and software architecture job would not exist :)
The reason is obviously that certain quality attributes contradict with each other.
So some combinations of quality attributes are either very hard to achieve or are even impossible.
We have to make the right trade-off.
The job of the software architect is to make the right choice by evaluating trade-off. Prioritizing some quality attributes over the others and designing the system in a way that will give us the highest chance for success.
Example 5
We may have have two conflicting requirements for our system’s login page. One requirement states that a user should log in to our system very quickly, preferably under one second.
The other requirement tells us to provide security to protect the user’s account.
We have two contradicting quality attributes,
- Performance
- Security
That for the user to log in, they will need to type in some sort of password, and also, to protect that password, we need to use something like SSL, which is a technology that allows us to protect that password from being intercepted by a third party.
But making a user type in their username and password, and also making the network request using SSL, makes the login process slower, which goes directly against the first requirement to make the login process as fast as possible.
Feasibility of The Requirement
The third important consideration in regards to quality attributes, it’s the feasibility of their requirements. It is up to us, the designers of the system, to make sure that the system that we’re attempting to design and later build is even capable of delivering what the client is asking for.
In some cases, because the client is not technical, they may ask for something that is either technically impossible, or prohibitively expensive to implement, and it is the architects job to call that out early on in the process.
Example 6
One example of an unfeasible requirement is unrealistic low latency expectations. For example, if the network latency between a client in South America and the closest data center where we run our system in U.S. East, is anywhere between 100 or 150 milliseconds, then we cannot guarantee page loads to be less than 100 milliseconds.
Actually, we can’t even guarantee a latency close to that, because loading a page using HTTP requires multiple round trips as part of its protocol, as well as potentially loading multiple assets.
So, before approving a requirement, we may even need to consult with people with domain expertise to make sure that we can actually deliver on what we promise.
