ready all right good morning afternoon evening everyone whatever time you end up watching this video welcome to the course on requirements engineering my name is bigoted Penson Starla and today I will give you a little overview of what the content of the semesters course is gonna be so let me start with writing down that title requirements engineering you probably have that somewhere on the website that you're looking at however one of the most important things in requirements engineering is becoming clear about the terminology that you use in a certain context so the first thing I would like to explain is what requirements engineering is has two parts requirements and engineering it's the early part of software engineering software design so in software engineering in general we start eliciting the requirements from the stakeholder we then move on into software design and then we implement and code and then we test integrate and eventually deploy and then we'll have to maintain for a long time potentially and you can see by the gesture that that usually takes more effort than you would initially think one of the reasons why it often takes more effort than you would initially think is because people didn't do a proper job in requirements engineering which will never happen to you because you're learning it right now so requirements are what people want in a software system or in a software intensive system or actually in any kind of system so what you learn in this course is potentially going to be useful for all sorts of areas in your life second it includes wishes that they may have that they are not aware of yet third it includes what they actually need but they may not know what they actually need they're stuck with some of the vish wishes and some of the things they think the software system should be able to do and the last one is constraints so constraints that your technical environment brings constraints that any other software system brings that your system will have to be integrated with and constraints by the operating environment where your system is later on going to run for example a certain connectivity to the cloud that's for the requirements part for the engineering part engineering in general says we try to do things according to a certain systematic we try to follow some good practices we will have some guidelines we will have some frameworks we will have some rules and we will have some best practices that have developed over experience in many years so even though we cannot formally prove why that is a good thing to do the last 25 years it seemed to be working pretty well so that's what we'll do before we try something else so this taken together is what will be the overall topic of the course and your particular learning goals will be developing those requirements first of all that means finding out what those requirements are so that means in another term allistic eliciting them this is also very typical for requirements engineering we usually have a bunch of synonym things that almost mean the same thing but not quite so sometimes we have to differentiate and sometimes we say well yeah it's kind of synonym it's pretty much the same for example quality requirements and non-functional requirements some of you may have heard that term before it is pretty close non-functional classifies anything that is not concerned with a particular feature in a system a quality requirement is a subcategory of that that talks about the performance of a system the robustness the reliability but that is a subchapter we'll talk about later back to the learning goals so we're going to develop requirements we're going to learn a number of techniques of how to do that we can do that in the form of natural language requirements and we can do that in the form of modeled requirements and modeled or model based requirements that can be some form of graphs some form of formulas and some form of code or pseudocode many of these graphs you may be familiar with some of those are UML diagrams for example UML diagrams formulas or more mathematical representation which means they're very precise but they can also grow really complex and really complicated so this is what we often use when there is a high security or safety relevance of our system then we want to know we want to be able to prove that a certain requirement fulfills something and that's what we want to be able to verified mathematically and then code is if we go into rapid prototyping if we want to find out what a customer really needs or if we have to try a couple of things out to know whether they can even work then we'll use code either pseudocode or early prototype for the graphs here and for the natural language requirements this is where we'll spend a good part of this course we call working with a lot of graphs and that in combination with natural language requirements that fit these graphs we call that artifact based requirements engineering I'll write that one down what's an artifact it's not like the thing that they found in Indiana Jones but it means any type of documentation any type of notation that would write down some customer requirements any type of code piece or even any PowerPoint slide where some CEO of a company said this is what we envision in the future that may be relevant to the system you're developing for them so that can include polls that can include other stakeholders and that can be information about constraints and we will talk about what each of these three are in more detail over the next few lessons now apart from learning several methods on how to develop these types of requirements and apart from learning these concepts in detail and how we can represent them the most important part about requirements engineering is communication so the requirements engineer is kind of the communication gateway between the stakeholders who are all the people who we should care about to talk to for a specific system in the development and on the other side of that communication communication gateway are the software developers your designers your Quality Assurance people your testers everything and everybody who helps get that system on the market and the requirements engineer to be able to translate in between the stakeholders over here who don't necessarily have a lot of technical knowledge and the very technical people back here so we need to be able to speak both languages and we need to be able to translate what the non-technical non-technical people say into what the technical people can easily understand and we need to be able to translate proposals of the technical people to the non-technical people so they can sign off on a specific set of requirements or a proposal to their solution so this is a very generic generic idea of what requirements engineering is and what we'll be dealing with the semester well learn how to do requirements how to elicit and find them how to write them down how to document them and then also how to prove them and how to communicate them to the stakeholders