How to Write Srs
How to Write SRS
Introduction
Software Requirement Specification (SRS) document usually contains a software vendor’s understanding of a customer’s software requirements. This document ensures that the software vendor and the customer are in agreement as to the features required in the software system being built. SRS is created after the initial requirement elicitation phase in which Software vendor interacts with the customer to understand the software needs. Usually SRS documentation is prepared by a business analyst who has some technical background.
An SRS is written in precise, clear and plain language so that it can be reviewed by a business analyst or customer representative with minimal technical expertise. However it also contains analytical models (use case diagrams, entity relationship diagrams, data dictionary etc.) which can be used for the detailed design and the development of the software system. SRS is one of the most critical pieces of software development since it acts as the bridge betweens the software developers and business analysts. An incomplete or incorrect SRS can have disastrous effects on a software project.
In this article I explain the major sections of a typical Software Requirement Specification document. I also provide a generic SRS template which can be customized for your project needs.
What is the need for an SRS document?
Software Requirements Specification is usually the first deliverable for any software project. As they say, first impression is the best impression!, and you should ensure that even the first draft of an SRS is of high quality.
The benefits of a good SRS are,
• A contract between the customer and the software vendor – A good SRS document specifies all the features required in the final system including technical requirements and interface requirements. SRS document is used by the customer to determine whether the software vendor has provided all the features in the delivered software system. To the
Introduction
Software Requirement Specification (SRS) document usually contains a software vendor’s understanding of a customer’s software requirements. This document ensures that the software vendor and the customer are in agreement as to the features required in the software system being built. SRS is created after the initial requirement elicitation phase in which Software vendor interacts with the customer to understand the software needs. Usually SRS documentation is prepared by a business analyst who has some technical background.
An SRS is written in precise, clear and plain language so that it can be reviewed by a business analyst or customer representative with minimal technical expertise. However it also contains analytical models (use case diagrams, entity relationship diagrams, data dictionary etc.) which can be used for the detailed design and the development of the software system. SRS is one of the most critical pieces of software development since it acts as the bridge betweens the software developers and business analysts. An incomplete or incorrect SRS can have disastrous effects on a software project.
In this article I explain the major sections of a typical Software Requirement Specification document. I also provide a generic SRS template which can be customized for your project needs.
What is the need for an SRS document?
Software Requirements Specification is usually the first deliverable for any software project. As they say, first impression is the best impression!, and you should ensure that even the first draft of an SRS is of high quality.
The benefits of a good SRS are,
• A contract between the customer and the software vendor – A good SRS document specifies all the features required in the final system including technical requirements and interface requirements. SRS document is used by the customer to determine whether the software vendor has provided all the features in the delivered software system. To the