Let’s continue investigating Software Architecture. We considered who is a Software Architect, what types of Software Architects exist and what the architect should do in the beginning of a project. When stakeholders are identified and requirements are collected, the question arises what to do next. After functional requirements are formulated — or the answer to the question “WHAT the system should do” is found, the software architect starts searching for the answer to the question “HOW the system should work”. Non-functional requirements help in that case.
Non-functional requirements (NFRs) define the criteria that are used to evaluate the whole system, but not for specific behavior, and are also called quality attributes and described in detail in architectural specifications.
All NFRs can be divided into two main categories:
A situation in which the system has the desired combination of quality attributes, for example, of usability and performance or reliability, shows the success of the architecture and the quality of the software. When designing to meet any requirements, it is important to consider the impact on other attributes and find compromises between requirements. Along with this, the value or priority of each individual attribute differs from system to system. This article covers not all existing attributes, but those covered can be a good start for designing your system.
To consider the types of quality attributes, we can use a diagram from ISO 25010:
Image 2. ISO/IEC FCD 25010 diagram
This standard describes the quality attributes for a software product. Next, we’ll look at what exactly each attribute means individually.
Performance shows the response of the system to performing certain actions for a certain period of time.
There are two ways how to measure performance:
In practice, the possible performance indicators include, for example:
you can find interesting latency numbers which every developer should know.
Performance issues very often grow into problems that can affect everything, from the server’s capacity or the ways in which you develop your front-end to the efficiency of database queries or the capacity of communication channels.
Performance is almost always included in the list of key quality attributes that need to be considered by the architect, since it affects the entire system and can affect many parts of the architectural solution. Therefore, on the internet, you can find a large number of examples of how to deal with performance problems.
Interoperability is an attribute of the system or part of the system that is responsible for its operation and the transmission of data and its exchange with other external systems. A well-designed system facilitates integration with third-party systems. To improve the interoperability, you can use well-designed external interfaces, standardization systems, etc.
Naturally, there are a lot of problems for interaction:
Interoperability cannot be ignored. In the best case, you will have to create additional layers for the interaction API. At worst, it will be necessary to rebuild the entire system.
Usability is one of the most important attributes, because, unlike in cases with other attributes, users can see directly how well this attribute of the system is worked out. One of the key problems of usability is too much interaction or too many actions necessary to accomplish a task. Incorrect sequences of steps in multistage interfaces are also a problem of usability. Data elements and controls may be designed not according to the accepted patterns of user experience, which also complicates the interaction. For example, if you are developing an iOS application, then it is important to use the guidelines from Apple, or the guidelines from Microsoft — for Windows desktop applications.
Examples of important indicators for this attribute are:
Reliability is an attribute of the system responsible for the ability to continue to operate under predefined conditions. Most often, the system fails due to the inaccessibility of external elements, such as databases, systems, and network connections.
Availability is part of reliability and is expressed as the ratio of the available system time to the total working time. Important indicators for this attribute are:
Availability is often expressed in the number of nines after the comma, that is nines of availability (hours / minutes / seconds):
For example, availability is one of the main criteria for tier-ranking of data centers in the USA.
Security is responsible for the ability of the system to reduce the likelihood of malicious or accidental actions as well as the possibility of theft or loss of information. There are a number of measures that are used to protect systems: authentication, encryption, audit, and others.
Examples of this attribute in the work of the system are:
Maintainability is the ability of the system to support changes. Changes can be related to new business requirements or correction of old errors and affect system components or separate methods. Also, maintainability affects the time needed to restore the system after a failure. Excessive dependencies between components have a very negative effect on maintainability. In programming, there is a notion of anti-pattern spaghetti code which means excessive coherence in the code. In architecture, there is no such thing, but architecture is very close to programming in this sense. It is because of the maintainability attribute that such concepts as separation of responsibility, microservice architectures, and modularity have appeared. At the same time, this attribute affects not only development processes, but also management processes (for example, splitting teams into product-related parts).
Modifiability determines how many common changes need to be made to the system to make changes to each individual item. Ideal is the case where each change affects only one element.
Testability shows how well the system allows performing tests, according to predefined criteria. In addition to testing performance, testability makes it possible to effectively divide the system into subsystems.
The main indicators for this attribute are:
There are other very important quality attributes which are not covered by the standard but cannot be ignored in this article.
Scalability is the ability of the system to handle load increases without decreasing performance, or the possibility to rapidly increase the load.
There are two ways to improve scalability:
The key indicators for measuring this attribute are:
And this is only a small part of the indicators which you need to follow when designing. Scalability is one of the most important attributes, no matter what stage the project is at.
Reusability is a chance of using a component or system in other components/systems with small or no change. Segregation of responsibilities, modularization, decreasing of copy-paste are all about reusability. Copying code, or worse, using different components for the same result in different modules, is one of the biggest problems of reusability.
Supportability is the ability of the system to provide useful information for identifying and solving problems. The main problems in ensuring supportability can be addressed with the following means:
Most often these are not considered in start-ups or small projects initially. The cost of maintaining the supportability attribute is high, and the result is only visible on a large scale. However, with the growth of the team and the product, this attribute becomes one of the key ones.
This article is divided into two parts. In the second part, let’s consider the approaches how to prioritize quality attributes and answer the question why it is so important to choose the right priorities.