software requirements specification (SRS)

Key components of an SRS

The main sections of a software requirements specification are:

• Business drivers – this section describes the reasons the customer is looking to build the system, including problems with the currently system and opportunities the new system will provide.
• Business model – this section describes the business model of the customer that the system has to support, including organizational, business context, main business functions and process flow diagrams.
• Business/functional and system requirements -- this section typically consists of requirements that are organized in a hierarchical structure. The business/Functional requirements are at the top level and the detailed system requirements are listed as child items.
• Business and system use cases -- this section consists of a Unified Modeling Language (UML) use case diagram depicting the key external entities that will be interacting with the system and the different use cases that they’ll have to perform.
• Technical requirements -- this section lists the non-functional requirements that make up the technical environment where software needs to operate and the technical restrictions under which it needs to operate.  
• System qualities -- this section is used to describe the non-functional requirements that define the quality attributes of the system, such as reliability, serviceability, security, scalability, availability and maintainability.
• Constraints and assumptions -- this section includes any constraints that the customer has imposed on the system design. It also includes the requirements engineering team’s assumptions about what is expected to happen during the project.
• Acceptance criteria -- this section details the conditions that must be met for the customer to accept the final system.

Purpose of an SRS

An SRS forms the basis of an organization’s entire project. It sets out the framework that all the development teams will follow. It provides critical information to all the teams, including development, operations, quality assurance (QA) and maintenance, ensuring the teams are in agreement.

Using the SRS helps an enterprise confirm that the requirements are fulfilled and helps business leaders make decisions about the lifecycle of their product, such as when to retire a feature. 

In addition, writing an SRS can help developers reduce the time and effort necessary to meet their goals as well as save money on the cost of development.

Alternatives to an SRS

In Agile methodologies, companies usually favor a more lightweight documentation of the requirements, such as via acceptance tests and user stories.

For this approach to work, the customer had to be easily accessible to provide any necessary clarification on the requirements during development. It also assumes that the developers writing the user stories with the customer will be the developers building the system.  

The Rapid Application Development (RAD) software development methodology favors speed and flexibility over upfront planning. This approach has a very short development time span. Typically, a project developed with this model has a delivery time of 60 to 90 days.

SRS Template

The following is a simple SRS template:

Table of Contents

1. Introduction

1.1 Purpose of this document

1.2 Scope of this document

1.3 Overview

1.4 Business Context

2. General Description

2.1 Product Functions

2.2 Similar System Information

2.3 User Characteristics

2.4 User Problem Statement

2.5 User Objectives

2.6 General Constraints

3. Functional Requirements

4. Interface Requirements

4.1 User Interfaces

4.2 Hardware Interfaces

4.3 Communications Interfaces

4.4 Software Interfaces

5. Performance Requirements

6. Other non-functional attributes

6.1 Security

6.3 Reliability

6.4 Maintainability

6.5 Portability

6.6 Extensibility

6.7 Reusability

6.8 Application Affinity/Compatibility

7. Operational Scenarios

8. Preliminary Use Case Models and Sequence Diagrams

8.1 Use Case Model

8.2 Sequence Diagrams

9. Updated Schedule

10. Appendices

10.1 Definitions, Acronyms, Abbreviations

10.2 References

Features of an SRS

An SRS should have following characteristics:

• Correct -- should accurately reflect product functionality and specification at any point of time.
• Unambiguous -- should not be any confusion regarding interpretation of the requirements.
• Complete -- should contain all the features requested by a client.
• Consistent -- same abbreviation and conventions must be followed throughout the document.
• Ranked for importance and/or stability -- every requirement is important. But some are urgent and must be fulfilled before other requirements and some could be delayed. It’s better to classify each requirement according to its importance and stability.
• Verifiable -- an SRS is verifiable only if every stated requirement can be verified. A requirement is verifiable if there is some method to quantifiably measure whether the final software meets that requirement.
• Modifiable -- an SRS must clearly identify each and every requirement in a systematic manner. If there are any changes, the specific requirements and the dependent ones can be modified accordingly without impact the others.
• Traceable – an SRS is traceable if the origin of each of its requirements is clear and if it makes it easy to reference each requirement in future development.

The goals of an SRS

Some of the goals an SRS should achieve are to:

• Provide feedback to the customer, ensuring that the IT company understands the issues the software system should solve and how to address those issues.
• Help to break a problem down into smaller components just by writing down the requirements.
• Speed up the testing and validation processes.
• Facilitate reviews.