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.

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