SRS- Software requirement specification

Started by thiruvasagamani, Jul 02, 2008, 02:51 PM

Previous topic - Next topic

thiruvasagamani

What is a Software Requirements Specification?

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.

The SRS document itself states in precise and explicit
language those functions and capabilities a software system
(i.e., a software application, an eCommerce Web site, and so
on) must provide, as well as states any required constraints by
which the system must abide. The SRS also functions 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 specifications, statements of work, software
architecture specifications, testing and validation plans, and
documentation plans, are related to it.

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.

SRSs are typically developed during the first stages of
"Requirements Development," which is the initial product
development phase in which information is gathered about what
requirements are needed--and not. This information-gathering
stage can include onsite visits, questionnaires, surveys,
interviews, and perhaps a return-on-investment (ROI) analysis
or needs analysis of the customer or client's current business
environment. The actual specification, then, is written after
the requirements have been gathered and analyzed.


What Kind of Information Should an SRS Include?

You probably will be a member of the SRS team (if not, ask
to be), which means SRS development will be a collaborative
effort for a particular project. In these cases, your company
will have developed SRSs before, so you should have examples
(and, likely, the company's SRS template) to use. But, let's
assume you'll be starting from scratch. Several standards
organizations (including the IEEE) have identified nine topics
that must be addressed when designing and writing an SRS:

   1. Interfaces
   2. Functional Capabilities
   3. Performance Levels
   4. Data Structures/Elements
   5. Safety
   6. Reliability
   7. Security/Privacy
   8. Quality
   9. Constraints and Limitations

But, how do these general topics translate into an SRS
document? What, specifically, does an SRS document include? How
is it structured? And how do you get started? An SRS document
typically includes four ingredients, as discussed in the
following sections:

   1. A template
   2. A method for identifying requirements and linking
      sources
   3. Business operation rules
   4. A traceability matrix
Thiruvasakamani Karnan