Software Requirement Specification (SRS) template
Filed Under Document, Requirements, SDLC, Process, Development, Software | Posted on October 17, 2007
Given the importance of capturing the Requirement specifications in a well documented way, the document itself should be very well drafted. The sections in it must closely map to the needs, and yet the overall document must not be very process heavy. It should make sense to the stakeholders, and yet capture all the relevant information.
An SRS is basically an organization’s understanding (in writing) of a customer or potential client’s system requirements and dependencies at a particular point in
time (usually) prior to any actual design or development work. It’s a two-way insurance policy that assures that both the client and the organization understand the other’s requirements from that perspective at a given point in time.
It’s important to note that an SRS contains functional and nonfunctional requirements only; it doesn’t offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer’s system requirements to be.
A well-designed, well-written SRS accomplishes four major goals:
* It provides feedback to the customer. An SRS is the
customer’s assurance that the development organization
understands the issues or problems to be solved and the
software behavior necessary to address those problems.
Therefore, the SRS should be written in natural language
(versus a formal language, explained later in this
article), in an unambiguous manner that may also include
charts, tables, data flow diagrams, decision tables, and so
on.
* It decomposes the problem into component parts. The
simple act of writing down software requirements in a
well-designed format organizes information, places borders
around the problem, solidifies ideas, and helps break down
the problem into its component parts in an orderly
fashion.
* It serves as an input to the design specification. As
mentioned previously, the SRS serves as the parent document
to subsequent documents, such as the software design
specification and statement of work. Therefore, the SRS
must contain sufficient detail in the functional system
requirements so that a design solution can be devised.
* It serves as a product validation check. The SRS also
serves as the parent document for testing and validation
strategies that will be applied to the requirements for
verification.
Here are some templates available on the internet:
Link1, Link2, Link3, Link4, A set of SRS templates, Link5, Link6
Leave a Reply
