Disclaimer: This post includes Amazon affiliate links. If you click on one of them and you make a purchase I’ll earn a commission. Please notice your final price is not affected at all by using those links.

Business requirements are the driving factor when implementing any Software Architecture, those requirements shape the different characteristics the final software will have and determine the different trade-offs to consider when designing a system.

In Software Architecture Business Requirements are also known as Functional Requirements and indicate how a system should function, for example:

• “System must do XYZ”
• “System should encode images in different sizes”

There are other kind of requirements to consider when designing a Software Architecture called Non-Functional Requirements, this post covers them.

What are Non-Functional Requirements

Non-Functional Requirements indicate how a system should be, for example:

• “System must be ABC”
• “System should be able to respond to spikes of traffic”

I prefer using Quality Attributes instead of Non-Functional Requirements because it allows stakeholders to clearly see the importance of those characteristics, using Non-Functional may indicate something that is not needed or can be ignored.

In other words Quality Attributes describe the System Properties we our Software Architecture will have, a way to visualize both Functional Requirements and Quality Attributes would be using an iceberg:

Colloquially those Quality Attributes are also known as illities because this is the suffix many of those words share, for example:

• Observability: How easy is to know what’s happening? Using instrumentation and tracing tools, like OpenTelemetry, could answer that question.
• Scalability: How easy is to grow over time? For example will the selected datastore support new users over time?
• Agility: How easy and quickly can we deliver new features to our customers? Is our deployment process complicated?
• Security: Are we preventing unauthorized access? Is network connectivity encrypted? How much information services share?
• Availability: What’s the probability our system will be available for our systems? 99% 99.9% 99.99% Service Level Indicators (SLI) and Service Level Objectives (SLO) are used for this property.
• Localizability: This property indicates Internationalization (i18n) and Localization (l10n). Can the system be adapted to support different regions? Countries? Languages? Currencies?
• Fault Tolerance: Can the system be operated in some event of failure? Does it degrade gracefully?
• Elasticity: Can the system adapt to workload changes automatically? Does it scale-out/scale-in automatically?
• Extensibility: How complex is to add new functionality? In the case of Go is the source code idiomatic and well organized? Does it define correct abstractions? Or will it become big ball of mud eventually?

How to determine what Quality Attributes to use?

To determine the Quality Attributes to use we need to refer to the Business Requirements as well as the Product Expectations this is because Software Architectures can not implement all existing System Properties at the same time, it would be impossible to support all of them however the way I like to approach new projects is by recommending to focus on at least three Quality Attributes:

• Availability,
• Scalability, and
• Latency

Those three System Properties are the baseline I like to use to guide me during the initial implementation of Software Architecture, however as a baseline the important thing to keep in mind is always the Functional Requirements, those drive the technical decisions we should make when designing and implementing our Software Architecture.

Conclusion

Quality Attributes / Non-Functional are topics I will be covering in the near future, specifically in the context of Go and how those System Properties apply to services built using this programming language with concrete examples.

Recommended reading

If you’re looking to sink your teeth into more Software Architecture-related topics I recommend the following books:

• Agile Software Development, Principles, Patterns, and Practices
• Building Evolutionary Architectures: Support Constant Change
• Hands-On Software Architecture with Golang

Back to posts