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

In this article I want to give the readers very simple tips from my very short experience in writing a software requirements document. I am a developer and I know how it is important for me to have very clear requirements, and I was a junior project a manager, and I know the cost of a mistake in the requirements document. What I want is to share my experience with the readers.

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.