2.software requirement specification
Download as PPTX, PDF9 likes7,898 views
This document outlines a software requirement specification (SRS) for a software system. It defines what an SRS is, including that it provides a complete description of the system's behavior and documents interactions between users and the software. The document also describes the key components of an SRS, including functionality, objectives, requirements, and constraints. It explains that an SRS is important as the official contract between developers and users, and serves as the basis for further system development. Finally, it provides an outline for the structure and contents of a full SRS document.
2.software requirement specification
- 1. SOFTWARE REQUIREMENT SPECIFICATION DEEPAK SHARMA 12KSSB6031 BCA 5th sem
- 2. Introduction software requirements are high level abstract statements of services that the system should provide. It is a formal description of the system function. A software requirement provides a blueprint for the development of a software product.
- 3. Software Requirements Specification (SRS) A requirements specification for a software system is a complete description of the behaviour of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. It is a structured document setting out detailed description of the system services written as a contract between client and contractor. Software requirements is a sub-field of software engineering that deals with the elicitation, analysis, specification,validationof requirements for software.
- 4. COMPONENTS OF SRS Functionality Environment Description and System Objectives Project Management System Delivery and Installation Requirements Functional Constraints Design Constraints
- 5. IMPORTANCE OF SRS 1. It is the official documents. 2. It resolves the conflict between user and developer. 3. Based on SRS further development of the system takes place. 4. It is the fundamental document, bridges the gap between users requirement and developers view.
- 6. GOALS OF SRS It provides feedback to the customer. It decomposes the problem into component parts. It serves as an input to the design specifications. It serves as a product validation check. SRS serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.
- 7. OUTLINE OF SRS 1 introduction 1.1 1.2 1.3 1.4 1.5 Purpose Scope Definition, acronyms and abbreviation. Reference Overview 2 System description 2.1 2.2 2.3 2.4 2.5 2.6 Product perspective Product functions User function System constraints System dependencies Requirements sub-domain 3 Specific system requirement 3.1 3.2 3.3 Function requirements Non-functional requirements External interfaces 4 Appendices 5 Index
- 8. STRUCTURE OF SRS Chapter no. 1 Preface It briefly explains about project. Chapter no. 2 Introduction Highlights the projects with its title and briefly describe the projects. Chapter no. 3 Scope What is the capability of the product? Chapter no. 4 Glossary Definition, acronyms and abbreviation. Chapter no. 5 User requirement definition Describes non-functional requirements Chapter no. 6 Architecture Specifies system architecture Chapter no. 7 System requirements System description with function and non-function requirement. Chapter no. 8 System model System model used to represent relationship. Chapter no. 9 System evaluation How system is evolved? Chapter no. 10 Appendices Annexure, application, data requirements. Chapter no. 11 indexes Indices of diagram, tables, functions.
- 9. Importance of SRS SRS is the contract between the development team and the customer. It is known as the BLACK-BOX specification since it mainly concentrates on what needs to be done and carefully avoids the “how to do” aspects. It is the formal and official document. It resolves the conflict between user and developer. Based on SRS, further the development of the system takes place. It is the fundamental document that bridges the gap between user requirements and developers view.
- 10. THANK YOU