Writing a Software Requirements Specification Document

Updated: 19/12/2019

What is a Software Requirements Specification Document?

Many developers choose to work with a software requirements specification document (also known simply as a Software Requirements Document) as it typically contains the following:

– A complete description of the software’s purpose and functionality
– Details as to how the software will perform in terms of speed, response time, availability, portability, maintainability, recovery speed and more
– Use cases of how users will use the software
– The definition of how the application with interact with other hardware and program
– Non-functional requirements (e.g: performance engineering requirements, quality standards, or design constraints)

Why is it important?

A SRS allows developers to be clear on the goals of the software and on what they should focus on. Furthermore, it allows them to:

– Save time on communication
– Minimize development efforts
– Gives the customer feedback
– Eliminate task duplication
– Facilitate the transfer to new users or to new machines
– Breaks problems down into parts
– Serves as the main document to verify the validation and testing processes
– Referring to past SRS documents helps identify deficiencies and process flaws
– Define the scope of the project
– It helps reduce development effort.

How to Write a Software Requirements Specifications Document

There is no standard way of writing a requirements specifications document, but here are a few guidelines:

Create an SRS outline
If you do not already have an SRS template, there are many you can find on the web. Use a template to create an outline for you SRS doc. Modify it to suit your organization’s needs.

SRS outlines vary, depending on the organization and their processes. Some may be simple, while others are more detailed and complex.

Here is an example of a simple SRS outline:

1. Purpose
2. Scope
3. System Overview
4. References
5. Definitions
6. Use Cases
7. Functional requirements
8. Non-functional requirements

I got this outline from this website. Check it out to see it in more detail.

Once outlined, the SRS is ready to be written. Here are some tips to writing an SRS:

Choose the best person to write it
The writer should have superior communication skills. The purpose of the SRS to make everyone understand the specifications. Anything that is unclear or miscommunicated can lead to not-so-great consequences. Many suggest having technical writers involved in the requirements specification process helps in preventing miscommunications. They are more skilled writers than developers, and they have an air for precision and clarity. Technical writers know how to gather and process the right information; they also know how to convey customer requirements.

Make things visual
A picture can save 1000 words. Include graphics such as tables and charts to communicate your ideas better.

Don’t over-document
Avoid including things that may not need to be documented. SRS documents may get a bit long, so avoid packing in unnecessary information.

Keep an online version of the SRS and keep updating
As your tasks progress and if your staff and process changes, the SRS will need to be updated. For this reason, keeping a virtual version will help keep the whole team on the same page every time a change is made.

Sources:
MicroTools Inc.
TechWhirl