Software requirement specification

Software Requirement
specification
SUBMITTED TO:
XYZ
(Assistant Professor)
(Department of Computer Science and Engineering)
SUBMITTED BY:

Table of Content
 What is SRS
 Nature of SRS
 Role of SRS
 Characteristics of good SRS
 Template
 SRS template description

What is SRS
 The production of the requirements stage of the software development
process is Software Requirements Specifications (SRS) (also called
a requirements document). This report lays a foundation for software
engineering activities and is constructing when entire requirements are
elicited and analyzed. SRS is a formal report, which acts as a
representation of software that enables the customers to review whether it
(SRS) is according to their requirements. Also, it comprises user
requirements for a system as well as detailed specifications of the system
requirements.

Nature of SRS
The basic issues that SRS writer shall address are the following:
 1. Functionality: What the software is supposed to do?
 2. External Interfaces: How does the software interact with people,
system's hardware, other hardware and other software?
 3. Performance: What is the speed, availability, response time, recovery
time etc.
 4. Attributes: What are the considerations for portability, correctness,
maintainability, security, reliability etc.
 5. Design Constraints Imposed on an Implementation: Are there any
required standards in effect, implementation language, policies for
database integrity, resource limits, operating environment etc.

Role of SRS
Since SRS has a specific role to play in software development process,
SRS writer should be careful for following points :
 1. SRS should correctly define all the software requirements. A software
requirement may exist because of the nature of the task to be solved or
because of a specific characteristic of the project.
 2. SRS should not describe any design or implementation details. These
should be described in the design stage of the project.
 3. SRS should not impose additional constraints on the software. These are
properly specified in other documents such as software quality assurance
plan.

Characteristics of good SRS
Following are the characteristics of a good SRS document:
 Correctness:
User review is used to ensure the correctness of requirements stated in the SRS.
SRS is said to be correct if it covers all the requirements that are actually expected
from the system.
 Completeness:
Completeness of SRS indicates every sense of completion including the numbering
of all the pages, resolving the to be determined parts to as much extent as possible
as well as covering all the functional and non-functional requirements properly.
 Consistency:
Requirements in SRS are said to be consistent if there are no conflicts between any
set of requirements. Examples of conflict include differences in terminologies used at
separate places, logical conflicts like time period of report generation, etc.
 Unambiguousness:
A SRS is said to be unambiguous if all the requirements stated have only 1
interpretation. Some of the ways to prevent unambiguousness include the use of
modelling techniques like ER diagrams, proper reviews and buddy checks, etc.

 Ranking for importance and stability:
There should a criterion to classify the requirements as less or more important or more
specifically as desirable or essential. An identifier mark can be used with every
requirement to indicate its rank or stability.
 Modifiability:
SRS should be made as modifiable as possible and should be capable of easily
accepting changes to the system to some extent. Modifications should be properly
indexed and cross-referenced.
 Verifiability:
A SRS is verifiable if there exists a specific technique to quantifiably measure the extent
to which every requirement is met by the system. For example, a requirement starting
that the system must be user-friendly is not verifiable and listing such requirements
should be avoided.
 Traceability:
One should be able to trace a requirement to design component and then to code
segment in the program. Similarly, one should be able to trace a requirement to the
corresponding test cases.

 Design Independence:
There should be an option to choose from multiple design alternatives for the final
system. More specifically, the SRS should not include any implementation details.
 Testability:
A SRS should be written in such a way that it is easy to generate test cases and
test plans from the document.
 Understandable by the customer:
An end user maybe an expert in his/her specific domain but might not be an expert
in computer science. Hence, the use of formal notations and symbols should be
avoided to as much extent as possible. The language should be kept easy and
clear.
 Right level of abstraction:
If the SRS is written for the requirements phase, the details should be explained
explicitly. Whereas, for a feasibility study, fewer details can be used. Hence, the
level of abstraction varies according to the purpose of the SRS.

SRS TEMPLATE
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definition, acronyms and abbreviations.
1.4 References
1.5 Overview
2. The overall description
2.1 Product perspective
2.1.1 System interface
2.1.2 Interface
2.2.3 Hardware interface
2.1.4 Communications interface
2.1.5 Memory constraints
2.1.6 Operations
2.1.7 Site adaption requirements

3. Specific Requirements
3.1 External interface
3.2 Functions
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design constraints
3.5.1 Standards compliance
3.6 Software system attribute
3.6.1 Reliability
3.6.2 Availability
3.6.3 Security
3.6.4 Maintainability
3.6.5 Portability
3.7 Organising the specific requirements
3.7.1 System mode
3.7.2 User class

3.7.3 Objects
3.7.4 Features
3.7.5 Features
3.7.6 Response
3.7.7 Functional hierarchy
3.8 Additional comments
4. Change managements process
5. Documents approvals
6. Supporting information

Description
1. Introduction
1.1 Purpose  Identify the product whose software requirements are specified in this
document, including the revision or release number.
1.2 Document Conventions  Describe any standards or typographical conventions that
were followed when writing this SRS, such as fonts or highlighting that have special
significance.
1.3 Scope  . Relate the software to corporate goals or business strategies. If a separate
vision and scope document is available, refer to it
1.4 Reference  List any other documents or Web addresses to which this SRS refers. These
may include user interface style guides, contracts, standards, etc.
2. Overall Description
2.1 Product Perspective  Describe the context and origin of the product being specified in
this SRS.

2.2 Product Functions  Summarize the major functions the product must perform or
must let the user perform.
2.3 User Classes and Characteristics  Identify the various user classes that you
anticipate will use this product. User classes may be differentiated based on frequency of
use, subset of product functions used, technical expertise, security or privilege levels,
educational level, or experience.
2.4 Operating Environment  Describe the environment in which the software will
operate, including the hardware platform, operating system and versions, and any other
software components or applications.
2.5 Design and Implementation Constraints  Describe any items or issues that will
limit the options available to the developers. These might include: corporate or regulatory
policies.
2.6 Assumptions and Dependencies  List any assumed factors (as opposed to known
facts) that could affect the requirements stated in the SRS. These could include third-party
or commercial components that you plan to use, issues around the development or
operating environment, or constraints.

3. External Interface Requirements
3.1 User Interfaces  Describe the logical characteristics of each interface between the
software product and the users.
3.2 Hardware Interfaces  Describe the logical and physical characteristics of each
interface between the software product and the hardware components of the system. This
may include the supported device types, the nature of the data and control interactions
between the software and the hardware, and communication protocols to be used.
3.3 Software Interfaces  Describe the connections between this product and other
specific software components (name and version), including databases, operating systems,
tools, libraries, and integrated commercial components.
3.4 Communications Interfaces  Describe the requirements associated with any
communications functions required by this product, including e-mail, web browser,
network server communications protocols, electronic forms, and so on.
4. System Features
This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product.

You may prefer to organize this section by use case, mode of operation, user class, object
class, functional hierarchy, or combinations of these, whatever makes the most logical
sense for your product.
5. Other Nonfunctional Requirements
If there are performance requirements for the product under various circumstances, state
them here and explain their rationale, to help the developers understand the intent and
make suitable design choices.
Specify those requirements that are concerned with possible loss, damage, or harm that
could result from the use of the product.
Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product.
6. Other Requirements
Define any other requirements not covered elsewhere in the SRS. This might include
database requirements, internationalization requirements, legal requirements, reuse
objectives for the project, and so on. Add any new sections that are pertinent to the project.

Software requirement specification

Recommended

More Related Content

What's hot (20)

Similar to Software requirement specification (20)

Recently uploaded (20)

Software requirement specification