Software Requirement Specification

 Introduction
o Purpose
o Project scope
o Definitions, acronyms, and abbreviations
o References
o Overview
 Overall Description
o Product perspective
o Product functions
o User classes and characteristics
o Operating environment
o Design and implementation constraints
o User documentation
o Assumptions and dependencies
 System features
o System feature 1
 Description and priority
 Stimulus/Response sequences
 Functional requirements
o System feature 2
 Description and priority
 Stimulus/Response sequences
 Functional requirements
o System feature....
 External interface requirements
o User interfaces
o Software interfaces
o Hardware interfaces
o Communication interfaces
 Non functional requirements
o Performance requirements
o Safety requirements
o Software quality attributes
o Security requirements
 Other requirements
 Appendix A: Glossary
 Appendix B: Analysis Models
 Appendix C: Issues list

1
Introduction
This section gives a scope description and overview of everything included in this SRS document. Also,
the purpose for this document is described and a list of abbreviations and definitions is provided.

Purpose
This subsection should:

 Delineate the purpose of the SRS;

 Specify the intended audience for the SRS.

Project Scope
This part should

 Identify the software product(s) to be produced by name (e.g., Host DBMS, Report Generator,
etc.);
 Explain what the software product(s) will, and, if necessary, will not do;
 Describe the application of the software being specified, including relevant benefits, objectives,
and goals;
 Be consistent with similar statements in higher-level specifications (e.g., the system
requirements specification), if they exist.

Definitions, acronyms, and abbreviations

This subsection should provide the definitions of all terms, acronyms, and abbreviations required to
properly interpret the SRS.

References
This subsection should

1. Provide a complete list of all documents referenced elsewhere in the SRS;

2. Identify each document by title, report number (if applicable), date, and publishing organization;
3. Specify the sources from which the references can be obtained.

Overview
This subsection should:

 Describe what the rest of the SRS contains;

 Explain how the SRS is organized.

Overall Description
This section of the SRS should describe the general factors that affect the product and its requirements.
This section does not state specific requirements. Instead, it provides a background for those
requirements, which are defined in detail in Section 3 of the SRS, and makes them easier to understand.

Product Perspective
This subsection of the SRS should put the product into perspective with other related products. If the
product is independent and totally self-contained, it should be so stated here. If the SRS defines a

2
product that is a component of a larger system, as frequently occurs, then this subsection should relate
the requirements of that larger system to functionality of the software and should identify interfaces
between that system and the software.

Product Functions
This subsection of the SRS should provide a summary of the major functions that the software will
perform. For example, an SRS for an accounting program may use this part to address customer account
maintenance, customer statement, and invoice preparation without mentioning the vast amount of
detail that each of those functions requires.

Note that:

a. The functions should be organized in a way that makes the list of functions understandable to
the customer or to anyone else reading the document for the first time.
b. Textual or graphical methods can be used to show the different functions and their
relationships. Such a diagram is not intended to show a design of a product, but simply shows
the logical relationships among variables.

User classes and characteristics

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.

Some systems provide different sets of functions to different classes of users. For example, an elevator
control system presents different capabilities to passengers, maintenance workers, and fire fighters.

Operating environment
This subsection describes in which environment the application will function(OS, database type,
software, hardware, with which applications to function).

Design and Implementation Constraints

This should specify design constraints that can be imposed by other standards, hardware limitations,
etc.

User Documentation
Defines what documentation does the user need to use this product. I.e. a manual.

Assumptions and dependencies

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. For example, an assumption may be that a specific operating system
will be available on the hardware designated for the software product. If, in fact, the operating system is
not available, the SRS would then have to change accordingly.

3
System features
Here are described the main features of the product which will be analyzed to make documentation for
test execution.

System feature 1
In this subsection the name and unique identifier are given to the feature. Don’t really say “System
Feature 1.” State the feature name in just a few words.

Description and priority

Here is described the feature of the product. What for is it? What it should do? What is its
priority for completion?

Stimulus\Response Sequences
The trigger to launch the feature. Here is described how the feature is launched and how it
behaves during launch sequence.

Functional Requirements
Describes how the feature must work, how reacts to failures, what must it check, how it
represents data, how and where it saves data etc. Each requirement should be uniquely identified
with a sequence number or a meaningful tag of some kind:

REQ-1:
REQ-2:

External interface requirements

How the system will work with the outside world, if it will. What are the API, how and where from will it
receive data.

This section provides a detailed description of all inputs into and outputs from the system. It also gives a
description of the hardware, software and communication interfaces and provides basic prototypes of
the user interface.

User Interfaces
Describe the logical characteristics of each user interface that the system needs. Some possible items to
include are:

 References to GUI standards or product family style guides that are to be followed.
 Standards for fonts, icons, button labels, images, color schemes, field tabbing sequences,
commonly used controls, and the like.
 Screen layout or resolution constraints.
 Standard buttons, functions, or navigation links that will appear on every screen, such as a help
button.
 Shortcut keys.

4
  Message display conventions.
 Layout standards to facilitate software localization.

Document the user interface design details, such as specific dialog box layouts, in a separate user
interface specification, not in the SRS. Including screen mock-ups in the SRS to communicate another
view of the requirements is helpful, but make it clear that the mock-ups are not the committed screen
designs. If the SRS is specifying an enhancement to an existing system, it sometimes makes sense to
include screen displays exactly as they are to be implemented. The developers are already constrained
by the current reality of the existing system, so it's possible to know up front just what the modified, and
perhaps the new, screens should look like.

Software Interfaces
Describe the connections between this product and other software components (identified by name and
version), including databases, operating systems, tools, libraries, and integrated commercial
components. State the purpose of the messages, data, and control items exchanged between the
software components. Describe the services needed by external software components and the nature of
the intercomponent communications. Identify data that will be shared across software components. If
the data-sharing mechanism must be implemented in a specific way, such as a global data area, specify
this as a constraint.

Hardware Interfaces
Describe the characteristics of each interface between the software and hardware components of the
system. This description might include the supported device types, the data and control interactions
between the software and the hardware, and the communication protocols to be used.

Communication Interfaces
State the requirements for any communication functions the product will use, including e-mail, Web
browser, network communications protocols, and electronic forms. Define any pertinent message
formatting. Specify communication security or encryption issues, data transfer rates, and synchronization
mechanisms.

Non functional requirements

Performance
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 the timing relationships for real time systems. Make such requirements as specific as
possible. You may need to state performance requirements for individual functional requirements or
features.

Safety Requirements
Specify those requirements that are concerned with possible loss, damage, or harm that could result
from the use of the product. Define any safeguards or actions that must be taken, as well as actions that
must be prevented. Refer to any external policies or regulations that state safety issues that affect the
product’s design or use. Define any safety certifications that must be satisfied.

5
Software Quality Attributes
Specify any additional quality characteristics for the product that will be important to either the customers
or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability,
maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be
specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for
various attributes, such as ease of use over ease of learning.

Security Requirements
Specify any requirements regarding security or privacy issues surrounding use of the product or
protection of the data used or created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations containing security issues that affect the
product. Define any security or privacy certifications that must be satisfied.

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.

Appendix A: Glossary
Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations. You
may wish to build a separate glossary that spans multiple projects or the entire organization, and just
include terms specific to a single project in each SRS.

Appendix B: Analysis Models

Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-
transition diagrams, or entity-relationship diagrams.

Appendix C: Issue List

Collect a numbered list of the TBD (to be determined/done) references that remain in the SRS so they can
be tracked to closure.