 Hello, welcome to the session on identifying the requirements from problem statement. At the end of this session, students will be able to identify ambiguities in consistency and incompleteness from the given requirement specification, and also identify and state the functional requirements and non-functional requirements. Let us discuss about the requirements. Somerville defines a requirement as a specification of what should be implemented. Requirement specifies how the target system that should behave. It specifies what to do, but not how to do. Requirements engineering refers to the process of understanding what a customer expects from the system to be developed, and to document them in a standard and easily readable and understandable format. This documentation will serve as a reference for the subsequent design, implementation, and verification of the system. It is necessary and important that before we start planning, designing, and implementation of the software system for our clients, we are clear about its requirement. If we don't have a clear vision of what is to be developed and what all the features are expected, there would be serious problems and the customer dissatisfaction as well. Let us discuss the characteristics of requirements. Requirements gathered for any new system to be developed should exhibit the following three properties, that is, unambiguity, consistency, and completeness. There should not be any ambiguity what a system to be developed should do. For example, consider you are developing a web application for your client. The client requires that enough number of people should be able to access the application simultaneously. What is this enough number of people? That could mean 10 number to you, but perhaps 100 to the client. So there is an ambiguity in the requirement statement. To illustrate this, consider the automation of a nuclear plant. Suppose one of the clients says that the radiation level inside the plant that exceeds the R1, all reactors should shut down. However, another person from the client side suggests that the threshold radiation level should be R2, thus there is an inconsistency between the two end users regarding what they consider as a threshold level of radiation. Next is the completeness. A particular requirement for a system should specify what the system should do and also what it should not. For example, consider a software to be developed for the ATM machine. If the customer enters an amount that is greater than the maximum permissible withdrawal amount, the ATM should display an error message and it should not dispense any cash. So there should be a complete requirement. Next we will discuss about categorization of requirements. Based on the target audience or the subject matter, the requirements can be classified into different types that is user requirements, system requirements. Next the categorization of the requirements that is classified into two groups based on what they describe that is functional requirements and non-functional requirements. So functional requirements, these describe the functionality of the system, how a system should react to a particular set of inputs and what should be the corresponding output. In the non-functional requirements they are not directly related to what the functionalities are expected from the system. However, non-functionality requirements could typically define how the system should behave under certain situations. For example, a non-functionality requirement could say that the system should work with for example, 128 MB RAM, 512 MB RAM. So under such condition, a non-functionality requirement could be more critical than a functionality requirement. Non-functionality requirements that could be further classified into different types like product requirements, for example, a specification that web application should use only the HTML5 and no frame sets. So performance requirement, for example, the system should remain available for 24x7 and organizational requirements, the development process should compile to the Software Engineering Institute Capability Maturity Model Level 4. Let us discuss the case study, a library information system. Here we will identify the functional requirements and non-functional requirements. So identify the high level functional requirements simply from the conceptual understanding of the problem. For example, a library management system, apart from anything else, should be able to issue and return books. For example, in digital library, a user might use the search book or any other functionalities to obtain the information, the books of his interest. So any high level requirement is identified, they could have the different sub-requirements. So after identifying the requirements, prepare a SRS document. So once all possible, the functional requirements and non-functional requirements have been identified which are complete, consistency, non-ambiguous, the requirement, specification document is to be prepared. The SRS is prepared by the service provider and verified by its client. This document serves as a legal agreement between the client and the service provider. So let us discuss the continuation with the library information system. Problem statement, as the size and capacity of the institute is increasing with the time, it has been proposed to develop a library information system for the benefit of students and employees of the institute. The system also enables a member to extend the date of his borrowing, if no other booking for that particular book has been made for the library staff. This system aids them to easily handle day-to-day books transaction. The librarian who has administrative privilege and complete the control over the system can enter a new record into the system when a new book has been purchased or removed, a record in case of any book is taken off the shelf. Any non-member is free to use this system to browse or search the books online. However, issuing or returning books is restricted to valid users or the members of library information system only. So the above problem statement that gives a brief discussion of the proposed system from the above, even without doing any deep analysis, we might easily identify some of the basic functionality of the system, that is new user registration, search book, user login. So new user registration, any member of the institute who wishes to avail the facilities of the library has to register himself with the library information system. On successful registration a user ID and password would be provided to the member and he has to use these credentials for any future transaction in library information system. Search book, any member of the library information system can avail this facility to check whether any particular book is present in the institute library. A book could be searched by its title, author name, publisher's name. User login, a registered user of the library information system can login to the system by providing his employee ID and password as is set by him while registering. So most of the functionality that would be available to the registered member, the new user registration would however be available to non-members, moreover an already registered user should not be allowed to register himself once again. So having identified the major functionality requirements, we assign the identifier to each membership. So we need to give a unique identifier for the future reference and verification. So following table that shows the number of requirements, their unique ID and also the priority, high priority or low priority of the requirements. Then next identify the non-functionality requirement of library information system. So following are the non-functional requirements, that is performance requirement, the system should remain accessible to 24 by 7, security requirements, software quality attributes, database requirements and design constraints. So these are the non-functional requirements. So let us pause the video for a while, answer the question. So resume the video and the answer for this question, when is feasibility study is done? So the answer is, before the final requirement specifications are done, the feasibility study is done for any software system. Next pause the video and answer the question. A good requirement specification is the one which is. So let us resume the video, the answer is all of the above. All these are the characteristics of the requirement. The requirement should be consistent, complete and unambiguous. So these are the references I referred. Thank you.