[MUSIC] So up till now, we have been talking about quality in an informal way. However, if you want to build systems that support the required qualities, you will need a way to express those qualities, and you need to understand how you can achieve them. After this module, you should be able to understand quality attributes and formulate your own quality requirements. We will also study two qualities that are especially relevant for the Internet of things, interoperability and modifiability. Now, quality attributes have been around for a long time, and many of them have their own research community and interest groups. Performance engineering, usability, and security, all examples of such specialized communities. The list is endless, but there are many problems with this older approach to system quality attributes. In many cases, the system quality is considered without any relation to the other qualities, and each community has its own vocabulary. Responsiveness has a different meaning for a performance engineer than for a usability expert. Another problem is the fact that some definitions are vague or ambiguous. What does it mean if a system is modifiable or fast? How can I test a requirement that states that the system needs to have high level of usability? Let's take the example of a mobile phone application for looking up train schedules. This sounds like a very simple, functional application, the only thing we need to do is to look up something in a database. However, users expect that such applications have a very high level of usability. Now, our intuition tells us that it can be somehow related to the fact that we want to get to the train schedule of the next train with a minimum number of keystrokes. But a usability requirement expressed as the departure station should be available with a minimum number of keystrokes is not specific enough to reason about the impact on the system architecture. What does that mean, minimum number of keystrokes? Or how do I even test this? So it makes more sense to formulate that the mobile application should protect the user against wrong data entries. This is called user error protection. And autocompletion on input fields is a way to achieve this. Now, the autocompletion can be made context aware and even propose a list of train stations that take into account the user location, the actual time of the day, and previous searches. So by now you should be convinced that usability has a big impact on the software architecture. And if not, you should start reasoning like a software architect and ask yourself, what are the structures needed to implement autocompletion in this very specific case? Where do I get the list of available train stations? Where do I store these lists? How can I filter the stations close to my actual position? Or how can I order this list in a way that the most recent searches appear first? The usability requirement for this use case should be rewritten as follows, a mobile user wants to look up the train schedules using the mobile app of the railway operator. The user interface system of the app will present a precalculated lists of departure stations taking into account location, time, and previous search results. The user interface of the system will also preset the departure time and a list of three possible destinations, again, based on previous searches. And this task will complete within three seconds after starting the application under normal runtime conditions. Now, this is a description of a quality attribute that already can be tested and measured. It can also be used to verify with the users and customers if the specification meets the expected functionality and quality levels. So the mobile application example allows us now to make a more formal definition of a quality attribute. A quality attribute, or a QA, is a measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders. Now, this definition means that you can easily verify if a quality attribute is well specified. If you cannot quantify it or write a test case for it, it simply is not good enough, and you need to reiterate until it satisfies this definition. Now, the list of quality attributes is long and virtually unlimited because as new complex systems are being designed, new quality attributes, or new flavors of existing quality attributes, are being added. And the application of the Internet of things to the healthcare sector, with the introduction to medical devices, wireless sensors and big data, has already introduced some new quality attributes. For example, medical staff expect that the analysis and the interpretation of medical data and medical images to be clinically correct. In this case, it could mean that the diagnosis should be equivalent to the conclusions of a reference group of health professionals. Now, this new system quality attribute can be quantified by the fact that there should be no more false negatives or false positives that indicates of a diagnosis by a medical specialist. It is a new type of requirement for diagnosis or clinical equivalence, and it can lead to long and expensive trials for the validation of a new digital system. So as a software architect, you will rely on quality attribute definitions to specify and analyze diverse sets of quality attributes of a given system. The definition is the basis for expressing the quality attributes in a more formal way. And it forces you to capture complete and quantified information that can be used to communicate and negotiate with stakeholders.
