The Basics to Software Requirements Specification (SRS Document)

Image for post

(All links will go to original medium post)

The purpose of this article is beginners guide to making an SRS for their portfolio projects to get hired as a junior developer.

What is in a Software Requirements Specification Document?

Software Requirements Specifications (SRS) is a document that describes what the software will do and how it will be expected to perform .

A typical SRS includes:

  • A purpose
  • An overall description
  • Specific requirements
Image for post
Tip: Good SRS documents account for real-life users.

Why use an SRS document?

An SRS is the framework that every team involved in development will follow, this may seem not needed for a solo developer project but the idea is scalability.

Using the SRS helps to ensure requirements are fulfilled providing critical information to multiple teams. These teams being development, quality assurance, operations, and maintenance.

Writing an SRS Document (The Outline)

A simple outline will look like this:

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

2. Solving a People Problem

This is the purpose of the product, you are creating something to solve a problem. Most often a people problem, think of a project like a ticket tracker for facility maintenance.

The purpose of the product will have a “Intended Audience and Intended Use”.

As an example:

In the case of a ticket tracker for facility maintenance, the “Intended Audience” will be for a property management companies focusing on commercial facilities. The “Intended Use” will be for the facility maintenance team giving key stakeholders the influence to propose problems that happen at the facility.

3. Detail Specific Requirements

Functional Requirements:

Functional requirements are essential to building your product.

If you’re developing a medical device, these requirements may include infusion and battery. And within these functional requirements, you may have a subset of risks and requirements.

External Interface Requirements:

External interface requirements are types of functional requirements. They’re important for embedded systems. And 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. Safety requirements, for example, will be critical in the medical device industry.

Want to see the full article? Click Here

Or

An actual SRS? Click Here

Leave a Reply