What is Software requirement specifications(SRS) and goal of SRS Document

What is Software requirement specifications(SRS) and goal of SRS Document 

SRS is basically an organization understanding in writing of a customer system requirements and dependencies at a particular point in time prior to any actual design or development take place.

It is two-way policy that assures that both the client and the organization understand the other requirements from that perspective at a given point in time.

The SRS also function as a blueprint for completing a project with as little cost growth as possible.The SRS is often referred to as the "parent document" because all subsequent project management documents such as design specification,statement of work,software architecture specifications,testing and validation plans are related to it.It is important to note that an SRS contains functional and non-functional requirements only.

Characteristics of a good SRS Document

• Complete.
• Consistent.
• Accurate.
• Modifiable.
• Ranked.
• Testable.
• Traceable.
• Unambiguous.
• Valid.
• Verifiable.

Goals of SRS document

• Feedback to customer.
• Problem decomposition.
• Input to design specification.
• Production validation check.

Who writes SRS document

System architects and programmers write SRS.With the increased complexity of the SRS it is better to involve the technical writers in the process of writing SRS document.The presence of a technical writer on the team helps place at the core of the project those user or customer requirements that provide more of an overall balance to the design of the SRS product and documentation.

Components of SRS document

SRS dovelopment will be collaborative effort for a particular project and ultimately results into a SRS document.Nine components that must be addressed when designing and writing SRS.

• Interfaces.
• Functional capabilities.
• Performance levels.
• Data structures.
• Safety.
• Reliability.
• Security.
• Quality.
• Constraints and limitations.

Uses of SRS Document

• Project managers base their plans and estimates of schedule,effort and resources on it.
• The maintenance and product support staff need it to understand what the software product is supposed to do.
• Customers rely on it to know what product they can expect.
• The publications group writes documentation,manuals etc from it.
• Training personnel can use it to help develop educational material for software product.
• The testing group needs it to generate test plans based on the described external behaviour.