 Welcome to this final part of the RE Requirements Engineering lecture and we now talk about the management of requirements and then we wrap up the whole thing. So managing is the process of basically dealing with requirements throughout their life cycle. You have new requirements coming in, you have requirements changing, you have to track them while you're developing them and so on. So points that you deal with in management is typically the change of requirements. So requirements do change and that's in fact one of the big issues we have in software engineering. While you're developing and while the software is in use things change. So on a development level how do you deal with this? If for example the client comes in halfway through your development and says we need to change something. We have realized there are problems, we need to change. What do you do? And this is partly a tooling issue so can you just modify it in your system? Do you need to keep versions? Do you need to do history essentially? But it's also about what do you do when this happens? Is there a kind of a process for this and in fact the summer world book talks about the change process a lot. So many companies for instance have a system that says okay the clients or the users can register a change request and when it comes in it's being analyzed and in practice that means someone looks at it, looks at the existing requirements and tries to understand why is the change there? Is it something we did wrong? Maybe we misunderstood something. Is it a requirement we have missed? The elicitation was not complete. It might also be a bug so everything is correct from a requirements perspective but in the system something has been wrongly implemented. But all of this requires some kind of process. How do you register a change? Who looks at it? What do they do and so on. So that's something we need to have in place if the development is complicated large enough. So that's an important part. The next thing we might want to have is a traceability policy and traceability is basically the practice of connecting things to each other. In many cases requirements for example to tests or to code. So that if you look at let's say a requirement, an individual requirement, can you tell how this is implemented in code? Can you tell how this is tested or if it is tested? That's one way you might also have to for example connect it to another requirement. So for example I mentioned in the previous video that the requirement to do voice recording to switch on the radio might depend on a more general requirement that voice capability is existing in the system. And this is something that is often required by regulations. You have to do that. For example if you develop financial software or safety critical software or so on. But it's also something that is of course useful to have. So if a change comes in here you might be able to tell which code which tests do we have to change. Or if you change some code because there's a bug you might understand okay this depends or this implements a certain requirement and there are other requirements depending on that. Maybe I also need to look at the code that is implementing this part to fix the bug properly. So essentially this is all about understanding how things are connected and in an organization you need to have some kind of policy of how to do this. For example do we need connections between requirements and code? Then you have to somehow tell the developers to do this. You also have to give them access that they can actually for example touch the requirements in the requirements management tool. So it's all about having a policy. And that has to do of course with requirements with regulations. So are we required to have certain trace links but it also has to do with costs. It's good to have these trace links but it's very expensive to create them. So you want to have your developers focus on testing on coding not just documenting all the time. So it's a matter of cost and even if you have this in place the question is how do you update these so that you don't end up with a system where all of these connections are there but they're all wrong. Then they don't help you at all. So there should be some kind of process some kind of policy in the company that says this is how we do traceability. This is who does it and when. And finally management is a lot about tooling. What kind of tools do we have in place? Who has access to them? What kind of licenses do we need? What are the capabilities? For example if we talk about tracing you might be doing your coding in let's say VS code or any kind of IDE. The requirements are probably another tool and then the question is is there any easy way to connect code to requirements or do you have to go into two different tools you have to do manually somehow the connection. For example in your code you add a comment that says requirement one that's your trace link. That's not very useful because you have to do manually all the work. So there is a lot of debate about tooling and in fact many companies we talk to are very often concerned with this. What is the best requirements engineering tool? How do we use it? So that's a big part of it. Now this is all I want to mention about management. In fact all of these points are a lot of different work. They're very complicated but you should at this point just be aware of that these are issues. Let's wrap this up. So requirements engineering is all about figuring out and documenting and managing what the stakeholder needs are and the important thing is it's not just writing down. So for many people when you mention requirements they're all like yeah but why do we need a large text document. It's not only that. In fact for many companies the value in requirements is the knowledge. So all the work you put into understanding what you really need understanding your end users understanding the stakeholders. That is really the key here and in particular if we talk about management being sure that this knowledge stays over time because especially in larger companies you can expect that your developers your requirements engineers are leaving at some point. There might be new people coming in. So how do you keep this knowledge in the company? And that's also when we go into processes in the next module if we talk about agile development. There has been the debate a bit in agile development do we still need requirements engineering? Well you still need the knowledge of what to build. So in a way yes you do need requirements engineering. It might look different you might not have long text documents but you still need to think about all these four different activities. How do you make sure to get the requirements? How do you document should you document them at all? How do you validate them? And how do you manage them? So this concludes the module on requirements engineering. Thank you very much for watching.