POSTS

As a Software developer, has that dreaded time arrived for you? I am sure; you have landed up here after wracking your brain and sweating it out trying to formulate a Good Software Requirements Specification (SRS).  You are undoubtedly great at developing Software, however, when you are working, you don’t work alone. There is a whole project team working with your, also, the product/software that you develop will be something your marketing and sales department would need to be aware of, and so do the important stake holders, and of course, your customers. What I am trying to convey here is that before you start developing your software, you need to keep all these people on a loop about what you are developing, what you are going to achieve by developing it, and what do you require for its development. And putting this in pen and paper, or rather keyboard and printer (please ignore my lame attempt at humor) is the necessary devil. Of course, the good part is that most probably you are not alone in writing this; your project team will be with you.

Now that you know WHY you need to write a Software Requirements Specification, let’s get to the HOW of it. Do note that there are ready SRS Template available, which you can use to write your SRS, so that you don’t have to worry about how the outline will be. But, first things first – You need to define what exactly a SRS is.

What is Software Requirements Specification (SRS):

A Software Requirements Specification (SRS) is a document which specifies how and what the software system will be performing i.e. it describes how you will develop software. It assesses the requirements which are necessary for development of specific software.

The SRS answers for you what the Software will do, how it will behave, what are the requirements for developing it, what will be the process of development, what schedule/timeline you’ll be following, etc. 

In general, your SRS should contain within it – The purpose, The description, The specific requirements, and The Schedule for your Software. The outline for your SRS may differ from one SRS to other, however the basic components are the ones mentioned above. What then should you write within the components in the templates? Let’s take a detailed look – 

The Purpose: The purpose is the most important aspect of a Software Requirements Specification. Any software is built with a definitive purpose or goal, and this is what drives the whole project development. Writing up the purpose up front is a good idea. The purpose will be in the introductory part of your SRS. The introduction, along with the purpose should include include definitions of the various term which will be included with the document, background, scope and the overview of the system. It should also mention who your intended audience is, and what your software’s intended use is.

The Description: Herein, you will write the overall description of what your will be building. It should include your product perspective including the various interfaces such as Hardware and Software and Communication, the Design and Memory Constraints, the user needs and characteristics, the various functions of the Product, the assumptions and you have made, and the dependencies and the risks included within the running of this project. 

The Specific Requirements: First you need to include the features of the System too. Write in what are your Logical database requirements, Functional requirements, Non-functional requirements, Performance requirements, as well as External Interface Requirements. And also do include what will be the Environment characteristics as well as what will be the Attributes required of your Software System.

The Schedule: Also, if possible, do mention what your schedule will be for developing the software. Give a tentative timeline which lets your stakeholders, and the associated people know how you are going to go about, and the tentative time period within which you will be completing all the steps. 

And, of course, after writing up all these details, you need to get your Software Requirements Specification approved. As we have covered what all you need to include, here are a few tips on what you need to avoid – 

Don’t write an incomplete SRS, it should be complete in every sense, properly including all functional as well as non-functional requirements

Don’t include the requirements cannot be verified by set standards within your SRS

Don’t write any terminologies or requirements which have conflicts. Your SRS should be consistant.

Your requirements should not be ambiguous. Make sure that all of your requirements stated within the SRS have only one single interpretation.

Avoid using requirements which cannot be modified, they should have capability – at least to some extent – of accepting changes.

Don’t use jargons i.e. avoid using formal language. Those reading your SRS surely are experts within their field of knowledge; however this does not mean they understand all your technical terms. So, keep it easy and simple to understand.

These were my dos and don’ts and outline on how you as a Software Developer can write a Good Software Requirements Specification. This should be enough to give you a gist of what goes in to writing a SRS. So, begin with your outline or take the help of SRS Template and just begin with it. Once you start writing, you will get a flow. Get writing people.