In my last blog post, I looked at the different attributes that form a complete software system. Now that we have a better understanding of what a software system entails, it's worthwhile looking at the different attributes that affect the quality of a companies software, to form a true definition of what quality really means.
Software needs to meet its known functional requirements
Getting the obvious one out of the way. Software needs to be first measured by whether it meets the functional requirements set out for it. This is the core business or usage reason behind what the software is intended to do and should preferably be detailed in how the software achieves this to ensure it meets this need correctly.
Software needs to meet non-functional requirements
Businesses might look at what the software functionally does, but there is a lot more to what is going on in the details of how the system works than what it does. In fact, the list of things that should form part of a system's non-functional requirements is quite large with some aspects detailed enough to warrant an item on their own in this list.
The list of non-functional requirements that should factor into the idea of quality in the software team include:
Usability — How easy is it to use the product? What defines the experience of using the product? We don’t just need to ensure our software performs the required task but can do so in a way that is intuitive to the end-user or consuming systems.
Security — Security is a massive part of the software industry, and any software system needs to cater to a variety of different security measures. Including how it deals with data, privacy and can withstand a variety of attacks and malicious software viruses.
Capacity — Systems don’t operate infinitely so it’s useful to understand the expectations of its usage and data requirements. What are your system’s storage requirements, today and in the future? How will your system scale-up for increasing volume demands? The answers to these questions can have a big impact on how you approach the design of your system.
Compatibility — As mentioned earlier – the software doesn’t operate in isolation and needs to work with other systems. Both internally and externally. For instance, all web software needs to work with a variety of different browsers and hardware configurations and this needs to be accounted for in the final solution
Reliability and Availability — Software needs to work and be available to users. Knowing the expectations of when those users will need to use the software factors into how we think about its design. And this goes beyond just ensuring that the software works correctly but is also reflected in the architectural design of the overall system.
Scalability – Also often known as the Black Friday test, after how retail sites need to be able to adapt to the increased loads faced during the annual Black Friday craze. This sounds similar to capacity but deals less with long-term system usage and focuses on a software system's ability to adjust to unusual usage. Question to consider here in your design are things like what are the highest workloads under which the system will still perform as expected?
Load and Performance — This is another very important non-functional requirement that you can spend a large amount of time on it. Ensuring that software is designed for the relevant load and can perform according to certain expectations is critical to its operation and how we need to approach its design.
Regulatory — There are a variety of regulatory and compliance frameworks that software may need to meet depending on the industry they fall in and are there requirements you need to satisfy for compliance?
Environmental — Global warming and reducing greenhouse emissions is an important thing. And while the power efficiency of our software system should definitely matter to us, this goes beyond that and should also factor into the user environment that the software will be expected to perform in. Think about the difference between military or flight software which is critical in their operation and performance and reliability are far more important than pretty graphics versus a social media platform where this is incredibly important.
Software needs to make a measured ROI
This is only relevant for business software, but it is still a factor that many teams don’t even think about. And that is because you could argue that the (Return on Investment) ROI on software features is not the realm of the software developers, but rather the business. But that doesn’t mean that the engineering team shouldn’t be working to factor these things in.
In achieving the core functional requirements, software should achieve its purpose and thereby meet the necessary return on investment. Much depends on the way the code is delivered that will determine this. Software that works poorly is either not going to be used or requires a lot of extra effort to fix – all hampering the expected ROI of the software.
Similarly, software that is difficult to maintain, build or test (more on these topics later) will lead to longer development times and have an impact on ROI.
So, while it may not seem like something that a software team is directly responsible for, the quality of a team's work has a big bearing on the overall success of how a software application helps to allow a company to be financially successful.
Software quality needs to reduce the support effort of a company
A common function of many companies is their ability to support and service their clients. Software should help to streamline this effort. While not all software might be intended for this, it still has an impact on the overall ability of an organization to provide support and service to clients.
Software that doesn’t work as expected, leads to functionality breaking, makes users unhappy, and often increases the number of service requests (SR) that companies have to handle.
When software works reliably, this SR Support greatly goes down. So, in a way, the quality of software products has some bearing on a company’s ability to support its core business function and we need to factor this into our understanding and definition of what truly represents software quality.
Software needs to be easy to maintain
There are many different rules and standards that can be put in place to ensure that code is structured and documented in a certain way to make it easier to maintain. The same goes for the make-up of its architecture and testing frameworks and whether they support easy updating, fixing, and testing of software or whether it will require significant amounts of rework.
Software needs to meet its intended lifespan
We may not always think about software having a shelf-life. After all, unlike manufactured goods, the software can constantly be updated and upgraded to adapt to newer computing technologies.
However, this is a misconception. You can’t simply upgrade an underlying server or patch yourself out of a problem. Technology may improve over time, but this often renders many aspects of our software stack obsolete over time, so we need to consider that our software needs to support a certain amount of change to ensure its smooth operation.
Understanding the intention for the functionality long-term will shape the way the software is architectured and affects the way you approach the code design.
Quality touches every aspect of software design
Understanding that a software system in its entirety is incredibly vast and that quality impacts every aspect of it can be a daunting prospect. However, if we think about these factors early, we can easily mitigate them in our planning, design, and testing and ensure software systems can deliver according to this bigger definition of quality.