Ever heard about quality scenarios? We are completing the development and delivering the software to the customer. But the customer is disappointed and describes the software as poor. The developers believe that they have complied with all the requirements. Consequently, the software must be good. Here, quality scenarios help to evaluate the quality characteristics of software objectively.
Why quality scenarios?
The newly developed software is available, and the boss asks us to evaluate the quality of the software. So I look at the many menu items and am thrilled by the many options. The old software did not have many options. On the other hand, my colleague feels that the interface is no longer up to date. Compared to other products, the interface seems sluggish, and the color scheme could be better. Another colleague is ambivalent. The operational features of the high availability are good, but the installation requires a little study. Here we see three people with three different opinions about the quality of this software.Is the quality of the software measurable?
Without further ado, the quality of the software does not seem to be measurable. Subjectively, each colleague comes to a different evaluation. After some discussion, we realize that each of us applies a different standard. And here lies the problem, we need a standard measurement for evaluation. This situation raises the question of whether and how it can objectively evaluate the software.Quality scenarios as a metric
The quality scenario describes an event that affects the system, and a metric suitably defines the system’s reaction. The goal is to define the scenario in such a way that different observers come to a comparable result. The following are a few examples of quality scenarios:- An average system engineer can install the software within an hour.
- 90% of the users can operate the software without further support after a 1-day training.
- The software can run on 4 CPUs and 12GB RAM.
- Migrating a document from the best edge system to the new system within 15 minutes.
- To make enhancements, a new developer can learn the source code within 2 days.
The Quality Tree
ISO 25010 defines a set of categories for quality scenarios, covering different areas of quality scenarios. Upon closer inspection, it becomes clear that some of these categories form opposites. Here it is necessary to prioritize, for example, maintainability over efficiency. Here is an overview of the quality tree:
The quality scenarios
Now, we define scenarios with their metrics based on the categories. The stimulus describes the trigger and measures the scenario through the metric. It requires no intuition for evaluation. We based the evaluation on objective criteria. Typically, quality scenarios are agreed upon between the client and the development team before development. By defining the quality criteria, the client describes his expectations. And the implementation team knows what is essential.Summary
The quality scenarios help all stakeholders. The client deals with his requirements early and prioritizes what is particularly important to him. The software architect supports this process by asking specific questions. As a result, the implementation team knows what is essential. As a result, all stakeholders pull together, and there are fewer surprises at the end. In particular, the quality scenarios clearly define which properties the software must fulfill to be good.