Today we are starting with the part 2 of the lecture and this one is about the quality attributes that gives the whole book its name.
So quality attributes are somehow in the core of the architectural considerations.
Before we start, let's just have a look on the schedule.
I decided to do a change in the schedule and I want to introduce it to you because I will shift between part 2 and part 3 from now on.
If you look at the schedule that you found in the Moodle, then the first things are still the same.
So last week we had this one, today we are dealing with software quality requirements and with quality attributes as well.
However, next week there will be a change. We will start with part 3, so to say we have two branches from now on, sometimes switching between part 2 and part 3.
This is done because the quality requirements are strongly related to architectural analysis.
Therefore they have strong relations and in the last year's schedule it was far away from each other, so they are now more tightly coupled and more timely together.
And then we will continue with part 3, with a branch of part 2 as well until the end and later we will go to part 3 only.
So far today we start with architectural quality requirements specification and this is the first section.
As you know, as usual for this lecture, there are a couple of questions that can be used as example questions that might appear in the exam.
For this first video we have two of them, three categories of requirements and the impact, the different impact of functional and quality requirements.
As I already mentioned, we will continue this next week with considering what is architecture specific requirements.
Before I start, let me use some story about requirements engineering.
Possibly you know this from colleagues or wherever, it's about software processes and some things are different.
So it's explained differently than it's understood, that's the fact we know.
However the analyst does it a different way, the programmer was not so skilled, unfortunately he was not an expert, however the consultant gave a bright view of that.
Documentation was somehow poor and installation was not much better, however the billing was extensive.
Support from time to time, however what I want to focus on is what would really have been needed by the customer.
The actual joke of this is if you compare the last with the first drawing, what was explained and what was really needed.
And this is what requirements engineering is about, this was just a short introduction why requirements engineering is important.
As far as I know, my colleague Walid Malish does some things about requirements engineering at this university in one of his lectures and unfortunately we don't have much time on that to deal with that but I just want to inform you that's very important.
That's a different discipline, it's one of the disciplines within informatics requirements engineering is quite important for project success.
Let's start with the three categories, if we consider requirements we have to, sometimes it's a good idea to make distinctions between categories if they behave in different ways.
And I want to introduce three categories, the category of functional requirements, category of quality attributes requirements and the category of constraints.
What is different to them? At first in general then with an example.
Functional requirements as the name tells us is about function, it's about behavior, it's about structure, these are the firm things.
And they determine how the system will look like, how the system will work in terms of control flow, data flow, data structures, this is what usually developers think about first.
However, there are some more requirements and these requirements are about the qualities such as performance, robustness, usability, learnability, security, performance efficiency.
Cell maintainability even, many of these ilities, they have a big impact on the architecture because architectural, they have to be considered in architectural decision making.
Components and interfaces, the decision for technologies to work on, the technology stack has a big impact on the quality attributes, therefore the requirements regarding quality, they have an even bigger impact on the architecture than the functional requirements.
As I mentioned, next week we will deal with architecture specific requirements and you will find these points again.
Last group, third category here is the category of the constraints. What is different with constraints compared to the first two?
The constraints have to be fulfilled, period. There's no choice, you have to meet a certain interface, you have to use a certain platform.
You cannot introduce a new database system, you have to work exactly with the database system that is defined for your, let's say, for your enterprise.
Therefore, platform decisions are typical ones, including interfaces. If you have to meet the interface of a machine or some interfaces, you have to serve them.
Furthermore, there are strategic decisions that are firm, you can't influence them, you just have to follow them.
And there are some standards. Standards are mentioned interfaces, other standards are standards for some technologies, we just have to use them.
So the constraints give some, they reduce the options, the number of possible decisions, the decision space.
So they have a big impact on design decisions as well because they limit the options and they have a big impact on technology decisions because of the same reason.
So quality attributes have an impact and constraints have an impact both on design decisions and on technology decisions.
Let's discuss this with a small example. Let's consider we have a small hosting system or we have to, our job is to host email servers.
And this is just a business and we can consider ourselves as the runner, the operators of this business.
And these email servers, of course, have to be supported. Somehow, customers call up for help when they have some problems and we are there for solving the problems.
So this is our job, this is our business. Therefore, we have to work with the information that we get from the system.
And this is more or less in log files and we have to work with them. However, as you know, the traffic is always increasing and we have to deal with this increase.
Let's consider this in the first sketch, the first architectural idea was, of course, we have these email servers, they are operated by our company, they generate log files.
And working with these log files and customer calls has some questions, we have to solve some issues, we have to find out what is the issue.
Therefore, we use queries to use, for example, the CREP command to check in the log files to find something, to navigate in the log files to find things in the mess of these whole messages.
And you could log in to that machine where the email server is running.
This is one option. However, if you have much more traffic and the traffic is increasing, you need more things that could be used here in our system.
And data structures are not really optimized. The data structures in these log files, the log files are just entry by entry and that's not optimal for searching.
Furthermore, we just use the terminal operating system commands to check so just skilled people can solve this. It would be much better if we provide a better user interface.
Therefore, we should check for a new solution.
Until now, what we discussed will have been quality considerations and now have been functional considerations, sorry, and now quality considerations, quality goals come to play.
Quality goals are the usability to be used by non-professionals, non-operators and the speed up of the process so performance should be an issue for querying the log files.
Okay, let's try what we can do. So we come up with the next version of our architectures.
We use a transfer file, merge it to tables, we transfer it to a relational database where the information is stored in tables according to relations, according to events, according to clients.
And they are accessible through HTTP and we build a user interface with a client that can be accessible even by non-technicians.
Therefore, we solved, we changed the decision, we changed the decision for the platform, we changed the decision for the whole architecture, for the whole data operation according to quality attributes.
Okay, this one can still be improved and what we could do is something more for accessibility here and what we use is here just to use the distributed file system if the amount of emails is increasing.
So big data and Hadoop are used here as another platform because relational database reaches an end when it has to be built.
So these are examples, this might serve as a very small example how quality attributes play a role when we design a system.
So we changed the technology decision here twice because of usability first and speed up in the end performance efficiency second.
So far this is just an example, let's go now to the next section where we go to quality attributes in brief.