SRS Document preperation

SRS(Software Requirements Specifications) useful link

 The SRS is a specification for a particular Software product, program or set of programs that performs certain functions in a specific environment.

It serves a number of purposes depending on who is writing it. 
First , the SRS could be written by the customer of a system. In this case SRS is used to define the needs and expectations of the users.

Second, the SRS could be written by a developer of the system. In this case it serves as a contract between the customer and the developer. The reduces the probability of the customer being disappointed with the final product. And this case (written by the developer) is of our interest.

The two scenarios create entirely  different situations and establish entirely different purposes for the document.

"SRS is a document that completely describes what the proposed software should do without describing how the software will do it". It is the basic goal of the requirement phase of the SDLC, which describes the complete external behavior of the proposed software.

• An SRS establishes the basis for agreement between the client and the supplier(developer) on what the software product will do.
• An SRS provides a reference for validation of the final product.
• A high-quality SRS is a prerequisite to high-quality software, and reducing the development cost.

The IEEE has published guidelines and standards to organize an SRS document. Different projects may require their SRS to be organized differently, The first two sections are the same in all projects, the specific tailoring occurs in section 3.  It should NOT describe any design or implementation details. These should be described in the design phase of the project.

The general organization of an SRS is given below:

1. INTRODUCTION: Should contain:
      1.1 Purpose
      1.2 Scope
      1.3 Definitions, acronyms and abbreviations
      1.4 References
      1.5 Overview

2. OVERALL DESCRIPTION: It does NOT state the specific requirements , instead it provides a background for those requirements, which are defined in detail in section 3 , and makes it easier to understand.
     2.1 Product Perspective: A block diagram showing major components of the system, interconnections and external interfaces.
     2.2 Product Functions: Provides a general overview of all the functions of the software(all use cases with use case diagrams).
     2.3 User Characteristics:Educational background, amount of product training required,
     2.4 Constraints: Description of any other items that would limit the developers options e.g. hardware limitations, parallel operations, implementation language requirements, criticality of the application, safety & security considerations.
     2.5 Assumptions and Dependencies

3. SPECIFIC REQUIREMENTS

(A) FUNCTIONAL REQUIREMENTS
   

 3.1 Functionality or Functional requirements. All functions to be performed by the system in response to an input or in support of an output. Which output should be produced from the given input.  All operations to be performed on the input data should be given. Care should be taken not to specify any algorithms, these decisions should be left for the designer. Example validity checks on the inputs, exact sequence of operations, system behavior in abnormal  situations like wrong input. responses to abnormal situations, Error handling and recovery.

3.2 External Interfaces: All possible interactions of the software with people, hardware and other softwares. Detailed description of every input into the system and  description of every output of the system. It should include: Name of item, description of purpose, source of input or destination of output, valid range, unit of measure,timing, relationships to other I/O, screen formats/organizations.

(B) NON-FUNCTIONAL REQUIREMENTS

3.3 Performance Requirements: Dynamic requirements , typically the response time(expected time of completion of an operation) and the throughput(number of operations that can be performed in a unit time e.g. the number of transactions that must be processed per unit time). Static requirements(also called capacity requirements of the system): Those that do not impose constraint on execution characteristics of the system. viz. the number of terminals to be supported, number of simultaneous users to be supported, amount and type of data to be handled(number of files that the system has to process and their sizes . All these requirements should be stated in measurable terms. For example "90% of the transactions shall be processed in less than 1 sec", rather than "An operator shall not have to wait for the transaction to complete".

3.4 Logical Database requirements:the logical requirements for any information that is to be placed into a database. This should specify Types of informations used by various functions, frequency of use, accessing capabilities, data entities and their relationships, integrity constraints, data retention requirements.
3.5 Design Constraints: Imposed by other standards, hardware limitations, operating systems, database integrity etc.like:

        3.5.1 Standards compliance: should specify the requirements derived from  existing regulations. like: report format,data naming, accounting procedures , audit tracing.

         3.5.2 Hardware limitations:

3.6 Software system attributes: Reliability, Availability, Security, Maintainability, Portability.


4. SUPPORTING INFORMATION
    4.1 Table of contents and index.
    4.2 Appendixes 

--------------------------------------------------------------------------------------------------------------------------

Sample SRS:
software-requirements-specification-of-library-management-system