SRS- Software requirement specification

Started by thiruvasagamani, Jul 02, 2008, 08:21 PM

previous topic - next topic
Go Down


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

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

    * 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
    * 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
    * 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

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
   3. Business operation rules
   4. A traceability matrix
Thiruvasakamani Karnan

Go Up

Quick Reply

With Quick-Reply you can write a post when viewing a topic without loading a new page. You can still use bulletin board code and smileys as you would in a normal post.

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.
Please leave this box empty:

Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:

shortcuts: alt+s submit/post or alt+p preview
Network of IT Acumens | GinGly :: SMS Backup | Acumen :: Discussion Board | AshokPillar :: Hosting | CineBuzz :: Latest Cinema News | My Kids Diary :: Capture your kids magical moment
Copyright 2005 - 2016 :: IT Acumens :: All Rights Reserved.
ITAcumens Forum with 2 lakhs post running for 10 years - Powered by HostGator Dedicated Server