SOFTWARE REQUIREMENTS SPECIFICATIONS
● A software requirements specification (SRS) is a detailed description of a software
system to be developed with its functional and non-functional requirements. The SRS is
developed based the agreement between customer and contractors.
● A good SRS defines the how Software System will interact with all internal modules,
hardware, communication with other programs and human user interactions with wide
range of real life scenarios.
Following are the features of a good SRS document:
1. Correctness:
User review is used to provide the accuracy of requirements stated in the SRS. SRS is
said to be perfect if it covers all the needs that are truly expected from the system.
2. Completeness:
The SRS is complete if, and only if, it includes the following elements: (1). All essential
requirements, whether relating to functionality, performance, design, constraints,
attributes, or external interfaces.
(2). Definition of their responses of the software to all realizable classes of input data in
all available categories of situations.
(3). Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.
3. Consistency:
The SRS is consistent if, and only if, no subset of individual requirements described in its
conflict. There are three types of possible conflict in the SRS:
(1). The specified characteristics of real-world objects may conflicts. For example, (a)
The format of an output report may be described in one requirement as tabular but in
another as textual. (b) One condition may state that all lights shall be green while another
states that all lights shall be blue.
(2). There may be a reasonable or temporal conflict between the two specified actions.
For example, (a) One requirement may determine that the program will add two inputs,
and another may determine that the program will multiply them. (b) One condition may
state that "A" must always follow "B," while other requires that "A and B" co-occurs. (3).
Two or more requirements may define the same real-world object but use different terms
for that object. For example, a program's request for user input may be called a "prompt"
in one requirement's and a "cue" in another. The use of standard terminology and
descriptions promotes consistency.
4. Unambiguousness:
SRS is unambiguous when every fixed requirement has only one interpretation. This
suggests that each element is uniquely interpreted. In case there is a method used with
multiple definitions, the requirements report should determine the implications in the
SRS so that it is clear and simple to understand.
5. Ranking for importance and stability:
The SRS is ranked for importance and stability if each requirement in it has an identifier
to indicate either the significance or stability of that particular requirement. Typically, all
requirements are not equally important. Some prerequisites may be essential, especially
for life-critical applications, while others may be desirable. Each element should be
identified to make these differences clear and explicit. Another way to rank requirements
is to distinguish classes of items as essential, conditional, and optional.
6. Modifiability:
SRS should be made as modifiable as likely and should be capable of quickly obtain
changes to the system to some extent. Modifications should be perfectly indexed and
cross-referenced.
7. Verifiability:
SRS is correct when the specified requirements can be verified with a cost effective
system to check whether the final software meets those requirements. The requirements
are verified with the help of reviews.
8. Traceability:
The SRS is traceable if the origin of each of the requirements is clear and if it facilitates
the referencing of each condition in future development or enhancement documentation.
There are two types of Traceability:
1. Backward Traceability: This depends upon each requirement explicitly referencing its
source in earlier documents.
2. Forward Traceability: This depends upon each element in the SRS having a unique
name or reference number. The forward traceability of the SRS is especially crucial when
the software product enters the operation and maintenance phase. As code and design
document is modified, it is necessary to be able to ascertain the complete set of
requirements that may be concerned by those modifications.
9. Design Independence:
There should be an option to select from multiple design alternatives for the final system.
More specifically, the SRS should not contain any implementation details.
10. Testability:
An SRS should be written in such a method that it is simple to generate test cases and test
plans from the report.
11. Understandable by the customer:
An end user may be an expert in his/her explicit domain but might not be trained in
computer science. Hence, the purpose of formal notations and symbols should be avoided
too as much extent as possible. The language should be kept simple and clear.
12. The right level of abstraction:
If the SRS is written for the requirements stage, the details should be explained explicitly.
Whereas, for a feasibility study, fewer analysis can be used. Hence, the level of
abstraction modifies according to the objective of the SRS.
Value of good SRS
• The origin of most software systems is in the needs of some clients. The software system
itself is created by some developers. Finally, the completed system will be used by the
end users.
• An SRS establishes the basis for agreement between the client and the supplier on what
the software product will do.
• A high-quality SRS is a prerequisite to high-quality software.
• A high-quality SRS reduces the development cost.
• A high-quality SRS is a prerequisite to high-quality software.