Recommended Practices for SRS

SRS stands for Software Requirements Specification. To explain simply, it is the document which specify what are the exact requirements the software would provide.It should be very specific as it is mostly like an agreement because both parties
sign off the document as well.

In almost every organization, there is a standard template for a SRS. The content in it should also be properly defined.A good SRS would provide benefits such as,

- Establish the basis for agreement between the customers and the suppliers on what the software
product is to do :

Since the SRS defines the requirements clearly, it also serves as an agreement. This would also communicate each others' understanding of the requirements.

-Reduce the development effort.

Since the SRS defines the requirements in detail, the developers do not have to spend time guessing or making assumptions.

-Provide a basis for estimating costs and schedules.

The more detailed the requirements are, a more accurate estimate will be able to be provided.

-Provide a baseline for validation and verification.

Once the product is developed, SRS will provide a baseline to as why a certain feature is included / not included as well.

Some other important things to consider while doing a SRS is the internal consistency.(eg: using different words to refer to the same thing).The requirements need to be broken and specified separately as it will bring proper attention to every requirement. Also , another thing is, we need not give too much internal details or go too deep into the technical details unless the client is interested.