Software Requirement Specification
A software requirements specification (SRS) is a document that captures
complete description about how the system is expected to perform. It is
usually signed off at the end of requirements engineering phase.
A software requirements specification (SRS) is a document explaining
how and what the software/system will do. It defines the features and
functionality that the product requires to satisfy all stakeholders’
(business, users) needs.
A standard SRS includes:
A goal/purpose
A summary of the whole process
Specific Requirements
There must be certain qualities in a well written SRS document, thus it
does not cause errors in the development process. The following qualities
include:
Correctness
The SRS document is only right if the program meets the required
specifications.
Thus, no fixed method is given to guarantee the consistency of the
SRS, but it can be used to make sure that it stays in line with other
superior requirements or documents. An SRS document is said as
correct if it covers all the requirements that are actually expected
from the system.
1
Users can also decide through feedback whether the SRS represents
their needs.
Unambiguousness
As a software development project is based on an SRS document,
all the declarations must be simple, concise, and in-depth.
No amphiboles, ambiguous adverbs, words suggesting multiple
significance, etc. should be present.
A glossary to clarify each word at the end of the document is often
useful.
Completeness
All the program specifications and answers to input data (valid or
invalid) are provided in a complete SRS.
Consistency
As mentioned above, the SRS must be linked to other high-level
documents such as the system requirements specifications.
An SRS document must also be reliable with itself, which ensures
that the details it contains cannot be changed.
Ranking for importance and/or stability rating
All software requirements are not equally important, some are
crucial, and others are less important add-ins.
An SRS document must assess the importance and/or stability of
the features of the program in order to enable development teams to
complete each task in the right order.
2
Verifiability
The declarations in the document need to be confirmed, and if the
program meets the needs, it can be checked.
This is only attributable to the uncertainty of an SRS, which cannot
be supported by unambiguous statements.
Modifiability
Because the process of software creation can change dramatically,
software needs can change.
An SRS must be versatile in structure and style, so it can be easily
changed if needed.
Traceability
The root of each software requirement must be transparent and
future documentation should be easy to reference, which means
that the life cycle of each function must be recognizable.
Understandable by Consumers
Here, consumers refer to the end-users who may be an expert in
their specific domain. However, they might not have expertise in
Computer Science. Therefore, it is very crucial to avoid using
formal notations and symbols to make the document as much
understandable as possible. And thus, the language used in the
document should be kept easy to read and clear to avoid any
miscommunications or confusion.
3
A typical SRS document describes all the software requirements and
sometimes even contains a collection of use cases that describe the user
interactions needed by the software.
It defines the purpose of a software project, provides the overall
definition and specifications of its features.
In general, SRS documents contain three kinds of program requirements:
Functional specifications that include measures to be performed
by the system
Non-functional requirements determining the software system’s
performance attributes
Domain requirements that are device limits on the service domain
Types of Requirements:
The below diagram depicts the various types of requirements that are
captured during SRS.
