For some organizations, the SRS is a very important document. Other organizations don’t bother. So the significance of the document will depend upon the organization and their development process.

Larger, “less agile” organizations tend to rely upon them more but I don’t intend to start a flame war over their usage versus various development methodologies. Both waterfall and unified process approaches have a place for the SRS document.

The SRS can be very helpful in making sure that the business clients are clearly expressing their requirements of the application to the architects and developers. It can also be useful in identifying conflicting requirements and providing the basis to resolve those conflicts. The sooner conflicts are caught and resolved then the less likely that expensive design and coding changes will be required.

Generally, representatives from the business, business analysts, architects, and lead programmers will contribute to the SRS at various stages. Any particular instantiation will depend upon that organization and that project. Ultimately, there needs to be at least two people involved – one to express what is required and one to capture those requirements in a way that will have meaning to developers.

Techniques used to prepare an SRS is a huge subject, and there are a number of resources available to describe the process. Consider looking at the Software Engineering Book of Knowledge as a starter course on SRS development.

_{Normally, I would provide a link to the SWEBOK but it’s under review for the next release and IEEE has been moving the hosting URL around. At the moment, it’s easier to just google for it.}

It is a prefect detailed decription of the behaviour of the system to be developed.
SRS docuent is an agreement between the developer and the customer covering the functionak and non functional requirements of the software to be developed.