Software Requirement Specification

 Introduction: 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.
 The SRS is a specification for a specific software product, program, or set
of applications that perform particular functions in a specific environment.
It serves several goals depending on who is writing it.
 First, the SRS could be written by the client of a system. Second, the SRS
could be written by a developer of the system. The two methods create
entirely various situations and establish different purposes for the
document altogether.
 The first case, SRS, is used to define the needs and expectation of the
users. The second case, SRS, is written for various purposes and serves as
a contract document between customer and developer.
 Format of SRS Document
 In order to form a good SRS, here you will see some points
which can be used and should be considered to form a
structure of good SRS. These are as follows :
1. Introduction
 (i) Purpose of this document
 (ii) Scope of this document
 (iii) Overview
2. General description 3. Functional Requirements 4.
Interface Requirements 5. Performance Requirements 6.
Design Constraints 7. Non-Functional Attributes 8.
Preliminary Schedule and Budget 9. Appendices Software
Requirement Specification (SRS)
 Format of SRS Document
 Depending upon information gathered after interaction, SRS is
developed which describes requirements of software that may
include changes and modifications that is needed to be done to
increase quality of product and to satisfy customer’s demand.
 Introduction :
 (i) Purpose of this Document – At first, main aim of why this
document is necessary and what’s purpose of document is explained
and described.
 (ii) Scope of this document – In this, overall working and main
objective of document and what value it will provide to customer is
described and explained. It also includes a description of development
cost and time required.
 (iii) Overview – In this, description of product is explained. It’s simply
summary or overall review of product.
 Format of SRS Document
2. General description : In this, general functions of product which
includes objective of user, a user characteristic, features, benefits,
about why its importance is mentioned. It also describes features of
user community.
3. Functional Requirements : In this, possible outcome of software
system which includes effects due to operation of program is fully
explained. All functional requirements which may include
calculations, data processing, etc. are placed in a ranked order.
4. Interface Requirements : In this, software interfaces which mean
how software program communicates with each other or users
either in form of any language, code, or message are fully described
and explained. Examples can be shared memory, data streams, etc.
 Format of SRS Document
5. Performance Requirements : In this, how a software system
performs desired functions under specific condition is explained. It
also explains required time, required memory, maximum error rate,
etc.
6. Design Constraints : In this, constraints which simply means
limitation or restriction are specified and explained for design team.
Examples may include use of a particular algorithm, hardware and
software limitations, etc.
7. Non-Functional Attributes : In this, non-functional attributes are
explained that are required by software system for better
performance. An example may include Security, Portability,
Reliability, Reusability, Application compatibility, Data integrity,
Scalability capacity, etc.
 Format of SRS Document
8. Preliminary Schedule and Budget : In this, initial
version and budget of project plan are explained which
include overall time duration required and overall cost
required for development of project.
9. Appendices : In this, additional information like
references from where information is gathered,
definitions of some specific terms, acronyms,
abbreviations, etc. are given and explained.
 Uses of SRS Document
 Development team require it for developing product according
to the need.
 Test plans are generated by testing group based on the
describe external behavior.
 Maintenance and support staff need it to understand what the
software product is supposed to do.
 Project manager base their plans and estimates of schedule,
effort and resources on it.
 customer rely on it to know that product they can expect.
 As a contract between developer and customer.
 in documentation purpose.
 Characteristics of good SRS

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
 Characteristics of good SRS

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.
 Characteristics of good SRS

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.
 Characteristics of good SRS

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.
 Characteristics of good SRS
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.