How to prepare Software Requirement Specification Document (SRS)

This is one of a very important document which act as a baseline for a contract between the user and the developer. Its is expected to contain the complete requirements to adequate what the user will get from the implementation.

Based on IEEE recommendation.

1. INTRODUCTION

• 1.1 PURPOSE: Clearly state purpose of this document
• 1.2 SCOPE: by whom and how it will be used
• 1.3 Definitions: Acronyms, Abbreviations as applicable
• 1.4 References: to other documents
• 1.5 Overview of Developer’s Responsibilities: In terms of development, installation, training, maintenance, etc..

2. GENERAL DESCRIPTION

Is a general description giving the overview of the product features.

• 2.1 PRODUCT PERSPECTIVE: relationship with other products and principle interfaces
• 2.2 PRODUCT FUNCTION OVERVIEW: general overview of tasks; including data flow diagrams
• 2.3 USER CHARACTERISTICS: who they are and what training they may need
• 2.4 GENERAL CONSTRAINTS: about schedule, resources, cost, etc..

3.1 FUNCTIONAL REQUIRMENTS

In this part we give functional details of every function of the software by giving brief introduction to this functions, then we describe  inputs to the function, processing and the output. This is really the body of SRS document where functions are describe in full detail.

• 3.1.1 INTRODUCTION
• 3.1.2 INPUTS
• 3.1.3 PROCESSING
• 3.1.4 OUTPUTS
• 3.2…. (repeat similarly for each function

4. External Interface Requirements

• 4.1 User Interfaces: a preliminary user manual giving commands, screen formats, outputs, error messages, etc.. e.g: not need to show exact interfaces, but user must get an logical overview for those interfaces.
• 4.2 Hardware Interfaces: with existing as well as new or special purpose hardware.
• 4.3 Software Interfaces: with other software packages, operating systems, etc.. e.g: A hotel reservation system may have to interface with their existing Accounting system.

5. Performance Requirements

• What kind of an environment in which this system performs well.
• Capacity requirements (no of users, no of files), response time, through-put (in measurable terms). e.g: In a Banking system: how long will it take for a transaction process, is system able to face peak time work load, etc..

6. Design Constraints

ex: In financial world, lots of standards are there. so our software must be compatible with those.

• 6.1 Standards Compliance: software development standards as well as organizational standards (e.g., for reports, auditing)
• 6.2 Hardware Limitations: available machines, operating systems, storage capacities, etc..

7. Other Requirements

Possible future extensions

Note:

1. All sections are not required for all projects.
2. After SRS finishes, it will be handover to the design team, and then they will convert the word specification into a design.
3. We must ensure that we have collected all the data and put them in to that document.
4. SRS can be extensive task for a large scale systems, and it is used to be reviewed with the customer and there should be a sign off by telling ‘YES’ to the SRS from the customers view.
5. We would proceed for the next phase (Design Phase) if only the SRS is accepted by the user.