 So, in this lecture, we'll start learning about software requirements engineering. And I will show to introduce the basic concept and main types of requirements. Let's take an example. A client meets a software engineer and tries to explain what he needs. Most likely, the client doesn't know precisely what he specifically needs. He knows that he would like to have a program or system that would increase productivity, extend functionality, or achieve any other goal. But how to do that, the client doesn't know. This should be investigated and clarified by both sides. Sometimes, a client has some wishes that he is not aware of them yet. On the other hand, the engineer should make sure that the program ensures all system or program functionalities in the most efficient and appropriate way. Requirement engineering is the process where we define what system or product has to be created for the client. During the requirement engineering process, we create a document of requirements where everything is described in detail, what needs to be created, and how, within various constraints. Requirements may range from high-level abstract statements to detailed mathematical functional specifications. In the previous example, you probably have already understood why requirement engineering is needed. Well, here requirements serve as a dual function, as an object for negotiating a price or represents the contract itself. There are two types of requirements, user requirements and system requirements. User requirements are created for clients to make sure that they will understand how the system works. It can be provided in statements of natural language and diagrams of services. System requirements mostly specify user requirements by showing how everything should be implemented. For better understanding, let's take an example. Here, in user requirements, only one sentence is presented. A learning management system needs to be created that should generate a monthly student activity report, while system requirements specification shows what needs to be implemented in the system to accomplish user requirements. In this example, the report table shall include student information, module information, activity duration. Also, shall be possible to generate separate reports and other things. In this slide, you can see a diagram that shows who reads the user requirements and system requirements. Client manager, contract manager, client engineer, system final user, system architect can read and understand the user requirements, while only client engineers, system architects and developers are interested in system requirements. Usually, a system architect is an intermediary who knows and understands all requirements from both sides. Another important thing to know is what a system stakeholder is. Basically, it can be any person or organization who is affected by the system in some way and who has a legitimate interest. It includes users, system managers, system owners or external stakeholders. For example, if you consider the university academic system, the final users are students and lecturers. System managers could be people from student department. Technical support most likely would be provided by the department of information technologies. And maybe some system reports could be provided to government institutions. In other words, external stakeholders. To create this type of system is a complicated task because there are many stakeholders and all could have their own requirements that make conflict. Now, what about agile? As you may already know, there are no such things like user or system requirements. Well, many agile supporters argue that producing detailed system requirements is a waste of time as requirements change so quickly. They state that there can only be one source of requirements so-called user stories. Question is whether it is good or not. In practice, it is good for business systems. However, it might be problematic for systems that require pre-delivery analysis, for example, critical systems or systems developed by several teams. Key points of this lecture. And engineering is the process of establishing the service that a customer requires from the system. System stakeholder is any person or organization who is affected by the system in some way and who has legitimate interest. There are user and system requirements. Agile approach use the so-called user stories. It is the single source of the requirements. Thank you for your attention and see you soon.