Software requirements specification. A software requirements specification (SRS) is a description of a software system to be  developed. It is modeled after the business requirements specification (CONOPS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction.

Software requirements specifications establish the basis for an agreement between customers and contractors or suppliers on how the software product should function (in a market-driven project, these roles may be played by the marketing and development divisions). Software requirements specification is a rigorous assessment of requirements before the more specific system design stages, and its goal is to reduce later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules. Used appropriately, software  requirements specifications can help prevent software project failure.

The software requirements specification document lists sufficient and necessary requirements for the project development. To derive the requirements, the developer needs to have a clear and thorough understanding of the products under development. This is achieved through detailed and continuous communications with the project team and customer throughout the software development process.

The SRS may be one of a contract's deliverable data item descriptions or have other forms of organizationally-mandated content.

Typically a SRS is written by a technical writer, a systems architect, or a software programmer.

History 
Software requirement specifications are already used in software development processes as early as 1975. 

The purpose and content of software requirement specifications was formalised in 1983 by the IEEE.  The standard was published in 1984 as IEEE-830-1984 and approved by ANSI. It was revised in 1993 and 1998, before being superseded by an international standard.  This standard aimed at providing criteria for a good SRS, and recommendations about its content. It recognised the benefits of prototyping for the requirement engineering.  It propose an example of structure and several variants.   

The ISO/IEC/IEEE 29148 standard "Systems and software engineering —Life cycle processes — Requirements engineering" superseded IEEE 830 in 2011.  The current revision is from 2018.  This standard is broader as it covers also requirement quality criteria, requirement management processes, and business requirement specification (BRS), as well as stakeholder requirement specification (StRS).  It proposes a slightly changed example structure.

Structure
An example organization of an SRS is as follows: 

Purpose
Definitions
Background 
System overview
References 
Overall description
Product perspective
System Interfaces
User interfaces
Hardware interfaces
Software interfaces
Communication Interfaces
Memory constraints
Design constraints
Operations
Site adaptation requirements
Product functions
User characteristics 
Constraints, assumptions and dependencies 
Specific requirements
External interface requirements
Performance requirements
Logical database requirement
Software system attributes
Reliability
Availability
Security
Maintainability
Portability
Functional requirements
Functional partitioning
Functional description
Control description
Environment characteristics
Hardware
Peripherals
Users
Other
It would be recommended to address also verification approaches planned to qualify the software against the requirements, for example with a specific section with a structure that mirrors the section on specific requirements.

Requirement quality
Requirements should strictly be about what is needed, independently of the system design, and not how the software should do it. Individual requirements shall hence be necessary, appropriate, and unambiguous. A set of requirements shall moreover be complete, consistent, feasible, and comprehensible. 

Following the idea of code smells, the notion of requirements smell has been proposed to describe issues in requirements specification where the requirement is not necessarily wrong but could be problematic. Examples of requirements smells are subjective language, ambiguous adverbs and adjectives, superlatives and negative statements. Comparative phrases, non-verifiable terms or terms implying totatily should also be avoided.

See also
System requirements specification
Concept of operations
Requirements engineering
Software Engineering Body of Knowledge (SWEBOK)
Design specification
Specification (technical standard)
Formal specification
Abstract type

References

External links
 
 
 
 ("This standard replaces IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 - ")
 
 
 
 
How to Write a Software Requirement Specification to Save Costs?

Software requirements
Software documentation
IEEE standards