 Hello. Welcome to the session on Software Requirement Analysis and Specification in SRS Document. At the end of this session, students will be able to analyze the problems by following the requirement process steps. Next, we will discuss about the requirement process, how we can do the analysis of the requirement process. There are sequence of steps that need to be performed to convert the user needs into the SRS document. So this requirement process that helps to elicit the needs and requirements and also to clearly specify it. The basic activities that are involved in the requirement process are problem analysis or the requirement analysis of a customer or the user, requirement specification descriptions or the product descriptions, then validation. So the analysis involves the elicitation and it is the very difficult or hardest step. The elicitation means to discover the details about the problem or to discover the more information about the problem or the customer problem. So analysis that involves a difficult task because it requires experience or business analyst to understand the problem or to collect the details. Let us discuss the requirement process steps. As you can see, the client or the user needs are collected and it is analyzed and this process, the analysis and specification, it is not linear. It is iterative and parallel. So there is a overlap between the phases. Some parts may be analyzed and some parts may be specified. So specification itself that may help the analysis and validation that can show the gap that can lead to further analysis and specification. So these are the steps. After collecting the user requirements, we need to analyze, then specify the requirements and validation. So we will get a final validated SRS document. The requirement process that mainly focuses on analysis is to understand the desired systems and its requirements. So to understand the requirement analysis, we go for the divide and conquer strategy. Divide the problem into small tasks and small parts. So understand each part and the relationship between the parts. So this divide and conquer strategy. So for this we use some techniques like data flow diagram, object diagram, ER diagrams for the analysis. Transition from analysis to specification is hard. So in specification, the external behavior is specified but during the analysis, structure and domain are need to understand. So the analysis structure helps in specification but the transition is not a final. The methods of analysis are similar to that of design but objective and scope are different. Analysis that deals with the problem domain whereas the design that deals with the solution domain. Analysis where we mainly concentrate on the problem, what is the customer problem or client problem whereas in the design part we find the solution of the problem. Let us discuss the problem analysis that problem analysis aims to obtain a clear understanding of the needs, requirements and constant on the software. Analysis involves the following steps. Interviewing the clients and the users to collect the requirements. Reading the manuals or reading the details about the particular problem statement. Studying the current existing systems. Helping the clients or user to understand the new possibilities or to new functionalities like becoming a consultant. So problem analysis that includes these various steps to collect the requirements. The sum of the issues are obtaining the necessary information, brainstorming, interacting with the clients to establish desired properties. So to collect the requirements, to ask different questions, information organization as large amount of information gets collected. So that ensures the completeness. So these are all the some issues that the organization or the one who was collecting the requirement has to handle. Interpersonal issues are very important to maintain the relationship with the client or to get the data or to get the requirements from the users. Communication skills are very important and the basic principle is to problem partition. So based upon the problem partition we understand the problem and we collect the requirements. The informal approach to the analysis. No defined methodology. Here the information about the system is obtained through some analysis or observation or discussion or study of some existing documents. So it is all the informal approach. There is no formal model of the system is built. This is obtained in the obtained informations are organized in the SRS and SRS document is reviewed with the clients. It relies on the analyst experience and the feedback from the client in reviews. So it also useful in many contexts. So informal approach where we collect the data or the information about the system in a informal way. And data flow modeling is a technique where we analyze the system or we analyze the problem statement and how the data will flow from one module to another module or how the data is consumed and produced by the system. So it is a top down requirement approach or called a structured analysis specification. So it views the system as a network of data transforms through which the data flows. So the data flow diagrams the technique we use to represent the data flow from one module to another from input to the output stages. Uses the data flow diagrams and functional decomposition in the modeling. Next method is structured system analysis and design method. It mainly focus on analysis of a problem and it is used a lot when automating the existing manual system. The main steps involved are to draw the context diagram of a existing system and draw the data flow diagram of the existing system. Draw the data flow diagram of the proposed system and identify the man machine boundary. So this context diagram data flow diagram are mainly helpful to represent the data and to understand how the data flow from one module to another module or one stage to another stage. Another problem analysis technique is called as entity relationship diagram. So the data models are used in analysis to describe the data requirements and assumptions in the system from top down perspective. It sets the stage for a design of databases later on the software development lifecycle. Let us pause the video for a while and the final output of the requirement task is the SRS document. As we go with the different analysis stages and all from in the requirement from requirement collecting the requirements. But the final output of requirement task is the SRS document. Why are data flow diagram object oriented models here diagram? Why these are not SRS? Let us pause the video and answer the question. The final output of the requirement task is the software requirement specification document. Why these data flow diagram objects are not SRS is because SRS focuses on external behavior while modeling focus on the problem structure. User interface are not modeled but have to be in the SRS. Error handling constraints are also needed in the SRS. So these are data flow diagram object modeling. These are all mainly focused on the problem structure. So transition from analysis to specification is not a straight forward. So it involves so many steps. Knowledge about the system acquired in analysis used in the specification. So these are the references I have referred. Thank you.