 Okay, welcome to part three of this requirements engineering module and we'll now talk about requirements specification. So as mentioned in the first video, this is essentially how to write them down. In language, in text, drawn as a model, putting them into a tool in many cases, for example something like Jira, which you have maybe already seen. So it is all about somehow getting them into written form and it's not that easy to decide as a first step how you should actually write them and who is the receiver of these documents. For example, the classical case is that you write requirements so that they can be developed. So you give them to your developers and say here, please write the system that fulfills these requirements. That's one purpose. Then you might need to be quite specific on the details of the system, how should it really work or what should it do rather. Often you actually avoid how because that's up to the developers. But it might also be, for example, for contracting. So it might be a document and that's what you sign a contract on based on the specifications for example, you as a developer, you as a development organization, you write the specification, you discuss it with the client and then you sign a contract and say this is what we have to deliver. And that might require a completely different kind of specification than for developers. So it's not that easy to mix these two. Now sometimes you need to have the requirements written down so that you can explain them to other stakeholders. And this might be for contracting to your client, but it might also be that you have to write them down to explain them to a user. And a user has often not the same knowledge as for example your developers. So if you write your specification to explain it to an end user, maybe you need to avoid certain kinds of technical terminology. You need to explain in more detail what certain functions are for and so on. So again, you need a completely different level of abstraction for example. And in many cases, requirement specifications are used to document what you have done. So you might have to send this to a regulator to get your software certified or approved that says okay, this is what we have developed. Is this okay? Yes or no? And then they might say well, it looks fine, but you have a breaking function in your car and that needs to be developed in a certain safety process that nothing can go wrong or it can be as good as possible for example. Or a very common way of documentation is this software has to live and be maintained for 10, 20 years. So you need to have some kind of written document that says this is what we developed so that two years later, if you have to change something, you actually have a place to look this up and decide what to change. And that's often a problem if you have an existing system, it's not documented, the requirements are not documented well, then it's very hard to change this because you don't know if you touch one part of the system, other parts might be affected. So that's another purpose. So depending on what you have, you need different kinds of abstractions, you need different kinds of ways of writing your requirements, you need different information. And often this is actually done in different documents or in different sources. So you might have an internal documentation in one tool that is for the developers and maybe for documentation for the future so that you know what you develop and you might have some kind of user manual that explains the requirements to the users and you might have a contracting document for the client so that they can actually sign off what you are going to develop. So these are typical purposes you can probably invent more here. Now how do we do this? By far the most common way is natural language statements. And this means one sentence per requirement that explains what the system shall do. It's these typical, the system shall be offering voice functionality to enable the radio for example. So it's just the natural language as you would write everything else but usually to avoid problems what you do and that's also what Somer will recommend is you invent some kind of standard format. For example this shell, every requirement has to be something like the system shall do X. The system shall do X. And then sometimes you also for example use shell if it's required and you use should if it's more optional but that's already quite a fine distinction. You should avoid some kind of jargon or unclear terminology. So often you tend to use things that are easy to understand from the context for example you are always talking to the client, you do all the contracting, you know all the details but if you do this in a, if you give this to a developer they might not understand that. So it's very important to make sure that every term that you use is clear, is understood by everyone. Now another thing that's very common and that's very problematic is to use and or statements. The system shall offer user commands for radio and something else. So that's basically already two requirements and especially if you use or the system shall use, shall offer voice commands to enable the radio or the lights. Does that actually mean that you have to do both or is it fine to do either? So usually the hardcore requirements engineering people would say don't do these, that's two different requirements. So if you have an and or an or just split it into two sentences and then you have two different requirements. So that's these kind of recommendations you will also find them in the Somerville book. A bit more extreme is to have requirements with a predefined structure. That's something you see for example in embedded systems very often that they have a number of they call them template sentences. So certain words are already fixed and you basically have to fill in the gaps. And these are suitable if you have for example systems that are very similar so you know what kind of requirements there are and you can define them in a certain way. For example embedded systems you always have a number of requirements that are quite similar and they might define, they might use these predefined structures and the reason is simply if you have these predefined structures you can make sure everyone in the organization understands what they mean. If you have free natural language you can write whatever you want. We have the problem that natural language is very ambiguous so one thing written down can mean a lot of different things and that's one of the big problems of specifying requirements. So how can you make sure that everyone understands it in exactly the same way? One way to do so have a predefined structure. One of them which you might know and which we will also use in this course is the so-called user story format. So what this is is a sentence that is called as a persona. I'd like to do and then you have the functionality and then usually you add in order to or so that I can. Now what we have here is the functionality itself. What would the stakeholder like to do? I would like to use voice commands for example so that you remove the do. The next information you have is who exactly would like to do that and finally you have the why of it. So the good thing about this format is in the typical language structure, in the natural language sentences you just have this statement. If you read that it's often very unclear why you need that and for whom this is important and that's the information that's included in this user story format. So you directly tell for example a developer we need this because there is a certain rationale behind it and it's important for this kind of persona, for this kind of stakeholder, for this kind of end user for example. And this is for example how we will write the requirements in the project. It's very common in agile development as well so this is quite a popular format nowadays. Also if you read the Somerville book he also recommends for example in natural language statements to also always include the rationale why is something needed. And the reason is quite simple imagine for example the system is finished, it's developed and five years later someone comes and says we need to change X, we need to add a new functionality, then often it's really hard to decide why are certain things in this system, why did we implement the voice commands, does this make any sense. And then if you know the rationale you can often decide is this something we still need or is this something we need to remove. And the other important thing is it actually tells the developer some kind of details that might help him or her to decide how to implement this. For example if you say as a driver I would like to use voice commands to enable the radio in order to not be for example not be interrupted in my driving. So that as a developer you know the usability is quite important. If the user has to say a lot of different things and has to listen to the response then maybe you are not fulfilling this rationale. They are still being distracted so this is not fulfilled. If you have this extra information you know that okay we need to do this in a certain way. So this is quite a valuable information often. What else do we have? There is something that is called a form based requirement or specification. And that's basically as if you are online and you fill in let's say registration form. It's basically a number of fields that are predefined and very common is for example that every requirement has an ID, a requirement might have a priority, a requirement has some kind of description for example a natural language sentence. So it's just a number of fields that you have to fill in or that are optional. And this is really the standard in all the requirements engineering tools. So usually they use something like this, a natural language statement, a predefined structure, a user story but embedded in a form. So you have to fill this in because there are additional things that might be very important. Now you can do scenarios as mentioned in the elicitation lecture so a description that is a bit more detailed. One of the most common ones are use cases. That's basically just a scenario that describes what is a typical way of using the system. There are different formats for that. If you look up in the summer world book you will find some examples. But often there is for instance a main flow, what is the typical way through the scenario, the success case. For example you describe how you get into the car, how you switch on the car, how you use the voice command, the radio goes on, everything is fine. And then often you have alternative flows that tell you what happens if something goes wrong. For example you go into the car blah blah blah, the system does not understand your voice command, what happens then. The system might answer that you have to say it again or abort the functionality. So the use case is basically a way that describes how does this whole thing work. One thing I don't mention here, this will be coming in the fourth module is graphical specification ways. So you can of course draw models. For example UML models that describe the different requirements will cover that later. But these are all the textual format that we will cover. It's of course just a selection. If you look up in the literature there are a lot more. But these are the common ones that you might find. And quite often if you look at a single document you actually get a combination of these. So you might have a specification that starts with a number of scenarios. It's the important scenarios. But scenarios always have the problem that it's hard to tell what is really required here and what is just sort of extra information or what is something that the person writing has just added. But it's actually not really needed. So it gives you a lot of context. It's very rich. It's very detailed. But it's also hard to tell apart what the requirements are. So you might have a specification that starts with this but then there are the detailed statements that say the system shall allow voice commands. The system shall do something else. The system shall do and so on. So often these are mixed. Similarly the user stories might just be a high level thing to motivate the overall functionality and then you have some detailed ones. Now all of this that I have covered here is for functional requirements. And in the next video I'll go into detail how this looks like for non-functional for quality requirements because you can do similar things but it's often a bit more complicated. So thanks for watching and the next one is on non-functional requirements.