 Welcome to this first module of the software engineering course in which we'll cover the topic of requirements engineering. Requirements engineering is one of the most central activities in software engineering because it deals with what is it that is required in a system and of course that's a key thing to figure out if you want to develop, you need to know what to do. And basically a requirement is in the literature something that a stakeholder needs, it's a stakeholder need. And this is already telling us that this is not a very easy process because it's not about what they want, it's what they need and that is in practice quite difficult difference because a user for instance might be able to tell you exactly what they want but they might not know what they need and in many practices they will not be, in many cases they will not even be able to tell you what they want so figuring this out is not easy. Stakeholders rather complicated term can be everyone and every organization, every entity that somehow has a stake has some kind of relation and need is influenced by the overall system so the typical stakeholders are for example our users and users but also administrators for example the clients so if you have a person or an organization that orders something they of course have an interest in the software. It might be that developers of the system or the ones that have to maintain it later on it could be regulatory bodies, regulators so let's say you are developing finance software then of course there are certain requirements on how to do that the software is regulated then the regulators are stakeholders and this list can go on so it's pretty difficult to figure out what is it that these stakeholders need all of them and in particular if you think for example about the developer and the regulators these might very well be conflicting so you might be it might be very easy to do something develop the system in a certain way but you might have to do it differently because regulations ask you to so this is not that easy so this is what it is a requirement is a stakeholder need and we typically distinguish between a couple of different requirements one common distinction that you might see is the system requirement versus the user requirement and that is simply a matter of perspective so your user has a very functional perspective this is what I want to use the system for if you want to develop it you might have to look at it from a different way for example if you develop let's say a car the user can tell you what he or she would like to have as a functionality for example if I use a voice command in my car I want to be able to enable the radio to switch it on or off for example so that's the user perspective but from a system perspective that means that you need certain capabilities for example the system needs to be able to record voice the system needs to be able to detect when someone speaks and that goes down to a much more technical level than what the individual components in the car for example might be required to do so this is sort of the holistic perspective how do you develop the system and this is just what the user would like to be able to do and in the old world in the old when you did software development step by step in a plan driven way usually the user the client would come with a so-called user requirements specification which just described on an abstract on a very high level what is it we would like the software to do for us what would we like to do with it and then the contractor whoever develops the system would write a system requirements specification and would say okay this is what the system overall will do and ideally this specification matches this functionality so that's one way of looking at it another way is from a development point of view is functional requirements versus non-functional and that basically means that you have requirements that deal with what should the system do what it's what is its functionality and what is the quality of the system for instance if we take the car example again the system shall be able to react to voice commands to switch or on or off the radio that's definitely a function but the system shall be able to react to voice commands within 10 milliseconds for example that's more of a quality that's how performant is the system and in fact these non-functional requirements are often called quality requirements so they deal with the different qualities how quick is the system how maintainable is it how secure is it and so on these are typical things now what does it actually mean to do requirements engineering what you see very often is a distinction in four different activities and they are requirements elicitation requirements specification requirements and validation and finally requirements management and we will go into these four different activities in the remaining videos but just to give you an overview what they roughly are elicitation is about finding out what the requirements are so basically figuring out discovering what are the stakeholder needs and that's for example through doing interviews or surveys or observing users in their daily work in specification it is about formalizing writing down the requirements so for example you might have figured out by looking at a user that they would like to be able to use voice commands so the question is how do you document that that for example the developers later on know what to do or the regulators later on can see that yeah you have done this in the right way so it's a lot about how to write requirements validation is making sure ensuring somehow that the requirements you have found are good enough and that means they are actually stakeholder needs you have captured them it also means to check somehow whether you have forgotten any important ones so are they complete enough you have to check if you have a lot of requirements whether they fit together whether they're consistent if you have two different requirements that they say opposing things then you have a problem you don't know exactly what which one should be the right one and then finally managing them because requirements in real life projects can easily get very large so in in big technical systems you can easily end up if everything is specified with thousands of pages and for example this is about having them in the right tool so it's easy to find them to modify them to read them it's about connecting them so requirements are often related so if you have the right connections between them in case you need to change something it's very easy to figure out which other requirements do you have to address for example so this is a lot of tooling for instance and I think I'll keep it at this in this video but we'll go into more detail I have the numbers here one two three four but these activities actually do not have to be exactly in this fashion so it's for example very common that you start with specification you know something that you need in the system and then based on that you realize okay maybe I need to go back to elicitation I find some more requirements you specify these maybe you do some validation and you realize something is wrong you go back and so on so all of these activities can be very much intertwined iterative and so on it's not by no means a linear step okay so we'll stop here and in the remaining videos we go into the details here thank you