How to Write Specifications for Software

A Software Requirement Specification (SRS) is a document that elaborates the business purposes and functionalities of the software. Because it defines how the software is meant to function based on the user’s or business’ requirement, it is important to know how to write specifications for software. An SRS document will also describe the software’s non-functional requirements such as performance, security, and UI design. In short, we can say that this is the one document all the developers, testers and other members of the development team will rely on during the design and development phases of the software. This means that it is critical that we know what a conventional SRS document should contain.

Why is it Important to Write an SRS?

At the beginning of a project, the client will most likely verbally list requirements in a meeting or in short notes through email or text chats. They won’t prepare a well written document for you that describes what their needs are because it’s the responsibility of the development team to prepare a well articulated specification document, clearly defining the customer’s needs and how they can be achieved, based on notes following the initial meeting. The document can also be used to get feedback from the customer to make sure the development team understands his or her requirements. It will also be considered as the ‘starting point’ for the actual design and implementation of the software and will clearly outline the software’s different components that will need to be developed and tested during the software testing life cycle.

How to Structure a Software Specification Document:

Define the Document’s Purpose

As with any technical document you write, you first need to tell the audience the purpose of the document and define the intended readers. This will usually be the customers and the development team.

Identify the Scope

As usual, you will be building a software within a given timeframe and will know that it’s not always possible to include all requirements asked for by the customer, within the timeframe. You will need to clearly define in the scope which software can be included within the time limitations, and which cannot.

Provide a Software Overview

Once you have described the purpose and the scope, it’s now time to describe the software. This is where you write about the business use of the software. This section won’t fully describe each and every function, but it will give the audience an idea of how the software behaves and can help the business or the user achieve what it’s is built for.

Outline the Infrastructure Requirements

This section contains details about the UI design, database design and other application layers and infrastructures needed to build the actual software.

Define the Functional Requirements

This section outlines every feature wanted by the customer in this software. It also details different use cases, and negative cases (if any), that need to be handled in the software. Technical specifications such as the class and methods used in the software may also be clearly detailed in this section.

Define the Non-functional Requirements

This section contains details about the performance, reliability, usability and security requirements of the software.

Provide any References and Appendices

References and appendices used in the documents should be listed here.

Key Points to Consider while Writing Specifications for Software

There are a few things that you will need to emphasise when preparing an SRS document, a few of which are listed below:

Images and Diagrams

Diagrams and images speak a lot and can be the easiest way to communicate to your audience. Use them wisely and properly to illustrate what you are trying to say. Using illustrations can also prevent you from ‘over documenting.’  If you can convey something with a simple diagram, why spend unnecessary time writing a 1000 word description? It can be as simple as that.

Conventions in Naming and the use of Terminology

Common terms used to name a particular feature or function across the documents should be consistent and properly defined in a particular section. Using two different terms to name the same feature will create confusion amongst those using your document. For example, if you use the word ‘login’ for a user login feature then it should be the same throughout so you cannot refer to the same feature as ‘sign in’ in other section.

Use of References

This is a most important point while writing an SRS. As you write, you will have to refer to various other documents or sections of the same document. Always use hyperlinks to reference these sections so that it’s so easy for the audience to simply click through and read the section it’s linked to.

Collaborate with Others Online

While you are creating such a document you may need advice, a review and proofreading from other members in the team, even though you have the prime responsibility for writing it. If you use online collaboration tools such as Google Doc, you will find it’s always easy to update the document and share with others online so that everyone in the team has instant access to the recent changes.