 Welcome to video number four in this series and we're now talking about the specification of quality requirements or non-functional requirements. And as we already discussed these address different qualities of the systems. And typical things you have are for instance requirements on the performance of a system, how should be the response time, how should be the capacity, how many users at the same time can it handle and so on. You have requirements on the security, what kind of for example authorization is implemented in the system on a different user roles, do you have to register, how can you access data, is it encrypted and so on. You might have for example reliability, how reliable is the system, also including things such as what happens if there is a fault, if for example the hard drive crashes on the operating system, how do you deal with this, can you anyhow restart and so on. So different things there, usability and I imagine that you have done a lot on that in Marta's course, so how usable is the system. Maintainability, how maintainable is it, is it a modular system, is it testable in a good way and there are more of these. Sometimes you also hear people talk about the illities, so it's all these kind of terms that end on illity, almost all of them. So these are the things we want to look at and they are actually quite hard to address because first of all if you look at development later on it's very difficult to address these in a single part of the system. So it might be that you have a part let's say the software code that writes something to the database, might be very performant, it's very quick but then for example you have implemented the user interface in a way that is quite slow and then suddenly the overall performance of the system is bad and this is an issue we have generally with many of these qualities that it's a cross-cutting concern. You change something in one part of the system and the entire system is affected. That's really difficult to address therefore especially also from a maintenance point of view. If you change something other things might break. So these are a hard thing to deal with but also if we come to the specification how do we specify it is actually not at all easy and I know that in the course you have taken there was one example that says a bad requirement would be to say the system shall be fast. So that would be roughly a performance requirement. The system shall be fast. The problems of course what does this mean? What is fast? Is it fast if it replies to you within an hour? Is it fast if it can handle 10 users? And now the answer might be it's better to say have a average response time smaller 500 milliseconds. So that's already better because you know somehow what is being measured. How does the system respond on average and you know what the limit is? Now there are two issues with that. The first is average over what? Is it enough to measure three times? Is it enough to measure one part of the system? For example is it only things that you enter through the user interface? Maybe there's also some kind of API some programmatic interface and that one you exclude. So the question is what are you measuring? What are the conditions? So is it the response time when there is only one user? Is it the response time when there are also 20 users at the same time active somewhere else? And why 500 milliseconds? So these are things that are quite difficult to describe. Generally this is already better because it gives you some details but you might want to include some kind of metric and measurement details. So what are you measuring and how do you measure it? What are the experiment conditions basically? And have a good limit and this is indeed in practice probably one of the hardest things. So I've heard stories of companies that said we need to have this limit because everyone writes fast so they just in their tool they just put a default there and say if you don't know what to enter it will be 200 milliseconds and then of course every requirement ended up being 200 milliseconds because no one could decide what this should be. If you have to find a limit there might be different ways to do this. One is for instance to look at literature so maybe there is some kind of study or some kind of material that shows you well 500 milliseconds is roughly the point where users start noticing that something is wrong. They might feel that something is off so that's one way of looking at it. Other requirements I don't have portability here but for example if we talk about mobile phones one source is often to look at what kind of operating systems are people using. There are official statistics that say 98 percent have iOS this version or higher and then you can actually decide okay the limit our system shall be portable or shall be backwards compatible to at least that version or higher. So if you have any kind of literature to base your limits on that can be a good source otherwise you can also do measurements you can test with people and maybe figure out most people thought it was pretty okay at 500 milliseconds if it got more they got really annoyed so then you have an idea. If not it's maybe still better to come up with something if you don't have any idea rather than writing fast but you should keep in mind that this is a cost factor so it might be that 500 milliseconds is double as expensive as one second or 700 milliseconds so then you need to ask yourself the questions is this really what we need can we go any higher because if you can go higher it might be much cheaper but this is definitely the question mark he remains this is not an easy thing to do in practice and in fact many companies do struggle with that if they write down their requirements their quality requirements they you can be pretty sure that they still have problems there sometimes you might also have regulations so depending on your system there might be regulations that tell you what exactly to put in here okay now how do we write them you can have these shallow statements but in fact there are different you can probably find methods for all of these different quality aspects that are specific specific security requirements and so on one method that exists I just want to mention it here is called a language or p language and that's in a way a form-based specification method so it's a language that tells you what kind of feels do you have to have for each quality requirement and things there are for instance fields there is scale that says okay how do you measure this there is metric what is the what is the resulting metric how do we measure for example response time in milliseconds and then there are different there is like a description what is the requirement really about and there are different levels different limits that say okay it must be at least 500 milliseconds we plan to have it less than 300 we wish for less than 200 and so on but then at least you get it you get a range and you can maybe say that okay somewhere in this interval we need to be ideally we're somewhere on this side but if we're here it's still okay so this is something you can look at if you're interested in finding out more about this how do you specify quality requirements that's one method that is fairly popular but other than that as I said there might be different methods in the literature and the general specification techniques still apply okay so this is all I'll talk about specification in general and specifically on quality requirements and we'll now in the next video continue with how to validate that our requirements are actually appropriate thanks for watching