SOFTWARE REQUIREMENT
SPECIFICATION
Lecture-5
INTRODUCTION
Without a map it can get tough traveling to a new
city or country. You wouldn’t know what transport
to take or which direction to travel in, making it
almost impossible to reach your destination.
Similarly, in software development, you are
unable to create the right product without
proper documentation of software
requirements.
SRS document is one of the most critical documents in
software development. It describes how a software
system should be developed. Simply put, an SRS
provides everyone involved with a roadmap for that
project.
A software requirements document (also known as software requirements
specifications) is a document that describes the intended use-case, features, and
challenges of a software application.
These documents are created before the project has started development in
order to get every stakeholder on the same page regarding the software’s
functionality.
WHY IS AN SRS DOCUMENT IMPORTANT?
An SRS document describes what a client wants and what
developers will provide. It is the written agreement on every
detail of the product.
Having a clear set of requirements ensures that a
development team creates software that meets the clients’
needs. An SRS will help with estimating the cost of work
and covering the project scope. It also gives coders an idea of
the tech stack they’ll need and helps them plan their work,
WHY IS AN SRS DOCUMENT IMPORTANT?
An SRS is important because it is a single source of information
and expectations, which prevents misunderstandings between
project managers, developers, designers, and testers.
1. Designers get project insights through SRS documents so
they can match the design to the use case.
2. Testers get the guidelines for creating test cases that match
the business’s needs.
3. End-users use the SRS to understand the software.
4. It provides investors with an overview of the system’s
features so they can make investment decisions.
WHAT DOES AN SRS INCLUDE?
An SRS document typically includes these elements:
The purpose of the software being developed
An overall description of the software
The functionality of the software or what it is supposed to do
Performance of the software in a production situation
Non-functional requirements
External interfaces or how the software will interact with hardware or other
software it must connect to
Design constraints or the limitations of the environment that the software will run
in
HOW TO WRITE A SOFTWARE REQUIREMENT SPECIFICATION
DOCUMENT
six steps involved in creating an SRS document in software engineering:
1. Create an Outline
The first step in the process is to create an outline for SRS document. You can create this
yourself or use an existing SRS template as a starting point. Here is a basic example of an
SRS outline:
1. Introduction
2. Purpose
3. Intended Audience
4. Intended Use
5. Scope
6. Definitions
7. Overall Description
8. User Needs
9. Assumptions and Dependencies
10. System Features and Requirements
a) Functional Requirements
b) External Interface Requirements
c) System Features
d) Non-functional Requirements
2. Define the Purpose
1. Define the product’s scope
2. Describe the value it will deliver
3. Show who will use the software
4. Detail how it will help with the intended users’ job
3. Give an Overview
After defining the product’s purpose, summarize how it will work.
Here you will give a general description of the software’s features
and how they fit the user’s needs.
4.Describe Functional and Non-functional
Requirements
Describe the functional requirements in enough detail so
developers can get to work and the non-functional requirements
like security specifications and performance.
5. Add Supplemental Details
The last step in creating the draft of SRS document in software
engineering is adding any details that could help developers finish
the job in the form of appendixes, glossaries of terms, and
references.
6. Get Approval
Once you have added enough details to the SRS to describe what
the system is supposed to do, it is time to have the stakeholders
approve the document.
HOW TO WRITE SOFTWARE USE CASES IN AN SRS
SRS TEMPLATE
THE FOLLOWING IS A SIMPLE SRS TEMPLATE:
Table of Contents
1. Introduction
1.1 Purpose of this document
1.2 Scope of this document
1.3 Overview
1.4 Business Context
2. General Description
2.1 Product Functions
2.2 Similar System Information
2.3 User Characteristics
2.4 User Problem Statement
2.5 User Objectives
2.6 General Constraints
3. Functional Requirements
3.1. what system will do
3.2. List of services the system should provide
3.3. List of services/ functions which user want
from software
3.4
4. Interface Requirements
4.1 User Interfaces
4.2 Hardware Interfaces
4.3 Communications Interfaces
4.4 Software Interfaces
5. Performance Requirements
• Response Time
• Workload
• Scalability
• Platform
6. Other non-functional attributes
6.1 Security
6.3 Reliability
6.4 Maintainability
6.5 Portability
6.6 Extensibility
6.7 Reusability
6.8 Application Affinity/Compatibility
7. Operational Scenarios
1. Description of an imagined sequence of events that
includes the interaction of the product or service with
its environment and users, as well as interaction among
its product or service components.
2. A set of actions or functions representing the dynamic
of exchanges between the functions allowing the
system to achieve a mission or a service.
3. Stories which describe the expected utilization of the
future system in terms of actions.
8. Preliminary Use Case Models and Sequence
Diagrams
8.1 Use Case Model
8.2 Sequence Diagrams
10. Appendices
10.1 Definitions, Acronyms, Abbreviations
10.2 References
Software Requirements Document
1. Introduction
1.1 Purpose: Set the expectations for the outcome of the product.
1.2 Intended Audience: Who is the software for? Who is the end-user? Will the software
be used internally at a company or externally?
1.3 Intended Use: What is the software for? What problem is it solving?
1.4 Scope: Explain the scope of the software. What are the main goals and objectives?
How do they relate to the company’s goals?
1.5 Definitions and Acronyms: Provide an overview of any definitions the reader
should understand before reading on.
2. Overall Description: Describe what you are building and for who.
2.1 User Needs: Explain the user needs for this software.
2.2 Assumptions and Dependencies: What assumptions are you making that could
cause an error in your approach? Is the project reliant on any other factors that could
affect the development of the software?
3. System Features and Requirements
3.1 Functional Requirements: Take time to define the functional requirements that
are essential for the software to build.
3.2 External Interface Requirements: Are there any UX and UI requirements that
you must keep in mind as you build?
3.3 System Features: What features are required for the software to even work.
3.4 Nonfunctional Requirements: Are there any non-functional requirements that you
need to address (i.e. budget, team, etc.)
FEATURES OF AN SRS
An SRS should have following characteristics:
• Correct -- should accurately reflect product functionality and specification at
any point of time.
• Unambiguous -- should not be any confusion regarding interpretation of the
requirements.
• Complete -- should contain all the features requested by a client.
• Consistent -- same abbreviation and conventions must be followed throughout
the document.
• Ranked for importance and/or stability -- every requirement is important.
But some are urgent and must be fulfilled before other requirements and some
could be delayed. It’s better to classify each requirement according to its
importance and stability.
• Verifiable -- an SRS is verifiable only if every stated requirement can be
verified. A requirement is verifiable if there is some method to quantifiably
measure whether the final software meets that requirement.
• Modifiable -- an SRS must clearly identify each and every requirement in a
systematic manner. If there are any changes, the specific requirements and the
dependent ones can be modified accordingly without impact the others.
• Traceable – an SRS is traceable if the origin of each of its requirements is
clear and if it makes it easy to reference each requirement in future
development.
THE GOALS OF AN SRS
1. Provide feedback to the customer, ensuring that the IT
company understands the issues the software system
should solve and how to address those issues.
2. Help to break a problem down into smaller components
just by writing down the requirements.
3. Speed up the testing and validation processes.
4. Facilitate reviews.
