Simple tips in writing a software requirements and specification Document(SRS) document

Tamer Khalil

software development Software Engineering softwareAgile MethodologiesSoftware Project ManagementSRSTamer KhalilSoftware Requirements and SpecificationsTips in writing software requirementsWater Fall Method

11 Comments

Join the conversation! Your thoughts help the community grow.

Dhanusu Varadharaja10y ago
Thank you Tamer. It's very helpful for my new job. Previously use to write BRD, now started to develop SRS.
Gowtham Rajamanickam11y ago
good on
knights16y ago
Dear Tamer, Thank you for sharing your experience.I would respectfully disagree where you have quoted "DON'T STICK TO A SINGLE TEMPLATE".For a certain type of projects and if an effective template is available and being used widely why not use the same template? Software develoment is a very vast and diverse field.I believe it depends on scale and circumstances of software development in which one is working in; that is why when you say you could make your own template will not help to effciently reach the milestones. All software development documents are based on models which are concluded after some research.Not following a researched one, seems not a very nice idea.Thanks
- knights16y ago
  Hey Sam,niether i nor you nor Tamer is saying not to use a template.My point to mention was that rather not sticking to a template seems not a nice idea.Since template is not more of abstract out line i think its the information that we put in any template to categorize it.I hope this will clear it.Thank you.
- Sam Hobbs16y agoedited
  knights, I agree that "Not following a researched one, seems not a very nice idea.". I think that what Tamer is saying is that use of a template before researching requirements is not a good idea. If a template is adequately documented and after a new project's requirements are determined, if a template satisfies the requirements then there is nothing in this article saying to not use the template.
- Tamer Khalil16y ago
  Its nice to have this discussion. But what we need to take care of there are several points that makes me choose a template, or even build my own template such as the type of project, the process methodology I'm using, the audience of the document, etc. I believe that there is no project similar to the other. What I mean with not to stick to a certain template, is to look first at the whole environment of the project, and the culture and mentalities of the client, then decide which template to use, or even build your own template if it will utilize your resources, and if it will be the best to be used for the project.
Sam Hobbs16y ago
I hope someone can provide examples of how costly mistakes can be when the requirements are not adequately determined initially. There are probably very many more than what people realize.
Hussein Ahmed16y ago
Thank you Mr.Tamer for posting this article regarding the very important issue which is requirements and how it is so essential to any successful software.
- Tamer Khalil16y ago
  Thanks a lot Hussein, I'm sure that you've seen this problem in Egypt in several projects, and I'm sorry to say that some of these projects were for enterprise organizations.
Sam Hobbs16y agoedited
All excellent points. Yes, the requirements should be written so the user can understand. It should not describe how to do the application technically; that cannot be determined until all the requirements are understood. The only technical items should be actual requirements, such as stating (for example) that the application must execute in Windows using SQL Server.
- Tamer Khalil16y ago
  Thanks A lot Sam, one of the major problems I found is that system analysts miss analyze the system carefully, and with misunderstanding of the job of the quality assurance.

Thoughts about improving writing a software Requirements and specification document (SRS).

Something that I believe in is that without a good requirements document, the project will approach failure (if it did not fail). This document is very important because any mistake in it costs time and money. When you are writing a software requirements document, you should think of following:

The audience of the document.

A logical work flow of the business process.

The User Interface.

Before I go through the above, please note that you don't have to stick to a certain template, you could make your own template; each project is different from the other, and each client is different from the other, so take my advice, DON'T STICK TO A SINGLE TEMPLATE

Determine The Audience of the Document

Knowing who is reading the document is very important. The requirements documents somehow needs to be from any technical terminologies, because usually if you are making a tailor made software, the client is usually someone who is out of our field. So be sure to determine the audience. So always use as much simple words as possible. It is not a design document, so don't include diagrams that any of the stock holders will not be able to understand.

Logical workflow of the business process

You should write a logical work flow of the business process, and all the system pages or frames should be integrated with each other. Think of every single action the user could do, and the way to do so, and how this action will reflect in the results, and on the other parts of the system.

The User Interface

Please note that the most important thing (sometimes the only thing) the client cares of is the user interface. You may have done all the functionality to work perfectly, but when it comes to the UI we should take care of it. In order to save time, you should settle all the UI issues with the client in the requirements document.