How to Write an SRS Document: Example and Guide

In IT projects, there are usually a lot of stakeholders and a lot of moving parts. One of the biggest challenges is keeping everyone on the same page and communicating needs, progress and feedback.

You need to establish a baseline for the project, estimate costs and development time, and make sure that all project stakeholders agree on key project details.

To do that, you can create an SRS document.

What is an SRS document?

Software Requirement Specification, or SRS, is the foundation of any software project, especially commercial ones with multiple stakeholders.

Someone funds the project, business managers run it, the development team builds the software, quality assurance experts test it, and marketers promote it. That’s quite some investment.

All of these project stakeholders should be on the same page. That’s where the SRS comes in. The SRS document paints the picture of the ideal outcome of the project. Even though end users won’t see this document, the SRS plays a huge part in building a functional product that satisfies user needs.

Think of the SRS as the foundation of your project, or better yet - the founding mission. There are plenty of benefits that come from proper SRS documents:

Everyone is on the same page, there’s less miscommunication. If there’s any dispute about the progress or state of the project, you can refer to the SRS.
The SRS makes it possible to precisely estimate costs and development time. Without an SRS document example it’s not really estimating, more like guessing.
Projects that start with a detailed SRS have shorter development time, and fewer redesigns throughout the development process.
An SRS reduces chances of project failure, and makes it easier to evaluate the project after it’s finished.

The main use case for SRS documents is outsourcing and working with IT contractors or software development companies. They’re also used in enterprise-level companies for in-house development.

SRS documents are usually written by project managers or technical managers. They can also be written in collaboration with your software development provider. At Ulam Labs, we write SRS documents with our clients during software discovery workshops.

After the SRS is written, your software provider can estimate costs and development time, and you can move on to the next steps of the project. Sometimes you’re going to have to approve the SRS with your CTO or other project stakeholders before you can move on.

In the most basic form of SRS, you need to have 3 sections:

Introduction (purpose and scope)
Description (business and user perspective)
Requirements (detailed technical perspective)

What goes into each of these sections? "Applied software project management" by Andrew Stellman and Jennifer Greene provides a neat template for a detailed SRS document:
‍

If you’re thinking “that doesn’t seem very agile”, you’re right. This template looks that way because it’s made in accordance with IEEE standards (Institute of Electrical and Electronics Engineers Standards Association).

But, unless you’re making software for fighter jets or medical devices, it’s likely that you don’t need so much detail in your SRS.

The first step in writing an SRS document is the big picture outline of the project. Look at the project from a top-down perspective - start with the main business goals, and work your way down to how the software will help achieve those goals.

You don’t want to get into technical details yet. Describe the project in broad strokes, focus on things like:

What is the software used for?
Who will use it? (target group)
Project definitions (industry specifics)
Definition of failure (for example, if it’s a self-driving system, an accident is a failure)

Now we can get into the details. This section still isn’t a purely technical overview, it’s more about defining the key usability and business aspects of the project. You might want to describe things like:

Are there competing products on the market?
Who exactly are the intended users?
How will they use the software?
Important considerations (for example, if new software should integrate with legacy infrastructure)

This is where you get technical, making this the hardest part of writing an SRS. If you’re not a software architect, you might want to do this part with a consultant or your software provider. In this section, you focus on:

How should the software be designed? (interfaces, business logic)
What hardware will the software need?
How will the software communicate with other systems?
What are the performance metrics you’re aiming for?
How secure should the software be?
How should the software store and manage data?

And that’s pretty much the gist of how to prepare an SRS. But, I want to show you another, a bit more agile way to prepare an SRS.

You might not know all the things that the typical SRS template requires. That’s absolutely fine. Like I mentioned before, unless you’re building software for fighter jets, your SRS doesn’t need to be super detailed.

The most common case is that you have a project idea, and you want to transparently convey it to your development provider so that they can make appropriate technological decisions.

Here, a shorter, more agile version of the SRS should be enough. The outline for an agile SRS looks like this:

With this simplified SRS, it should be much easier and less time-consuming to establish a baseline for the project.

Summary

The SRS is a very important document, however it doesn’t always have to be as detailed as IEEE standards impose. It can be a relatively short document that defines the crucial details of your software idea.

If you’re not sure about the detailed technical parts of your project, don’t let it stop you from making any SRS document at all. The business perspective is just as crucial as the technological perspective, and when you’re outsourcing your project, your provider will take care of the tech.

Any SRS document is better than no SRS. And trust me - if you prepare one, your software provider will be grateful, and it will make the development process easier.