Software Requirement Specification

(SRS) Format
 Difficulty Level : Easy
 Last Updated : 13 Dec, 2021

 Read

 Discuss

 Practice

 Video

 Courses
In order to form a good SRS, here you will see some points which can be used and should
be considered to form a structure of good SRS. These are as follows :
1. Introduction
 (i) Purpose of this document
 (ii) Scope of this document
 (iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
Software Requirement Specification (SRS) Format as name suggests, is complete
specification and description of requirements of software that needs to be fulfilled for
successful development of software system. These requirements can be functional as well
as non-functional depending upon type of requirement. The interaction between different
customers and contractor is done because its necessary to fully understand 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.
1. Introduction :
 (i) Purpose of this Document –
At first, main aim of why this document is necessary and what’s purpose of
document is explained and described.
 (ii) Scope of this document –
In this, overall working and main objective of document and what value it will
provide to customer is described and explained. It also includes a description of
development cost and time required.
 (iii) Overview –
In this, description of product is explained. It’s simply summary or overall review
of product.

2. General description :
In this, general functions of product which includes objective of user, a user
characteristic, features, benefits, about why its importance is mentioned. It also
describes features of user community.

3. Functional Requirements :
In this, possible outcome of software system which includes effects due to operation
of program is fully explained. All functional requirements which may include
calculations, data processing, etc. are placed in a ranked order.

4. Interface Requirements :
In this, software interfaces which mean how software program communicates with
each other or users either in form of any language, code, or message are fully
described and explained. Examples can be shared memory, data streams, etc.

5. Performance Requirements :
In this, how a software system performs desired functions under specific condition is
explained. It also explains required time, required memory, maximum error rate, etc.

6. Design Constraints :
In this, constraints which simply means limitation or restriction are specified and
explained for design team. Examples may include use of a particular algorithm,
hardware and software limitations, etc.

7. Non-Functional Attributes :
In this, non-functional attributes are explained that are required by software system
for better performance. An example may include Security, Portability, Reliability,
Reusability, Application compatibility, Data integrity, Scalability capacity, etc.
8. Preliminary Schedule and Budget :
In this, initial version and budget of project plan are explained which include overall
time duration required and overall cost required for development of project.

9. Appendices :
In this, additional information like references from where information is gathered,
definitions of some specific terms, acronyms, abbreviations, etc. are given and
explained.

Clear, concise, and executable requirements help development

teams create a proper product. How do we organize and present these
requirements? That's where a Software Requirements Specification
(SRS) comes in. But what is an SRS, and when should you use one?

In this blog, we'll outline a typical software requirements

specification, including how to define your product's purpose, describe
what you're building, detail the requirements, and, finally, deliver it for
approval. We'll also discuss the benefits of working through a
requirement software vs. word.

 What Is a Software Requirements Specification (SRS) Document?

 Why Use an SRS Document?
 Software Requirements Specification vs. System Requirements
Specification
 How to Write an SRS Document
 Writing an SRS in Microsoft Word vs. Requirement Software

What Is a Software Requirements Specification (SRS)

Document?

A software requirements specification (SRS) is a document that

describes what the software will do and how it will be expected to
perform. It also describes the functionality the product needs to fulfill
all stakeholders (business, users) needs.

An SRS can be simply summarized into four Ds:

 Define your product's purpose.

 Describe what you're building.
  Detail the requirements.
 Deliver it for approval.

We want to DEFINE the purpose of our product, DESCRIBE what we are

building, DETAIL the individual requirements, and DELIVER it for
approval. A good SRS document will define everything from how
software will interact when embedded in hardware to the expectations
when connected to other software. An even better SRS documents
also account for real-life users and human interaction.

The best SRS documents define how the software will interact when
embedded in hardware — or when connected to other software. Good
SRS documents also account for real-life users.

Why Use an SRS Document?

An SRS gives you a complete picture of your entire project. It provides

a single source of truth that every team involved in development will
follow. It is your plan of action and keeps all your teams — from
development to maintenance — on the same page (no pun intended).

This layout not only keeps your teams in sync but it also ensures that
each requirement is hit. It can ultimately help you make vital decisions
on your product’s lifecycle, such as when to retire an obsolete feature.

The time it takes to write an SRS is given back in the development

phase. It allows for better understanding or your product, team, and
the time it will take to complete.

Software Requirements Specification vs. System Requirements Specification

A software requirements specification (SRS) includes in-depth

descriptions of the software that will be developed.

A system requirements specification (SyRS) collects information on

the requirements for a system.

“Software” and “system” are sometimes used interchangeably as SRS.

But, a software requirement specification provides greater detail than
a system requirements specification.
>> Need to prove compliance? Here's how to create a traceability
matrix >>

How to Write an SRS Document

Writing an SRS document is important. But it isn’t always easy to do.

Here are five steps you can follow to write an effective SRS document.

1. Define the Purpose With an Outline (Or Use an SRS Template)

Your first step is to create an outline for your software requirements

specification. This may be something you create yourself. Or you may
use an existing SRS template.

If you’re creating this yourself, here’s what your outline might look
like:

1. Introduction

1.1 Purpose

1.2 Intended Audience

1.3 Intended Use

1.4 Scope

1.5 Definitions and Acronyms

2. Overall Description

2.1 User Needs

2.2 Assumptions and Dependencies

3. System Features and Requirements

3.1 Functional Requirements

 3.2 External Interface Requirements

3.3 System Features

3.4 Nonfunctional Requirements

This is a basic outline and yours may contain more (or fewer) items.
Now that you have an outline, lets fill in the blanks.

Download a white paper on best practices for writing requirements >>

2. Define your Product’s Purpose

This introduction is very important as it sets expectations that we will

hit throughout the SRS.
Some items to keep in mind when defining this purpose include:

Intended Audience and Intended Use

Define who in your organization will have access to the SRS and how
they should use it. This may include developers, testers, and project
managers. It could also include stakeholders in other departments,
including leadership teams, sales, and marketing. Defining this now
will lead to less work in the future.

Product Scope

What are the benefits, objectives, and goals we intend to have for this
product? This should relate to overall business goals, especially if
teams outside of development will have access to the SRS.

Definitions and Acronyms

It’s important to define the risks in the project. What could go wrong?
How do me mitigate these risks? Who is in charge of these risk items?
For example, if the failure of a medical device would cause slight
injury, that is one level of risk. Taking into account the occurrence
level and the severity, we can come up with a strategy to mitigate this
risk.
>> Need to create a PRD? Here's a how-to with examples >>

3. Describe What You Will Build

Your next step is to give a description of what you’re going to build. Is

it a new product? Is it an add-on to a product you’ve already created?
Is this going to integrate with another product? Why is this needed?
Who is it for?

Understanding these questions on the front end makes creating the

product much easier for all involved.

User Needs

Describe who will use the product and how. Understanding the user of
the product and their needs is a critical part of the process.

Who will be using the product? Are they a primary or secondary user?
Do you need to know about the purchaser of the product as well as the
end user? In medical devices, you will also need to know the needs of
the patient.

Assumptions and Dependencies

What are we assuming will be true? Understating and laying out these
assumptions ahead of time will help with headaches later. Are we
assuming current technology? Are we basing this on a Windows
framework? We need to take stock of these assumptions to better
understand when our product would fail or not operate perfectly.

Finally, you should note if your project is dependent on any external

factors. Are we reusing a bit of software from a previous project? This
new project would then depend on that operating correctly and should
be included.

4. Detail Your Specific Requirements

In order for your development team to meet the requirements properly,

we MUST include as much detail as possible. This can feel
overwhelming but becomes easier as you break down your
requirements into categories. Some common categories are:

Functional Requirements

Functional requirements are essential to your product because, as

they state, they provide some sort of functionality.

Asking yourself the question “does this add to my tool’s functionality?”

Or “What function does this provide?” can help with this process.
Within Medical devices especially, these functional requirements may
have a subset of risks and requirements.

You may also have requirements that outline how your software will
interact with other tools, which brings us to external interface
requirements.

External Interface Requirements

External interface requirements are specific types of functional

requirements. These are especially important when working with
embedded systems. They outline how your product will interface with
other components.

There are several types of interfaces you may have requirements for,
including:

 User
 Hardware
 Software
 Communications

System Features

System features are types of functional requirements. These are

features that are required in order for a system to function.

Other Nonfunctional Requirements

Nonfunctional requirements can be just as important as functional

ones.
These include:

 Performance
 Safety
 Security
 Quality

The importance of this type of requirement may vary depending on

your industry. In the medical device industry, there are often
regulations that require the tracking and accounting of safety.

IEEE also provides guidance for writing software requirements

specifications, if you’re a member.

5. Deliver for Approval

We made it! After completing the SRS, you’ll need to get it approved by
key stakeholders. This will require everyone to review the latest
version of the document.

Writing an SRS in Microsoft Word vs. Requirement Software

You can write your software requirement specification in Microsoft

Word. A smart way to do this is to create an SRS template that you can
use as a starting point for every project.

However, even with a template, writing an SRS this way can be a

painstaking process. And if a requirement changes, your SRS can fall
easily out-of-date. Plus, there can be versioning issues with
requirements documents in Word.

You can save time — and ensure accuracy — by writing an SRS

in Helix ALM instead.
Why Helix ALM Is Better…

Helix ALM (which comes with a dedicated requirements management

tool) adds efficiency through your entire requirements
management process.

By creating an SRS in Helix ALM, you’ll ensure a single source of truth

on your SRS. It will be easier to do requirements reviews of your SRS.
And that will help you get faster approvals — so your developers can
get started.

Once you have requirements in an SRS, you can easily manage them
throughout your development process.

If you’re also writing a PRD, you can link those feature requirements
to the high-level requirement in the SRS. This creates traceability
across your requirements process.

You can also link the requirements in your SRS to tests. This will help
you ensure that the product you deliver fulfills the purpose and
requirements of your SRS.

See for yourself how easy it can be to write an SRS. Try Helix
ALM free — and see how an effective SRS will improve your
development process. You can also watch our demo to see more
functionality.

What is Software Requirement Specification - [SRS]?

A software requirements specification (SRS) is a document that captures complete
description about how the system is expected to perform. It is usually signed off at the
end of requirements engineering phase.

Qualities of SRS:
 Correct
 Unambiguous
 Complete
 Consistent
 Ranked for importance and/or stability
 Verifiable
 Modifiable
 Traceable
Types of Requirements:
The below diagram depicts the various types of requirements that are captured during
SRS.