Unit_1_Application-Development-and-Emerging-Technologies-Copy.docx

**Unit 1** ---------- **Requirement Analysis and Modeling** ------------------------------------- Image result for introduction icons round **Introduction** ---------------------------------------------------------- Requirement Analysis and Modeling are significant steps in developing any kinds o...

**Unit 1** ---------- **Requirement Analysis and Modeling** ------------------------------------- Image result for introduction icons round **Introduction** ---------------------------------------------------------- Requirement Analysis and Modeling are significant steps in developing any kinds of software. It reviews all requirements and provides a graphical view of the entire system using diagrams. After the completion of the analysis, it is expected that the understandability of the project may improve significantly. This unit covers the topics on Software Requirement Specification, Steps in Requirement Analysis, Data Flow Diagram and Entity Relationship Diagrams, and create Data Dictionaries Files.  **Unit Learning Outcomes** ------------------------------------------------------------- By the end of the unit, students should be able to: 1. Understand the importance of Software Requirements Specification Report in developing system application. 2. Make a graphical view of frontend and backend structural design of the system by creating a model using ERD and DFD. 3. Create a Data Dictionaries Files for database design. 4. Write a System Analysis Report. Image result for lightbulb icons **Activating Prior Knowledge** --------------------------------------------------------------- 10 items Diagnostic Test **Topic 1: Software Requirement Specification** ----------------------------------------------- Time Allotment: 1 Hour  **Learning Objectives** ---------------------------------------------------------- At the end of this unit, students will be able to - Understand the importance and use of Software Requirements Specification Report in Software Development - Learn the different features and properties of a good SRS Document - Construct a Software Requirements Specification Report C:\\Users\\Dell\\Desktop\\note-512.png **Presentation of Contents** ------------------------------------------------------------------- The production of the requirements stage of the software development process is Software Requirements Specifications (SRS) (also called a requirements document). This report lays a foundation for software engineering activities and is constructing when entire requirements are elicited and analyzed. SRS is a formal report, which acts as a representation of software that enables the customers to review whether it (SRS) is according to their requirements. Also, it comprises user requirements for a system as well as detailed specifications of the system requirements. The SRS is a specification for a specific software product, program, or set of applications that perform particular functions in a specific environment. It serves several goals depending on who is writing it. First, the SRS could be written by the client of a system. Second, the SRS could be written by a developer of the system. The two methods create entirely various situations and establish different purposes for the document altogether. The first case, SRS, is used to define the needs and expectation of the users. The second case, SRS, is written for various purposes and serves as a contract document between customer and developer. **Software Requirement Specification Report Sample Content** 1. Introduction. 2. Functional data description. 3. Subsystem description. 4. System modeling and simulation results. 5. Products. 6. Appendices. **Types of Requirements** The two types of requirements are 1. Functional requirements: a. input/output b. Processing. c. Error handling. 2. Non-functional requirements: d. Physical environment (equipment locations, multiple sites, etc.). e. Interfaces (data medium etc.). f. User & human factors (who are the users, their skill level etc.). g. Performance (how well is system functioning). h. Documentation. i. Data (qualitative stuff). j. Resources (finding, physical space). k. Security (backup, firewall). l. Quality assurance (max. down time, MTBF, etc.). **Characteristics of good SRS**  **Following are the features of a good SRS document:** 1\. **Correctness**: User review is used to provide the accuracy of requirements stated in the SRS. SRS is said to be perfect if it covers all the needs that are truly expected from the system. 2\. **Completeness**: The SRS is complete if, and only if, it includes the following elements: 3\. **Consistency**: The SRS is consistent if, and only if, no subset of individual requirements described in its conflict. There are three types of possible conflict in the SRS: 4\. **Unambiguousness**: SRS is unambiguous when every fixed requirement has only one interpretation. This suggests that each element is uniquely interpreted. In case there is a method used with multiple definitions, the requirements report should determine the implications in the SRS so that it is clear and simple to understand. 5\. **Ranking for importance and stability**: The SRS is ranked for importance and stability if each requirement in it has an identifier to indicate either the significance or stability of that particular requirement. Typically, all requirements are not equally important. Some prerequisites may be essential, especially for life-critical applications, while others may be desirable. Each element should be identified to make these differences clear and explicit. Another way to rank requirements is to distinguish classes of items as essential, conditional, and optional. 6\. **Modifiability:** SRS should be made as modifiable as likely and should be capable of quickly obtain changes to the system to some extent. Modifications should be perfectly indexed and cross-referenced. 7\. **Verifiability:** SRS is correct when the specified requirements can be verified with a cost-effective system to check whether the final software meets those requirements. The requirements are verified with the help of reviews. 8\. **Traceability:** The SRS is traceable if the origin of each of the requirements is clear and if it facilitates the referencing of each condition in future development or enhancement documentation. ***There are two types of Traceability:*** The forward traceability of the SRS is especially crucial when the software product enters the operation and maintenance phase. As code and design document is modified, it is necessary to be able to ascertain the complete set of requirements that may be concerned by those modifications. 9\. **Design Independence**: There should be an option to select from multiple design alternatives for the final system. More specifically, the SRS should not contain any implementation details. 10\. **Testability**: An SRS should be written in such a method that it is simple to generate test cases and test plans from the report. 11\. **Understandable by the customer**: An end user may be an expert in his/her explicit domain but might not be trained in computer science. Hence, the purpose of formal notations and symbols should be avoided too as much extent as possible. The language should be kept simple and clear. 12\. **The right level of abstraction**: If the SRS is written for the requirements stage, the details should be explained explicitly. Whereas,for a feasibility study, fewer analysis can be used. Hence, the level of abstraction modifies according to the objective of the SRS. **Properties of a good SRS document** The essential properties of a good SRS document are the following: **Concise:** The SRS report should be concise and at the same time, unambiguous, consistent, and complete. Verbose and irrelevant descriptions decrease readability and also increase error possibilities. **Structured:** It should be well-structured. A well-structured document is simple to understand and modify. In practice, the SRS document undergoes several revisions to cope up with the user requirements. Often, user requirements evolve over a period of time. Therefore, to make the modifications to the SRS document easy, it is vital to make the report well-structured. **Black-box view:** It should only define what the system should do and refrain from stating how to do these. This means that the SRS document should define the external behavior of the system and not discuss the implementation issues. The SRS report should view the system to be developed as a black box and should define the externally visible behavior of the system. For this reason, the SRS report is also known as the black-box specification of a system. **Conceptual integrity:** It should show conceptual integrity so that the reader can merely understand it. Response to undesired events: It should characterize acceptable responses to unwanted events. These are called system response to exceptional conditions. **Verifiable:** All requirements of the system, as documented in the SRS document, should be correct. This means that it should be possible to decide whether or not requirements have been met in an implementation. **Software Requirement Specification Example:** Please click this link: [click here](srs_document_for_hotel_management_system.docx) Image result for learning activity round icons **Application** -------------------------------------------------------------- Think of a System for a company (example: Bus Reservation, E-commerce, and Online Registration) and enlist its Product Functions and Functional Requirements. Please read the page 4 to 6 of the Software Requirement Specification Example above to learn how to do this activity. **Topic 2: Steps in Requirement Analysis** ------------------------------------------ Time Allotment: 30 mins  **Learning Objectives** ---------------------------------------------------------- At the end of this unit, students will be able to Understand the different Steps in Requirement Analysis C:\\Users\\Dell\\Desktop\\note-512.png **Presentation of Contents** ------------------------------------------------------------------- Requirement analysis is significant and essential activity after elicitation. We analyze, refine, and scrutinize the gathered requirements to make consistent and unambiguous requirements. This activity reviews all requirements and may provide a graphical view of the entire system. After the completion of the analysis, it is expected that the understandability of the project may improve significantly. Here, we may also use the interaction with the customer to clarify points of confusion and to understand which requirements are more important than others. **Analysis Objectives** - Identify customer's needs. - Evaluate system for feasibility. - Perform economic and technical analysis. - Allocate functions to system elements. - Establish schedule and constraints. - Create system definitions.  1. **Draw the context diagram**: The context diagram is a simple model that defines the boundaries and interfaces of the proposed systems with the external world. It identifies the entities outside the proposed system that interact with the system. The context diagram of student result management system is given below: 2. **Development of a Prototype (optional)**: One effective way to find out what the customer wants is to construct a prototype, something that looks and preferably acts as part of the system they say they want. A. Throwaway Prototyping i. prototype only used as a demonstration of product requirements ii. finished software is engineered using another paradigm B. Evolutionary Rapid Prototyping iii. prototype is refined to build the finished system 3. **Model the requirements:** This process usually consists of various graphical representations of the functions, data entities, external entities, and the relationships between them. The graphical view may help to find incorrect, inconsistent, missing, and superfluous requirements. Such models include the Data Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-transition diagrams, etc. a. **Data model** - shows relationships among system objects b. **Functional model** - description of the functions that enable the transformations of system objects c. **Behavioral model** - manner in which software responds to events from the outside world 4. **Finalise the requirements**: After modeling the requirements, we will have a better understanding of the system behavior. The inconsistencies and ambiguities have been identified and corrected. The flow of data amongst various modules has been analyzed. Elicitation and analyze activities have provided better insight into the system. Now we finalize the analyzed requirements, and the next step is to document these requirements in a prescribed format.