Transcript SOFTWARE REQUIREMENT SPECIFICATION(SRS) INTRODUCTION SRS is:  Requirements specification for a software system  May include a set of use cases.  Also contains non-functional.

SOFTWARE REQUIREMENT
SPECIFICATION(SRS)
INTRODUCTION
SRS is:
 Requirements specification for a software system
 May include a set of use cases.
 Also contains non-functional requirements.
TOPICS
IEEE 830 format explored under 5 subtopics:
1.
Scope of SRS.
2.
References made to other standards.
3.
Consideration of good SRS.
4.
Definitions of specific terms used.
5.
Essential part of SRS.
SCOPE OF SRS
SRS is recommended in important part of
software development cycle as:
 Used in design implementation
 Used in Project Monitoring
 Used in Verification
 Used in Validation
 Used as legal documents of agreement
REFERENCES
List of few references for writing a SRS:
 IEEE Std 610.12-1990, IEEE Standard Glossary
of Software Engineering Terminology.
 IEEE Std 730-1998, IEEE Standard for Software
Quality Assurance Plans.
 IEEE Std 730.1-1995, IEEE Guide for Software
Quality Assurance Planning.
 IEEE Std 828-1998, IEEE Standard for Software
Configuration Management Plans.
 IEEE Std 1028-1997, IEEE Standard for
Software Reviews.
NATURE OF SRS:
The SRS should address following issues:
 Functionality
 External Interfaces
 Performance
 Attributes
 Design Constraints.
Should avoid:
 Design and implementation details
 Additional constraints
CHARACTERISTICS OF GOOD SRS(CONTD)..
Correct
 Unambiguous
 Complete
 Consistent
 Ranked for importance and/or stability
 Verifiable
 Modifiable
 Traceable

OTHER CONSIDERATION OF GOOD SRS
Environment of the SRS.
 Joint preparation of the SRS.
 SRS evolution.
 Prototyping.
 Embedding design in the SRS.
 Embedding project requirements in the SRS.

DEFINITIONS
contract:
A legally binding document includes the technical
and organizational requirements, cost, and
schedule for a product.
PARTS OF SRS
INTRODUCTION (SECTION 1 OF THE
SRS)
It should contain the following subsections:
a) Purpose;
b) Scope;
c) Definitions, acronyms, and abbreviations;
d) References;
e) Overview.

OVERALL DESCRIPTION (SECTION 2 OF
THE SRS)
This section usually consists of six subsections,
as follows:
a) Product perspective;
b) Product functions;
c) User characteristics;
d) Constraints;
e) Assumptions and dependencies;
f) Apportioning of requirements.

PRODUCT PERSPECTIVE (2.1 OF THE
SRS)
Describe how the software operates inside
various constraints. For example, these
constraints could include
a) System interfaces
b) User interfaces
c) Hardware interfaces
d) Software interfaces
e) Communications interfaces
f) Memory
h) Site adaptation requirements

HARDWARE INTERFACES

•
•
e.g. from iTest SRS
For the communication protocol the program
needs these protocols to be installed:
Tcp for the client to connect to the server in
online mode.
Storing devices(flash,optical disks etc.) for the
client to take a test in offline mode.
PRODUCT FUNCTIONS (2.2 OF THE SRS)
This subsection of the SRS should provide a
summary of the major functions that the
software will perform.
 e.g. from iTest SRS
• Sorting questions: Sort questions from A-Z or ZA.
• Filter questions: Show questions based on their
difficulty or flag category.

USER CHARACTERISTICS (2.3 OF THE
SRS)

This subsection of the SRS should describe those
general characteristics of the intended users of
the product including educational level,
experience, and technical expertise. It should not
be used to state specific requirements, but rather
should provide the reasons why certain specific
requirements are later specified in Section 3 of
the SRS.
CONSTRAINTS (2.4 OF THE SRS)
This subsection of the SRS should provide a
general description of any other items that will
limit the developer’s options like
a) Hardware limitations (e.g., signal timing
requirements);
b) Interfaces to other applications;
c) Control functions;
d) Reliability requirements;
e) Safety and security considerations.

ASSUMPTIONS AND DEPENDENCIES (2.5 OF
THE SRS)
This subsection of the SRS should list each of the
factors that affect the requirements stated in the
SRS. These factors are not design constraints on
the software but are, rather, any changes to them
that can affect the requirements in the SRS.
 e.g. from iTest SRS
Language editor for additional translations.

APPORTIONING OF REQUIREMENTS (2.6
OF THE SRS)

This subsection of the SRS should identify
requirements that may be delayed until future
versions of the system.
SPECIFIC REQUIREMENTS (SECTION 3
OF THE SRS)

This section of the SRS should contain all of the
software requirements to a level of detail
sufficient to enable designers to design a system
to satisfy those requirements, and testers to test
that the system satisfies those requirements.
EXTERNAL INTERFACE

This should be a detailed description of all inputs
into and outputs from the software system
FUNCTIONAL REQUIREMENTS

Functional requirements should define the
fundamental actions that must take place in the
software in accepting and processing the inputs
and in processing and generating the outputs.
These are generally listed as ‘shall’ statements
LOGICAL DATABASE REQUIREMENTS
This should specify the logical requirements for
any information that is to be placed into a
database. This may include the following:
a) Types of information used by various functions
b) Frequency of use
c) Accessing capabilities
d) Data entities and their relationships
e) Integrity constraints
f) Data retention requirements

DESIGN CONSTRAINTS

This should specify design constraints that can
be imposed by other standards, hardware
limitations, etc.
e.g. from iTest SRS
This program is created using C++ programming
language and uses the Qt4 libraries for the main
iTestClient and iTestServer modules. So a
minimum PC having at least 64mb of RAM and
CPU over 400mhz is required to run the program
with good speed. Also the program uses at least
15 megabytes of hard disk space to store the
program libraries.
STANDARD COMPLIANCE

This subsection should specify the requirements
derived from existing standards or regulations.
SOFTWARE SYSTEM ATTRIBUTES
There are a number of attributes of software that
can serve as requirements.
 Reliability
 Availability
 Security
 Maintainability
 Portability

ORGANIZING THE SPECIFIC REQUIREMENTS

•
•
•
•
•
•
•
Different classes of systems lend themselves to
different organizations of requirements in
Section 3 of the SRS.
System mode
User class
Objects
Features
Stimulus
Response
Functional Hierarchy
e.g. from iTest organised by system feature
SUPPORTING INFORMATION
The supporting information makes the SRS
easier to use. It includes the following:
a) Table of contents and index
b)
Appendixes.

REFERENCES
[1] IEEE-SRS-format-830-1998
[2] Software_Requirements_Specification-iTest