What is SRS?

A software requirements specification (SRS) is a description of a software

system to be developed. It lays out functional and non-functional
requirements and may include a set of use cases that describe user
interactions that the software must provide.
Software Requirement Specification (SRS) Format is a complete
specification and description of requirements of the software that need to
be fulfilled for the successful development of the software system. These
requirements can be functional as well as non-functional depending upon
the type of requirement. The interaction between different customers and
contractors is done because it is necessary to fully understand the needs
of customers.
Depending upon information gathered after interaction, SRS is developed
which describes requirements of software that may include changes and
modifications that is needed to be done to increase quality of product and
to satisfy customer’s demand.
SRS’s characteristics include:
 Correct
 Unambiguous
 Complete
 Consistent
 Ranked for importance and/or stability
 Verifiable
 Modifiable
 Traceable
Description
 Complete: The SRS should include all the requirements for the
software system, including both functional and non-functional
requirements.
 Consistent: The SRS should be consistent in its use of terminology
and formatting, and should be free of contradictions.
 Unambiguous: The SRS should be clear and specific, and should
avoid using vague or imprecise language.
 Traceable: The SRS should be traceable to other documents and
artifacts, such as use cases and user stories, to ensure that all
requirements are being met.
 Verifiable: The SRS should be verifiable, which means that the
requirements can be tested and validated to ensure that they are
being met.
 Modifiable: The SRS should be modifiable, so that it can be updated
and changed as the software development process progresses.
  Prioritized: The SRS should prioritize requirements, so that the most
important requirements are addressed first.
 Testable: The SRS should be written in a way that allows the
requirements to be tested and validated.
 High-level and low-level: The SRS should provide both high-level
requirements (such as overall system objectives) and low-level
requirements (such as detailed functional requirements).
 Relevant: The SRS should be relevant to the software system that is
being developed, and should not include unnecessary or irrelevant
information.
 Human-readable: The SRS should be written in a way that is easy
for non-technical stakeholders to understand and review.
 Aligned with business goals: The SRS should be aligned with the
overall business goals and objectives of the organization, so that the
software system meets the needs of the business.
 Agile methodologies: Agile methodologies, such as Scrum and
Kanban, provide an iterative approach to requirements capturing
and validation, where requirements are captured and validated in
small chunks of functionality and feedback is gathered from the
customer.

The important parts of the Software Requirements Specification

(SRS) document are:
1. Functional requirements of the system
2. Non-functional requirements of the system, and
3. Goals of implementation
These are explained as follows.
Functional Requirements
The purposeful requirements part discusses the functionalities needed
from the system.
1. The system is taken into account to perform a group of high-level
functions Fi. The functional view of the system is shown in the below
diagram
2. Each function Fi of the system can be considered as a transformation
of a set of input data Ii to the corresponding set of output knowledge
Oi.
The main types of Software Requirements are functional, non-functional,
and domain requirements.

What is Software Requirements?

 A condition or capability needed by a user to solve a problem or
achieve an objective
 A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification or other
formally imposed documents
 A documented representation of a condition or capability, as in 1 and 2.
Types of Software Requirements
Software Requirements are mainly classified into three types:
 Functional requirements
 Non-functional requirements
 Domain requirements
1. Functional Requirements
Definition: Functional requirements describe what the software should
do. They define the functions or features that the system must have.
Examples:
 User Authentication: The system must allow users to log in using a
username and password.
 Search Functionality: The software should enable users to search for
products by name or category.
 Report Generation: The system should be able to generate sales
reports for a specified date range.
Explanation: Functional requirements specify the actions that the
software needs to perform. These are the basic features and
functionalities that users expect from the software.
2. Non-functional Requirements
Definition: Non-functional requirements describe how the software
performs a task rather than what it should do. They define the quality
attributes, performance criteria, and constraints.
Examples:
 Performance: The system should process 1,000 transactions per
second.
 Usability: The software should be easy to use and have a user-friendly
interface.
 Reliability: The system must have 99.9% uptime.
 Security: Data must be encrypted during transmission and storage.
Explanation: Non-functional requirements are about the system’s
behaviour, quality, and constraints. They ensure that the software meets
certain standards of performance, usability, reliability, and security.
3. Domain Requirements
Definition: Domain requirements are specific to the domain or industry in
which the software operates. They include terminology, rules, and
standards relevant to that particular domain.
Examples:
 Healthcare: The software must comply with HIPAA regulations for
handling patient data.
 Finance: The system should adhere to GAAP standards for financial
reporting.
 E-commerce: The software should support various payment gateways
like PayPal, Stripe, and credit cards.
Non-functional requirements are classified into the following types:
 Interface constraints
 Performance constraints: response time, security, storage space, etc.
 Operating constraints
 Life cycle constraints: maintainability, portability, etc.
 Economic constraints
The process of specifying non-functional requirements requires the
knowledge of the functionality of the system, as well as the knowledge of
the context within which the system will operate.

They are divided into two main categories

 Execution qualities: These consist of thing like security and usability,
which are observable at run time.
 Evolution qualities: These consist of things like testability,
maintainability, extensibility, and scalability that are embodied in the
static structure of the software system.

What are Domain requirements in software engineering?

Domain requirements in software engineering refer to requirements
that originate from the application domain (i.e., the specific area or
industry in which the software will operate).
Classifications of Software Requirements
Other common classifications of software requirements can be:
1. User requirements: These requirements describe what the end-user
wants from the software system. User requirements are usually
expressed in natural language and are typically gathered through
interviews, surveys, or user feedback.
2. System requirements: These requirements specify the technical
characteristics of the software system, such as its architecture,
hardware requirements, software components, and interfaces. System
requirements are typically expressed in technical terms and are often
used as a basis for system design.
3. Business requirements: These requirements describe the business
goals and objectives that the software system is expected to achieve.
Business requirements are usually expressed in terms of revenue,
market share, customer satisfaction, or other business metrics.
4. Regulatory requirements: These requirements specify the legal or
regulatory standards that the software system must meet. Regulatory
requirements may include data privacy, security, accessibility, or other
legal compliance requirements.
5. Interface requirements: These requirements specify the interactions
between the software system and external systems or components,
such as databases, web services, or other software applications.
6. Design requirements: These requirements describe the technical
design of the software system. They include information about the
software architecture, data structures, algorithms, and other technical
aspects of the software.
Advantages of Software Requirements
Advantages of software requirements include:
1. Better organization: Classifying software requirements helps organize
them into groups that are easier to manage, prioritize, and track
throughout the development process.
2. Improved communication: Clear classification of requirements makes
it easier to communicate them to stakeholders, developers, and other
team members. It also ensures that everyone is on the same page
about what is required.
3. Increased quality: By classifying requirements, potential conflicts or
gaps can be identified early in the development process. This reduces
the risk of errors, omissions, or misunderstandings, leading to higher-
quality software.
4. Improved traceability: Classifying requirements helps establish
traceability, which is essential for demonstrating compliance with
regulatory or quality standards.
Disadvantages of software requirements
Disadvantages of software requirements include:
1. Complexity: Classifying software requirements can be complex,
especially if there are many stakeholders with different needs or
requirements. It can also be time-consuming to identify and classify all
the requirements.
2. Rigid structure: A rigid classification structure may limit the ability to
accommodate changes or evolving needs during the development
process. It can also lead to a siloed approach that prevents the
integration of new ideas or insights.
3. Misclassification: Misclassifying requirements can lead to errors or
misunderstandings that can be costly to correct later in the
development process.
Functional vs. Non Functional Requirements

Aspect Functional Requirements Non-Functional Requirements

Describes what the system Describes how well the system should
Definition
should do perform
Focus Functionality and features Performance, quality, and constraints
Nature Task-oriented Property-oriented
User login, data retrieval, Load time, scalability, security,
Examples
report generation usability
Mandatory for system performance
Requirement Type Mandatory for system behavior
and user satisfaction
Can be tested via functional Validated via performance, load, and
Validation
testing usability testing
User Interaction Directly related to user Often related to background processes
 Aspect Functional Requirements Non-Functional Requirements
interactions or system qualities
Use cases, user stories, Quality attribute scenarios,
Documentation Tool
functional specs performance benchmarks
Impact on System Determines system Influences system architecture and
Design capabilities and features infrastructure

Examples of Functional and Non-functional

Requirements
1. Online Banking System
1. Functional Requirements:
 Users should be able to log in with their username and password.
 Users should be able to check their account balance.
 Users should receive notifications after making a transaction.
2. Non-functional Requirements:
 The system should respond to user actions in less than 2 seconds.
 All transactions must be encrypted and comply with industry security
standards.
 The system should be able to handle 100 million users with minimal
downtime.
2. Food Delivery App
1. Functional Requirements
 Users can browse the menu and place an order.
 Users can make payments and track their orders in real time.
2. Non-functional Requirements:
 The app should load the restaurant menu in under 1 second.
 The system should support up to 50,000 concurrent orders during peak
hours.
 The app should be easy to use for first-time users, with an intuitive
interface.