 So, in the second video on requirements engineering, we talk about the activity known as requirements elicitation. And requirements elicitation is really a discovery, as Someril writes. It's a discovery of the requirements of the stakeholder needs. And this is a really, really important point. It's not about what a client, a user wants, it's figuring out what they need and what is needed generally of the system. So that's the key of it, finding out what you need. And as a part of that, you usually also go into activities like prioritization. So you have a lot of requirements, a lot of needs, which ones are really the important ones. And because you have so many different stakeholders, you end up in requirements negotiations. So usually, someone pays for the system, so it's also a matter of. Even though we have five requirements that are really important, we can only pay for four, which ones should those be? And in the best situation, it's you discussing with the client, but in many cases that's of course a negotiation among all the different stakeholders. For example, you might have the end user needs, you might have certain administrative needs, you might have the regulators coming in, you have the budget. So this is not at all a simple step. Now, this course has as a prerequisite the course with Marta, so I'm not going into a lot of detail on elicitation because you have already done that. But roughly, elicitation techniques include, for example, interviews. You might want to interview a customer or a user. How would you like to use the system? What do you think is important? What kind of problems that you have with previous systems and so on? You can run a survey, a questionnaire-based survey. As you all know, you're going to invite Link, please participate in this survey. It only takes 10 minutes and then you ask different questions. And of course, interviews are very time-intensive. It takes a lot of time to prepare them. It takes a lot of time to analyze them later on if you want to do it properly. Surveys are much, much cheaper. So it's, for example, much easier to reach a large amount of end users so that you get more input. Because of course, interviews give you very in-depth data, they give you all the details, they often give you the background why something is important, but it's only from few people. And if you have selected the wrong people, that's a big problem. So a survey can be a good tool to reach a much broader base. The drawback here is, of course, you do not get all the details. You get a certain answer, but you don't know why. So often you say that a survey answers a what question and interviews can answer more why or how questions. For example, if you do a political poll, which party would you vote for? You get a certain picture, 50% would vote for X, but you can't explain why that is the case. For that you might have to go and interview people. Other techniques are observations, so you can actually go and observe people. For example, figure out how are they using the system. And this is a very good way to really find out what they need. Because in an interview, in a survey, they can mainly tell you what they want or what they don't have so far, but it's very hard to find out what they need. For that, for example, observation might be a good way because you see that, okay, they always use the system in a certain way. It's really strange. Maybe they actually need something else. Again, similar to the interview, this is quite expensive, though. If you want to observe people over a longer time, you need to analyze that somehow. It's not easy and it's not cheap. What is also common is the study of existing systems. For example, if you build a follow-up system or documents, if there's any kind of documentations on how the current system works or maybe a manual on how different processes in the company work, then this is also very common, of course. In many cases you are not developing something completely new, but there might be an existing system. So that's also a source for elicitation. In the Somerville book there is also something listed that he calls scenarios as an elicitation tool. So basically you write down an entire, for example, an entire workflow. When I get into my car, I usually switch on the ignition, then I use the voice command to start the radio and so on. Basically by getting this very rich description of how the whole process works out, it's much easier to tell what are the details, why are certain things needed or maybe why are certain things currently done in a way that we could do much better. So that's what he suggests in the requirements literature scenarios are also very often a tool for requirements specifications, so how to write them down and we'll get to that later. So these are typical elicitation techniques to find out what people need. As I said, I just want to mention them here, I don't want to go into the details because all of them you can easily spend a lecture on. They are quite complicated, plus you have done that in previous courses, but this is just to mention which techniques could exist. There are of course more. Now we already mentioned this is about discovery, so it's rather difficult to find out what people need and what are in detail the problems. So the first problem we have already mentioned, we are talking about needs not wants and it's really hard for people to formulate what they need, they can tell you what they want. The best example of course, if you look at small kids for instance, they're very good at telling you what they want, it's very often different from what they really need and when it comes to complicated systems it's not that different for adults either. So someone can always tell you what they would like to have but it might be a big discrepancy. So that's why you have all these tools to find out, is there something more than what they want? Is there something different? The other difficulty is the domain. In many cases, you as a requirements engineer when you do elicitation, you will deal with a system that is not your specialty. For example, let's say you graduate from this university and you start working for a bank and then you have to develop the system in the finance domain and all the people you talk to will talk the finance language basically. So that's a very different domain and for example they might use terms that are completely different than what you are used to, they might use them in a different way than you do and of course for example they might have existing processes, how to do things that you are not at all familiar with and the problem is always to find out which language are they talking actually and what part of what they tell you are they skipping because for example certain terms for them they are completely natural, they don't think about that they need to explain that. So this is often an issue, it's very rare that you work in a domain long enough that you really truly understand it and for many companies that's actually a competitive advantage if they are really knowledgeable in their domain. Now one thing I have mentioned when it comes to prioritization and negotiation are conflicts. So you have many stakeholders and they will tell you different things. So you have to somehow figure out how do we deal with these issues. If one person tells you we need A and the other person tells you we should not have A how do you result that conflict without causing problems without causing frustration among different stakeholders basically in a good way and of course budget is always a big conflict you only have a certain limited budget on what you can do and then finally we are going into organization politics so different conflicts if you are developing a software for a specific organization they might have internal struggles going on that one part of the organization would like to have something and the other organization wants the other department wants something else and they sort of fight so this is often an issue in these cases. Other things if we don't talk about a single organization are for example regulations so that's very often strong lobbying that certain things you can do in one way but other things you are not allowed to do so these things often come into play here as well. So this is a quick overview of what requirements and the citation is about as I said these are the main techniques you can use if you would like to do that I would recommend to read the dedicated literature on that or refer back to the course that you already had. Thanks and we'll continue in the next video with requirement specification.