Pages

Ads 468x60px

Tuesday, August 19, 2008

What Do You Mean By SRS

  • a set of precisely stated properties or constraints which a software system must satisfy.
  • a software requirements document establishes boundaries on the solution space of the problem of developing a useful software system.

A software requirements document allows a design to be validated - if the constraints and properties specified in the document are satisfied by the software design, then that design is an acceptable solution to the problem.


Six requirements which a software requirements document should satisfy

  1. it should specify only external system behaviour,
  2. it should specify constraints on the implementation,
  3. it should be easy to change,
  4. it should serve as a reference tool for system maintainers,
  5. it should record forethought about the life cycle of the system, and
  6. it should characterize acceptable responses to undesired events


Characteristics of a Software Requirements Specification

A good SRS is

  1. unambiguous,
  2. complete,
  3. verifiable,
  4. consistent,
  5. modifiable,
  6. traceable, and
  7. usable during the operation and maintenance phase.

Unambiguous

  • Every requirement has only one interpretation.
  • Each characteristic of the final product is described using a single unique term.
  • A glossary should be used when a term used in a particular context could have multiple meanings.

Complete

    A complete SRS must possess the following qualities:
    1. inclusion of all significant requirements,
    2. definition of the responses of the software to all realizable classes of input,
    3. conformity to any standard that applies to it,
    4. full labelling and referencing of all tables and diagrams and the definition of all terms.

Verifiable

  • Every requirement must be verifiable.
  • There must exist some finite cost-effective process with which a person or machine can check that the software meets the requirement.

Consistent

  • No set of individual requirements described in the SRS can be in conflict.
  • Types of likely conflicts:
    1. Two or more requirements describe the same real world object in different terms.
    2. The specified characteristics of real world objects might conflict.
    3. There may be a logical or temporal conflict between two specified actions.

Modifiable

  • The structure and style of the SRS are such that any necessary changes to the requirements can be made easily, completely and consistently.
  • Requirements:
    1. a coherent and easy-to-use organization (including a table of contents, index and cross-referencing),
    2. not be redundant - this can lead to errors.

Traceable

  • The origin of each requirement must be clear.
  • The SRS should facilitate the referencing of each requirement in future development or enhancement documentation.
  • Types:
    1. Backward traceability
      • Each requirement must explicitly reference its source in previous documents.
    2. Forward traceability
      • Each requirement must have an unique name or reference number.

Usable during the operation and maintenance phase

  • The SRS must address the needs of the operation and maintenance phase, including the eventual replacement of the software.

No comments:

Post a Comment

 

Sample text

Sample Text

Job Search



Sample Text