A software requirements specification (SRS) is a description of a
software system
A software system is a system of intercommunicating software component, components based on software forming part of a computer system (a combination of Computer hardware, hardware and software). It "consists of a number of separate Computer progr ...
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
A deliverable is a tangible or intangible good or service produced as a result of a project that is intended to be delivered to a customer (either internal or external). A deliverable could be a report, a document, a software product, a server upgr ...
data item descriptions or have other forms of organizationally-mandated content.
Typically a SRS is written by a
technical writer
A technical writer is a professional communicator whose task is to convey complex information in simple terms to an audience of the general public or a very select group of readers. Technical writers research and create information through a vari ...
, a
systems architect, or a
software programmer
A programmer, computer programmer or coder is an author of computer source code someone with skill in computer programming.
The professional titles ''software developer'' and ''software engineer'' are used for jobs that require a progr ...
.
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 Institute of Electrical and Electronics Engineers (IEEE) is an American 501(c)(3) organization, 501(c)(3) public charity professional organization for electrical engineering, electronics engineering, and other related disciplines.
The IEEE ...
. The standard was published in 1984 as IEEE-830-1984 and approved by
ANSI
The American National Standards Institute (ANSI ) is a private nonprofit organization that oversees the development of voluntary consensus standards for products, services, processes, systems, and personnel in the United States. The organiz ...
. 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
The International Organization for Standardization (ISO ; ; ) is an independent, non-governmental, international standard development organization composed of representatives from the national standards organizations of member countries.
Me ...
/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
##
Definition
A definition is a statement of the meaning of a term (a word, phrase, or other set of symbols). Definitions can be classified into two large categories: intensional definitions (which try to give the sense of a term), and extensional definitio ...
s
##Background
##System overview
##
Reference
A reference is a relationship between objects in which one object designates, or acts as a means by which to connect to or link to, another object. The first object in this relation is said to ''refer to'' the second object. It is called a ''nam ...
s
#
Overall description
##
Product perspective
###
System Interfaces
###
User interface
In the industrial design field of human–computer interaction, a user interface (UI) is the space where interactions between humans and machines occur. The goal of this interaction is to allow effective operation and control of the machine fro ...
s
###
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 totality 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)
A specification often refers to a set of documented requirements to be satisfied by a material, design, product, or service. A specification is often a type of technical standard.
There are different types of technical or engineering specificati ...
*
Formal specification
*
Abstract type
In programming languages, an abstract type (also known as existential types) is a type in a nominative type system that cannot be instantiated directly; by contrast, a concrete type be instantiated directly. Instantiation of an abstract ty ...
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?
{{DEFAULTSORT:Software Requirements
Software requirements
Software documentation
IEEE standards