Quality scenarios in software architecture is a really important method to ensure the product fulfills the right functional and non-functional requirements. If projects are failing or need cost expensive refactings, the reasons are often changed or unexpected requirements. Also the misunderstanding for the product and product goals are often problems that can result in a wrong software architecture.
For a good software architecture, it is important that the product team has the awareness for the functional and non-functional goals. It’s also important to have a active discussion about the software architecture in the team.
Quality goals and Quality scenarios are methods that can help to ensure the software architecture is fitting the requirements.
Quality Goals
When new projects are starting, the functional requirements are often discussed. The product owner describe the product vision and work on a product backlog.
Development teams start to brainstorm about their architecture and start with their first implementation.
But beside the functional requirements, there are also important non-functional requirements to consider. The team should discuss the quality goals. A good starting point for finding the right goals can be the ISO 9126 that defines attributes for software quality.
There are two main reasons why this quality goals need to be prioritized:
- The most software products don’t need all quality attributes with the same priority. Trying to fulfill them all could be waste of money.
- It’s really important for the engineering team to understand the importance of the right quality attributes. Otherwise they may invest their time in the wrong goals.
In the given example the software product should have a high usability. Maintainability and functionality have also a high priority. On the other hand, the attribute reliability seems to be not so important for that product.
The ISO 9126 is just a example and maybe a starting point, but further quality attributes can be included when necessary.
The prioritized quality attributes help the engineering team to understand where they need to focus on the architecture level.
When should architecture work start?
In the early phase of a new software product the main work is mostly on finding the right software architecture. As a starting point – or let’s say ‘definition of ready’ the main requirements should be known and described.
Even in agile projects, a high level description for the product vision, product goals and main use-cases should be known. It’s normal that there are many unknowns. But a high amount of unknowns may result in a wrong software architecture. I’s really useful if the team discuss which decisions for the software architecture need to be done in a early phase, and which decisions can be done later without a big pain. Compared with building a house, the structure of the rooms should be known before building the walls, because the walls cannot be changed on a later phase. The color of the tiles can be chosen on a later phase without bigger problems. The same picture can be turned on building software systems. There are some main concepts that need to be defined in the early phase and it’s hard, often painful and expensive to change them later.
This doesn’t mean that everything need to be 100% clear before starting thinking about the software architecture. But teams should try to collect so many information they can get in this project phase. A smaller scope of uncertainty decreases the risk of wrong decisions.
Defining the quality scenarios
Beside of the main use-cases, the definition of quality scenarios is a good way to get a better idea what the product need to fulfill.
One good way can be to make a workshop with all relevant stakeholders of the products software architecture. This are mainly the customer / user of the product, surrounding products that need to be integrated, people that are responsible for running and maintaining the application, platform teams, compliance and quiet more. It make sense to make a stakeholder analysis in the beginning to find out who may have a stake on the software architecture.
This stakeholder should bring their quality scenarios that the software architecture need to fulfill. The scenarios can be structured in a table with columns like
- Unique ID to reference the quality scenario
- Reference to the corresponding quality goal
- Unique name for the quality scenario
- Business goal for the quality scenario
- Description
- Trigger
- System Reaction / Behavior
- Target System State
Here is the example of a list with quality scenarios for a online shop.
ID | Quality Goal | Name | Business Goal | Description | Trigger |
1 | Efficiency | Effective resource management | Cost efficiency | Depending on the current active customers in the shop, the system should be resource efficient. | Amount of users is increasing or decreasing |
2 | Functionality | Preventing unauthorized access | Security | The customer should only see his own data (including adres and payment data) and bills. It should not | Customer visit the account profile page |
3 | Functionality | Functionality | Compliance | Sensitive data like credit cards need to be transported and stored encrypted. | Customer add sensitive data like credit cards |
In this phase, the system behavior and target state remains empty. For the quality scenarios, it’s important they are described in a measurable and achievable way. The list with the scenarios should be prioritized in consideration for the priority of the corresponding quality attributes. It’s also important to ensure the list contains only scenarios for relevant quality attributes. This helps to keep the focus on the right topics.
Evaluating the software architecture with quality scenarios
Based on the product goals, main use-cases and quality scenarios the team can now start creating the software architecture on the paper. During this phase, the two open columns should be fulfilled. This will help to ensure all relevant scenarios are covered with the architecture.
The engineering team can then present the architecture and the filled table to the stakeholder.
ID | Quality Goal | Name | Business Goal | Description | Trigger | System Reaction / Behavior | Target State |
1 | Efficiency | Effective resource management | Cost efficiency | Depending on the current active customers in the shop, the system should be resource efficient. | Amount of users is increasing or decreasing | The system is able to scale up and down automatic based on configured CPU usage. | System use always the minimum of 2 instances or if there are more |
2 | Functionality | Preventing unauthorized access | Security | The customer should only see his own data (including adres and payment data) and bills. It should not | Customer visit the account profile page | The shop use an OAuth server for authentication and authorization. The backend API’s | Each operation is protected via OAuth. |
3 | Functionality | Functionality | Compliance | Sensitive data like credit cards need to be transported and stored encrypted. | Customer add sensitive data like credit cards | Sensitive fields are declared. The payment module has a generic logic to encrypt all fields that have this declaration. | Sensitive data is decrypted, unit test ensure the decryption and encryption is well implemented. |
Scenario based prioritization
Alternative to the previous method the prioritization of quality goals can be achieved based on quality scenarios. The stakeholder define quality scenarios and rate them. For the rating, different aspects like business value and non functional requirements can be considered. The rating from the quality scenarios can then lead to the prioritization for the referred quality goals.
How to start the implementation?
Quality scenarios are really useful in the beginning of the project because the architecture is in this phase only on the paper existing. Adjustments can be done very easy and cheap. The described process can be a iterative way with multiple iterations until all relevant quality scenarios are fulfilled in a acceptable way.
Some people may think that this is not agile anymore because there need to be a plan in upfront of starting with the implementation. There are many opinions but I would suggest that before starting with implementations, a high level plan should exist. This does not mean that the system is perfectly designed on a low level. For the implementation it’s useful to start with the features that have the highest risk on the technical level. It’s helpful to start with a first spike and check if the system behavior is like expected based on the quality scenarios. If the goal of the scenario is not reached, the process can go one step back to reconsider the architecture, challenge again the corresponding scenarios and create another spike. If the spike is working, the implementation of further use-cases and requirements can be done until a first valuable product is going to production.
Summary
In agile project it’s really important to develop a product step by step with integrating the user’s feedback as early as possible to ensure that the product bring the expected value. But the architecture work should not be underestimated. It’s not necessary (and recommended) to have a 100% plan how to implement a system. But it’s important to be aware of the main use-cases and non-functional requirements to ensure the given architecture fulfill them in the right way. This decreases the risk of expensive refactoring in later phases and help also the team to not waste time in the wrong targets. Quality goals can help to get a better understanding which aspects are important and also unimportant for the product. Quality scenarios help to get a better understanding for non-functional needs. The cross functional discussion with all relevant stakeholder ensure that all aspects are considered in the software architecture. It helps also to create transparency and a good understanding for the architecture inside the product team and also for the surrounding stakeholders.