In this lesson you will learn how to express quality attributes in a universal and formal way. And for this, we will use the Quality Attribute Scenario or the QAS. The goal of a QAS is to capture unambiguously and testable quality requirements. In the same way as use case scenarios do this for functional requirements. Now first, you will get familiar with the structure of the quality attribute scenario template. Next, we will apply this to a particular quality attribute domain such as interoperability or modifiability. And the final step is to use the domain specific quality attribute scenario for expressing concrete quality requirement. The quality attribute scenario captures the following information. Who or what does something to the system of part of it under certain conditions? How does the system react to these actions and how can these actions and reactions be measured by metrics? This is the type of information a software architect needs to have a good understanding of the quality requirement. And to have a basis for communication and negotiation with the stakeholders. This information is represented by the six elements of the quality attribute scenario template. For the first element, the source, identifies the original nature of the event or the action. It can be user or another system. The second element is the stimulus, and describes the action or the external event that arise at the system. The response tells us how the system reacts to the stimulus. And the response measured provides metrics and quantifies the quality attribute. The environment describes the external circumstances under which the quality requirements needs to be omit. And the artifact indicates the part of the system to which the quality requirement applies. Now the QAS template is a universal template, and it can be instantiated for each specific quality domain. This will be called the general QAS for the quality domain. Which can be security, performance, or any other quality domain that was mentioned earlier. The general QAS gives the architect a domain-specific vocabulary. And also proposes concrete elements that should be used to describe quality requirements in that domain. In the case of performance, the general performance QAS enumerates. For example, the metrics that should be used to measure the quality of performance requirements. Like latency is the time by which an event need to be processed. While throughput is the number of events that can be processed in a particular interval. Combined, the capacity of a system measures the maximum throughput without violating latency requirements. Now the general performance scenario, provides these levels of the main related details for all six parts of the quality attribute scenario. The software architect then uses the general QAS of the quality domains that are relevant to the system and the construction. To formulate concrete quality attribute scenarios. And when writing concrete quality attribute scenarios the architect usually starts with four core elements. The source, the stimulus, the response, and the response measure, this is sometimes called the Minuscule Scenario. However, the artifacts and the environment are equally important. And should always be considered as essential elements of a complete quality requirements specification. Now, let's go back to our smart city traffic management application. And analyse the performance requirements of the sub systems that announce the public transport arrival times and the real-time displays in the terminals. In this smart transport system, each bus will have a sub system that send real time data such as speed and location to a central server. The central server will then calculate the estimated arrival time for each bus and update the relevant digital displays. Now we need to specify the performance requirement for this use case. The mini quality attribute scenario contains the following elements. A source, a bus subsystem, sense a stimulus which is a periodic message which speeds in location information every 15 seconds. The system then produces a response, the estimated arrival time for all desk terminals. And sends it out with a measurable response time of 30 seconds after receiving the message from the first bus. Though this type of mini quality attribute scenario is often used in the early analysis of quality attributes to determine the business priority and the technical complexity. This analysis is helpful when trade-off decisions are needed. Well to have a complete QAS you also need to specify the environment. Because we need to know the conditions under which this quality requirement applies. The response time of 30 seconds may not only be required under normal conditions. But we may need a second quality attribute scenario under peak load conditions. Where we allow a response time of 30 seconds, but with a jitter of ten seconds. And finally, we also need to know which part of the traffic management system is responsible for supporting this quality requirement. Now this may not be fully clear at the start of the architectural design. But we do need to identify this as soon as the structure of the architecture starts to take shape. And for the moment we assign you to the central server, but during the iterations of the attribute driven design. We may allocate it to a more specific software module, like the arrival time calculations module. So, as a software architect, you will use quality attributes scenarios to express quality requirements. Quality attributes scenarios contain six elements and can be applied to every quality domain. The domain specific, or general quality attribute scenario. Contains the vocabulary that can be used to write concrete quality attribute scenarios.
