The document defines a System Requirements Specification (SRS) as a written document that captures all functional and non-functional requirements for software deliverables. An SRS provides a complete and structured description of a system's requirements, behavior, and interfaces. It is a contract that translates business needs into a technical format. The SRS includes sections that cover requirements, design constraints, interfaces, and performance criteria. It provides direction for subsequent design and implementation phases.

1. SYSTEMREQUIREMENTS SPECIFICATION (SRS)
SAVYASACHI
MUZAFFARPUR INSTITUTE OF TECHNOLOGY
Muzaffarpur

2. System
Analysis
User Design
Requirements
(Functional +
Non-
functional)
SR
S
2
4/9/2020SAVYA SACHI

3. DEFINITIONS
 SRS is written document which is an output of
Systems Analysis that contains the details of
deliverables to be given with the software to the
user, consisting of all functional and non-
functional requirements.
 A Software Requirements Specification (SRS) is
a specification of the software system which
provides complete and structured description of
the system’s requirements, behaviour, interfaces
including all functional and non-functional
requirements.
3
4/9/2020SAVYA SACHI

4.  SRS is essentially a contract document which
translates business and user processes and
models into an exact format understood by
technical stakeholders of the project.
 It encompasses various sections and sub-
sections to provide sufficient coverage to touch
base all important aspects of project
implementation.
 Once the SRS document is signed-off and
frozen during requirements elaboration phase of
the project, subsequent activities such as detail
design and implementation would start.
 SRS is vital to the s/w as it gives the direction
and fate of the product.
4
4/9/2020SAVYA SACHI

5.  Organizations create SRS documents to
provide the complete requirements for vendors
to implement the s/w system or in case of in-
house development, SRS captures user
requirements in a structured fashion to aid s/w
implementation.
 SRS being formal document communicates all
detailed requirements from end-user/customer
to the software development team. It covers
various kinds of requirements including
functional, operational, resources, interface, 5
4/9/2020SAVYA SACHI

6.  An SRS clearly defines the following:
 External interfaces of the system- It identifies
the information which is to flow ‘from and to’
to the system.
 Functional and Non-functional requirements
of the system. They stand for the finding of
run-time requirements.
 Design constraints
 Performance criteria
6
4/9/2020SAVYA SACHI

7. DIFFERENCE BETWEEN SYSTEM REQUIREMENTS SPECIFICATION AND SOFTWARE
REQUIREMENTS SPECIFICATION
 The fundamental difference b/w a system
specification is that a system specification
provides details about the underlying
hardware and other set-up of the system.
This includes things like system functions,
system drawing/ instructions, system
interface details, hardware safety
requirements etc.; whereas the software
specification is focussed mainly on the
functionality of software like functional use
cases, performance requirements, etc.
7
4/9/2020SAVYA SACHI

8. BENEFITS OF SRS
 Forms the basis of agreement between
customers and suppliers about the s/w
functionality
 Optimizes development effort
 Forms basis for cost and schedule estimation
 Forms basis for verification and validation
 Helps software portability and installation
 Helps in enhancement of the
software/system
 Helps in cost & schedule estimation for 8
4/9/2020SAVYA SACHI

9. KEY CONCERNS OF SRS (AS PER IEEE 830
STANDARD
 Functionality: Complete details of the s/w
 External interface: Details of how the s/w interacts with
external systems, and end users
 Performance: provides details of transaction speed, s/w
availability, response time, failover conditions, disaster
recovery scenario, etc.
 Attributes: provides details about portability, correctness,
maintainability, security, extensibility, flexibility, etc.
 Constraints: All applicable architecture and design
constraints including the max load supported, supported
browsers, JavaScript dependency and others should be
detailed.
9
4/9/2020SAVYA SACHI

10. CHARACTERISTICS OF GOOD SRS
 Simplicity: It should be written using simple english
language and should be easy to understand by people
of varied background.
 Correct: specify functionality correctly, and be updated
continually.
 Unambiguous: statements must not be ambiguous, and
must produce one and only one meaning.
 Precise: It should be collection of jargon and fizzy
words.
 Complete: in all reference from design and
implementation point of view.
 Consistent: terminologies, definitions, symbols, and
others used throughout the SRS must be uniform. All
definitions, abbreviations, notations should be
predefined.
10
4/9/2020SAVYA SACHI

11.  Traceable: it should map the requirements to
other business/user requirement documents so
that it is possible to trace the requirements. It
should provide backward and forward
traceability.
 Modifiability: SRS should be as modifiable as
possible so as to incorporate changes in
requirements as per end users at later stages
too. To ensure this, it should be:
 Be coherent, well-organised, and contain cross
referenccing,
 Avoid redundancy,
 State each requirement separately. 11
4/9/2020SAVYA SACHI

12.  Verifiable: all requirements should be quantified
with exact and verifiable numbers.
 Ranked for importance/stability: based on its
deemed business/user importance.
 Degree of Stability: related to number of changes
required for implementing functionality.
 Degree of importance: requirements are classified into
categories such as essential, conditional and optional.
 Should be design independent
 It should be the translation of analysis and should
lead to design.
 It should contain both functional as well as non-
functional requirements.
 It should contain process logic, inputs and outputs
 It should also contain constraints, security,
reliability, performance issues. 12
4/9/2020SAVYA SACHI

13.  SRS establishes basis of agreement between
the user and the supplier.
 Users needs have to be satisfied, but user may
not understand software
 Developers will develop the system, but may
not know about problem domain
 SRS is the medium to bridge the
communication gap and specify user needs in a
manner both can understand
Need for SRS
13
4/9/2020SAVYA SACHI

14. SRS HELPS
 users understand his needs.
 users do not always know their needs
 must analyze and understand the potential
 the goal is not just to automate a manual
system, but also to add value through it.
 The requirement process helps clarify needs
14
4/9/2020SAVYA SACHI

15.  SRS provides a reference for validation of the final product
 Clear understanding about what is expected.
 Validation - “ SW satisfies the SRS “
 High quality SRS
 essential for high Quality SW
 Requirement errors get manifested in final sw to satisfy the
quality objective,
 must begin with high quality SRS
 Requirements defects are not few
 Good SRS reduces the development cost
 SRS errors are expensive to fix later
 Req. changes can cost a lot (up to 40%)
 Good SRS can minimize changes and errors
 Substantial savings;
 extra effort spent during req.
 saves multiple times that effort
15
4/9/2020SAVYA SACHI

16. IMPACT OF SRS
 Impact on cost and Schedule
 Quality Impact
 Impact on overall customer / user satisfaction
 Impact on maintenance
16
4/9/2020SAVYA SACHI

17. BEST PRACTICES OF WRITING A GOOD QUALITY SRS
 Following factors be comprehended while
authoring a high quality SRS:
 Nature of SRS: Document should follow the
standard structure to ensure that it is understood
and interpreted by all stakeholders.
 Environment of SRS: Background of SRS authors
and the intended audience should be
comprehended to ensure that language, terms are
interpreted consistently.
 Characteristics of SRS: Good characteristics
 Joint preparation of SRS: Independent reviews
should ensure that SRS is coherent and consistent
 SRS Evolution: SRS document should be
continuously updated along with system evolution.17
4/9/2020SAVYA SACHI

18. SAMPLE SRS STRUCTURE / FORMAT (IEEE 830
STANDARD )
 Section 1: Introduction
 Purpose
 Scope
 Definition, Acronym/Abbreviation
 References
 Overview
 Section 2: General Description
 Product Perspective
 Product Functions
 User characteristics
 General constraints
 Assumptions and dependencies
18
4/9/2020SAVYA SACHI

19.  Section 3: Specific Requirements
 External Interface requirements
 Functional Requirements
 Performance requirements
 Design constraints
 Standards compliance
 Logical Database requirements
 Software System attributes
 Reliability
 Availability
 Security
 Maintainability
 Appendices Section 19
4/9/2020SAVYA SACHI

20. SIMPLIFIED (ALTERNATE) SRS FORMAT
1. INTRODUCTION
A. System reference
B. Overall description
C. Software project description
2. INFORMATION DESCRIPTION
A. Information Content representation
B. Information flow representation
(i) Data flow
(ii) Control flow
20
4/9/2020SAVYA SACHI

21. 3. Functional Description (DFD/PSPEC)
A. Functional partitioning
B. Functional Description
1. Processing Narrative
2. Restrictions/limitations
3. Performance requirements
4. Design constraints
5. Supporting diagrams
C. Control Description (CFD/CSPEC)
1. Control Specification
2. Design constraints
4. Behavioural escription (STD)
A. System States
B. Events and actions
5. Validation and Criteria
A. Performance bounds
B. Classes of Tests
C. Expected software response
D. Special consideration
6. Bibliography
7. Appendix
21
4/9/2020SAVYA SACHI

22. Thanks
22
4/9/2020SAVYA SACHI