Quality requirements in software architecture are not an independent category alongside functional requirements, but part of the same requirements space. ISO 25010 separates the two, but this boundary is blurred: many quality properties such as usability or security are ultimately implemented through functionality. Architectures should be built in such a way that both types of changes remain possible.
Key Takeaways
- The distinction between functional and quality requirements leads to a false hierarchy in practice: Functional requirements drive architectures just as much as all other properties.
- Quality requirements such as usability or security are ultimately implemented through functionality, for example through a password dialog or a screen reader, which dissolves the dividing line between the two categories.
- Quantitative requirements such as response times are often defined without a business case basis, which later leads to irresolvable conflicts with other constraints.
- An architecture that is designed for changeability at an early stage makes it possible to address quality characteristics when they actually come into focus, instead of having to make all decisions correctly in advance.
- The ISAQB Foundation Syllabus treats quality together with architecture assessment in a single chapter at the end, although the topic belongs at the beginning as a requirements basis.
Functional requirements and quality requirements are difficult to separate architecturally
From an architectural perspective, there is no fundamental difference in the treatment of functional requirements and other requirements. Both drive the design, both get messed up, both result in major consequential changes in bad architectures.
Michael Sperber, ISAQB trainer for basic software architecture training, takes a critical view of this blanket separation. In some parts of the community, functional requirements are considered hardly relevant to architecture, for example in a much-cited architecture book. For him, this view neither fits in with how most people do architecture nor with his own experience.
The distinction itself is blurred. A server is supposed to convert dollars into euros: that is a function. It should do this in ten milliseconds: that is a quality characteristic. But what if the system does something specific after the ten milliseconds have elapsed? This is again a function. It is often difficult to say whether this is functional or qualitative.
The fact that such allocation questions keep cropping up is itself an indication that the taxonomy has a problem.
What functional suitability in ISO 25010 really means
ISO 25010 is a quality model that divides the concept of quality into categories into which properties can be sorted. Opinions differ precisely on the functional suitability category.
Alexander Lorz reads the column like this: it says how well the functional requirements match what stakeholders need. For him, the functional requirements themselves are not underneath. Otherwise, this box would become a giant compartment in which it feels like half of all requirements end up, and the model would become skewed.
Michael sees it differently. For him, functionality is of course one of the characteristics of a system. Anyone who understands quality as a synonym for property does not exclude functionality. The previous standard simply called the column Functionality. A member of the standardization committee with whom he spoke confirmed that the functional requirements are located below this, the wording is just so confusing that everyone interprets something different.
At this point, both agreed on “we agree to disagree”. What is more important in practical terms is the insight behind this: you can argue endlessly about a small question without the answer changing the implementation.
Quality requirements fly under the radar for many stakeholders
Anyone who builds information systems talks to customers about functions: about processes that the system should support. All too rarely is it a question of how well the system should do these things, how good development or deployment processes should be or what the situation is regarding recoverability.
This is precisely where the practical value of differentiation lies. It helps to sort requirements into those that a team is already well aware of and those that fly under the radar but cause risks and pain later on. Changes to quality requirements often have a major impact and affect many components.
The industry shapes the view. Automotive and automation technology teams are usually satisfied with their functional requirements and often also have good quality requirements because they build safety-relevant systems and the customer sets tough standards. This balance is less common in information systems.
The label loses its meaning during subsequent implementation. Whether it says “functional” or “quality” is then irrelevant: they are requirements like any other.
Sticking a number on a requirement only helps if there is a business case behind it
Quantified quality requirements are only useful if the number is justified. An arbitrary number does more harm than good.
A common mistake: teams go through the entire taxonomy and stick a number on every property. Sometimes it is pulled out of a hat, sometimes it is impossible to predict how it will settle because it is still unclear how many users the system will have at any one time. Such figures later come into conflict with other requirements or boundary conditions. There have been projects in which several quantitative requirements simply could not be met at the same time.
The direction of the error also varies. A customer has no idea and sticks a figure on it. Or an engineer wants to be sporty and names a figure that cannot be achieved within the available budget, just so that something is there at all. Why is 200 milliseconds not enough, why does it have to be 20? The question cannot be answered without a business case.
For many properties, the direction is more important than the target value. Faster is better, sometimes slower is better. In practice, measures are applied until the target is reached or the customer is satisfied. For this process, it is not necessary to know at the beginning what number you will end up with.
Some qualities are difficult to measure, but this is still important information
Not every quality can be measured with a number. Response time or requests per second are easy to measure. Security or usability are difficult. What does “Usability 5” mean?
At this point, the ISO uses the phrase “degree of which” to describe the extent to which quality can or should be measured. However, a non-quantified requirement also carries information. If it is clear that usability is very important to a stakeholder, this is valuable for the architectural design.
If the Definition of Done is missing, a risk arises. There is no clear point at which you are finished. Instead, you have to keep asking the customer whether it is good enough. This costs money, and both the customer and management must be aware of this. This is precisely what makes the lack of quantification an indicator, not a lack of control.
In practice, customers often shy away from the expense. They don’t pay for a usability study, even though usability is one of the most important drivers of the business case.
Trends replace targets: getting better instead of hitting a number
Increasingly, it is enough to see that things are moving in the right direction. Quantifying is often simply too expensive.
In evolutionary software architecture, you test for properties of the architecture without setting a fixed target value such as “5”. Instead, the goal is not to get worse, but ideally to get better. This trend is increasing. Much of what would have been a number in the past can now be mapped as a monitored process.
A recurring model problem further exacerbates the situation. For some quality attributes, endless discussions arise as to which chapter they belong in. Response times, for example, can be read as a usability or a performance issue. Half an hour of debate about categorization is useless if the classification does not play a role in the decision.
Good architecture hides decisions instead of making them right forever
There are two camps among software architects. One says that architecture means making the important decisions correctly. This is based on the assumption that you can’t change them later.
The other camp goes back to David Parnas. His idea is that each module hides a decision and thus puts you in a position to change this decision later. From this perspective, the position “we have to make the right decisions” is a collective capitulation to the problem.
If possible, you shouldn’t make any important decisions immovable at all, but make your software in such a way that you can change them later. Michael Sperber
This principle should apply to all qualities, not just functional ones. Even for non-functional qualities, it is important to find architectural concepts that allow you to react to changing requirements with changes that are as small, quick and cheap as possible.
This is precisely where the risk of blanket separation lies. Those who believe that functionality is simple and everything else is too difficult will build architectures that can no longer react to changes in the non-functional area.
Functionality first, but flexible enough for later
In the Isaqb model, it is considered unclean to start with functionality. In practice, however, the focus is almost always on functionality first, and almost every architecture is created from functionality in the first draft.
The trick is to keep the software flexible afterwards. Many tactics, especially for quantitative properties, take the form of taking an existing system and modifying it to improve the desired property. If you decouple early on, you can still fulfill such requirements later when they come into focus.
The different backgrounds characterize this view. Michael comes from functional architecture, Alexander from the hardware and object-oriented world. Functional architecture provides significantly less coupling in standard mode, in Michael’s experience about an order of magnitude less than typical object-oriented architecture. This tends to make the architectures more flexible towards changes.
The open question remains how to achieve this flexibility without overengineering at the beginning. At the beginning, nobody knows what the important decisions will be.
Performance and maintainability are not necessarily a trade-off
Higher performance often means closer coupling to specific hardware. For some teams, maintainability therefore hardly plays a role: in the safety environment, you want to deploy a system once and then let it run for ten years without ever changing it again.
But this finding is partly a chicken-and-egg problem. Many systems are not changed because they are difficult to change, not because no change is necessary. And the drivers for change are shifting. Devices in the embedded and safety environment are increasingly getting internet connections and are exposed to new attack vectors. This shifts priorities without reversing them.
The assumed conflict of objectives between performance and maintainability is even reversed in many cases. Traditional enterprise software is often tightly coupled to the database; the schema is designed for today’s queries. If the functional requirements change, the schema can no longer fulfill the new requests satisfactorily.
Theoretically, it would be possible to build a tightly coupled system that answers the new queries efficiently. The problem is the existing system, which cannot do this and cannot be changed. Since software usually lives longer than desired, it is worth betting on changeability, even against the call for a “good enough architecture”.
