SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

System Name

Prepared By:

<Name of Students – Alphabetically arranged>

<TITLE ACRONYM> SRS

Document Sign-
Document Sign-off

Developers Reviewers

Name Name
Title Title

Name Name
Title Title

University of Baguio Page 2 of 14 10/23/19

<TITLE ACRONYM> SRS

Revision History

Name Date Reason For Changes / Comments Version

e.g.
ACPS 07/17/09  Changed Contents of the V 0.0
Scope, Business
Description, and Objectives
 Added documents in the
System Flowchart (Existing
System)

University of Baguio Page 3 of 14 10/23/19

<TITLE ACRONYM> SRS

Table of Contents
1. INTRODUCTION............................................................ 5
1.1 PURPOSE ............................................................... 5
1.2 SCOPE ................................................................. 5
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS. ................................... 5
1.4 REFERENCES ............................................................. 5
1.5 OVERVIEW .............................................................. 6
2. BUSINESS DESCRIPTION.................................................... 6
2.1 BUSINESS DESCRIPTION..................................................... 6
2.2 BUSINESS OBJECTIVES ..................................................... 6
2.3 STAKEHOLDER PROFILE ..................................................... 7
3. THE OVERALL DESCRIPTION................................................. 7
3.1 PRODUCT PERSPECTIVE ..................................................... 8
3.2 PRODUCT FUNCTIONS ....................................................... 8
3.3 USER CHARACTERISTICS..................................................... 9
3.4 ASSUMPTIONS AND DEPENDENCIES .............................................. 9
3.5 APPORTIONING OF REQUIREMENTS. ............................................. 9
4. SPECIFIC REQUIREMENTS.................................................. 10
4.1 FUNCTIONAL REQUIREMENTS .................................................. 11

University of Baguio Page 4 of 14 10/23/19

<TITLE ACRONYM> SRS

1. Introduction
The following subsections of the Software Requirements
Specifications (SRS) document should provide an
overview of the entire SRS. The thing to keep in
mind as you write this document is that you are
telling what the system must do – so that designers
can ultimately build it. Do not use this document for
design!!!

1.1 Purpose
In one paragraph each, place here the ff.:
Brief introduction of the company
Purpose of this SRS
Intended audience for the SRS

1.2 Scope
This should be an executive-level summary. Do not
enumerate the whole requirements list here.
This subsection contains:
The name of your proposed software product(s). Describe the
application of the software being specified, including
relevant benefits, objectives, and goals.
What the software product(s) will do. (bulleted)
What the software product(s) will not do, if necessary.
(bulleted)
1.3 Definitions, Acronyms, and Abbreviations
Provide the definitions of all jargons, acronyms, and
abbreviations required to properly interpret the SRS.
This information may be provided by reference to one
or more appendices in the SRS or by reference to
documents. This information may be provided by
reference to an Appendix.
Note: Bulleted and Alphabetically arranged and grouped
1.4 References
This subsection contains:
A complete list of all documents referenced elsewhere
in the SRS. Use APA format. Separate them according to
their category, e.g. Published Materials, Unpublished
Materials, Websites, etc.)
This information can be provided by reference to an
appendix or to another document. If your application
uses specific protocols or RFC’s, then reference them
here so designers know where to find them.

University of Baguio Page 5 of 14 10/23/19

<TITLE ACRONYM> SRS

1.5 Overview
In this subsection describe what the rest of the SRS
contains. Explain how the SRS is organized.
The document is divided into 4 major sections:
Section 1: Introduction - <what does this contain?>
Section 2:Business Description - <what does this
contain?>
.
.
.

2. Business Description
This section provides an overview of the business
domain.
2.1 Business Description
Describe here the type of business (organization) and
the unique characteristics of this domain, e.g.
health, telecommunications, banking, real estate, etc.
Also include subdivisions of the business, like
public, private, defense, etc., as each of those may
require or affect the project scope and resource
allocation through understanding of this model (e.g.
security clearance for some type of financial
projects). Try to explain the business environment
associated with or related to it, and other types of
business or sectors that is affected by it.
2.2 Business Objectives
Specify the objective(s) of the organization that your
proposed system will help achieve. Explain here also
how your proposed system will help achieve it/them.
Use the following formula to build up a properly
constructed business objective.
Specific – Clearly state what it is you want to
do/achieve by way of factual description
Measurable – Ensure that the success of your business
objective can be measured against concrete criteria
Achievable – Is the objective achievable given your
current operational resources and/or
competence/capacity
Realistic – Is the scope of the objective within the
bounds of what is recognizable as a proper “business
fit”

University of Baguio Page 6 of 14 10/23/19

<TITLE ACRONYM> SRS

Time Bound – Include a time scale within which the

objectives should be achieved

2.3 Stakeholder Profile

Understanding stakeholder or user needs before
beginning development is crucial to the success of
this process. Describe each stakeholder in the system
by filling in the following table for each
stakeholder. Stakeholder types can be as divergent as
users, strategy departments and technical developers.
[Who is the stakeholder
representative to the project?
Representative
(optional if documented elsewhere.)
What we want here is names.]
[Brief description of the
Description
stakeholder type.]
[Qualify the stakeholders’
expertise, technical background,
Type and degree of sophistication—that
is, guru, business, expert, casual
user, etc.]
[List the stakeholders key
responsibilities with regards to
Responsibilities
the system being developed—that is,
their interest as a stakeholder.]
[How the stakeholder is involved in
the project? Relate where possible
Involvement
to RUP workers—that is,
Requirements Reviewer etc.]
[Are there any additional
deliverables required by the
Deliverables stakeholder? These could be
project deliverables or outputs
from the system under development.]
[Problems that interfere with
Comments / Issues success and any other relevant
information go here.]

3. The Overall Description

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 section 3, and makes them easier to understand. In
a sense, this section tells the requirements in plain
English for the consumption of the customer. Section3

University of Baguio Page 7 of 14 10/23/19

<TITLE ACRONYM> SRS

will contain a specification written for the

developers.
3.1 Product Perspective
Reiterate the system’s purpose here.
Explain, in high level of abstraction, how the
proposed system works.
The software application is divided into the following
modules:
1. File Maintenance - <what data are being
maintained>
2. Transaction - <description>
3. Reports - <description>
4. Utility - <description>
3.2 Product Functions
Provide a summary of the major functions that the
software will perform. Sometimes the function summary
that is necessary for this part can be taken directly
from the section of the higher-level specification (if
one exists) that allocates particular functions to the
software product.
For clarity:
(1) 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.
(2) Textual or graphic 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.
This normally contains the list functionality of the
system in the language of the customer. What
specifically does the system that will be designed
have to do? Drawings are good, but remember this is a
description of what the system needs to do, not how
you are going to build it. (That comes in the design
document).
Functionality Description

e.g. Log-in It is a process a user has to go through to

be able to open ACPS for security purposes.
The system will authenticate the information
provided by the user before loading the
application. The user can only access

University of Baguio Page 8 of 14 10/23/19

<TITLE ACRONYM> SRS

Functionality Description

features of the application specified in his

access level.

3.3 User Characteristics

Describe those general characteristics of the intended
users of the product including educational level,
experience, and technical expertise. Do not state
specific requirements but rather provide the reasons
why certain specific requirements are later specified
in section 3.
What is it about your potential user base that will
impact the design? Their experience and comfort with
technology will drive UI design. Other
characteristics might actually influence internal
design of the system.
User Description Functions
<Position> e.g. End-user  Update tax, SSS,
e.g. PhilHealth and Pag-
Bookkeeper ibig table

3.4 Assumptions and Dependencies

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 might be that a
specific operating system would be available on the
hardware designated for the software product. If, in
fact, the operating system were not available, the SRS
would then have to change accordingly.
This section is catch-all for everything else that
might influence the design of the system and that did
not fit in any of the categories above.
3.5 Apportioning of Requirements.
Identify requirements that may be delayed until future
versions of the system. After you look at the project
plan and hours available, you may realize that you
just cannot get everything done. This section divides
the requirements into different sections for
development and delivery. Remember to check with the
customer – they should prioritize the requirements and
decide what does and does not get done. This can also

University of Baguio Page 9 of 14 10/23/19

<TITLE ACRONYM> SRS

be useful if you are using an iterative life cycle

model to specify which requirements will map to which
interaction.

4. Specific Requirements
This section contains all the software requirements at
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. Throughout this section, every stated
requirement should be externally perceivable by users,
operators, or other external systems. These
requirements should include at a minimum a description
of every input (stimulus) into the system, every
output (response) from the system and all functions
performed by the system in response to an input or in
support of an output. The following principles apply:

(1) Specific requirements should be stated with all the

characteristics of a good SRS
 correct
 unambiguous
 complete
 consistent
 ranked for importance and/or stability
 verifiable
 modifiable
 traceable
(2) Specific requirements should be cross-referenced to
earlier documents that relate
(3) All requirements should be uniquely identifiable
(usually via numbering like 3.1.2.3)
(4) Careful attention should be given to organizing the
requirements to maximize readability (Several
alternative organizations are given at end of document)
Before examining specific ways of organizing the
requirements it is helpful to understand the various
items that comprise requirements as described in the
following subclasses. This section reiterates section
2, but is for developers not the customer. The
customer buys in with section 2, the designers use
section 3 to design and build the actual application.
Remember this is not design. Do not require specific
software packages, etc. unless the customer
specifically requires them. Avoid over-constraining
your design. Use proper terminology:

University of Baguio Page 10 of 14 10/23/19

<TITLE ACRONYM> SRS

The system shall… A required, must have feature

The system should… A desired feature, but may be
deferred ‘til later
The system may… An optional, nice-to-have feature
that may never make it to implementation.
Each requirement should be uniquely identified for
traceability. Usually, they are numbered 3.1, 3.1.1,
3.1.2.1 etc. Each requirement should also be
testable. Avoid imprecise statements like, “The
system shall be easy to use”. Well, no kidding, what
does that mean? Avoid “motherhood and apple pie” type
statements, “The system shall be developed using good
software engineering practice”
Avoid examples, this is a specification, a designer
should be able to read this spec and build the system
without bothering the customer again. Don’t say
things like, “The system shall accept configuration
information such as name and address.” The designer
doesn’t know if that is the only two data elements or
if there are 200. List every piece of information
that is required so the designers can build the right
UI and data tables.
4.1 Functional Requirements
Functional requirements 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 starting with "The system shall…
These include:
 Validity checks on the inputs
 Exact sequence of operations
 Responses to abnormal situation, including
 Overflow
 Communication facilities
 Error handling and recovery
 Effect of parameters
 Relationship of outputs to inputs, including
 Input/Output sequences
 Formulas for input to output conversion
It may be appropriate to partition the functional
requirements into sub-functions or sub-processes.
This does not imply that the software design will also
be partitioned that way.
Use Case Template:

University of Baguio Page 11 of 14 10/23/19

<TITLE ACRONYM> SRS

Note: Group specific functional requirements into

subsections, according to the agreed upon mode of
organization. Place a description of each
subsection.

<Req. ID> <place Use Case Name here>

Description Provide a brief description of the
reason for and outcome of this use case,
or a high-level description of the
sequence of actions and the outcome of
executing the use case.
(Indicate if the use case will be used
or included in the completion of another
use case)
Actor An actor is a person or other entity
external to the software system being
specified who interacts with the system
and performs use cases to accomplish
tasks. Different actors often
correspond to different user classes,
or roles, identified from the customer
community that will use the product.
Name the actor(s) that will be
performing this use case.
Trigger What event, action, or actor triggered
the use case
Complexity <Easy, Average, Difficult, Highly
Complex>
Pre-condition List any activity that must take place,
or any condition that must be true,
before the use case can be started.
Number/Use a bullet for each
precondition. Examples:
1. User’s identity has been
authenticated.
2. User’s computer has sufficient
free memory available to launch
task.
Post Describe the state of the system at the
condition conclusion of the use case execution.
Number/Use a bullet for each post
condition. Examples:
1. Document contains only valid SGML
tags.
2. Price of item in database has been
updated with new value.

Basic flow Actor Action System Response

University of Baguio Page 12 of 14 10/23/19

<TITLE ACRONYM> SRS

Provide a This description

detailed may be written
description of as an answer to
the user actions the hypothetical
and system question, “How
responses that do I <accomplish
will take place the task stated
during execution in the use case
of the use case name>?” This is
under normal, best done as a
expected numbered list of
conditions. This actions
dialog sequence performed by the
will ultimately actor,
lead to alternating with
accomplishing responses
the goal stated provided by the
in the use case system. The
name and normal course is
description. numbered “X.0”,
where “X” is the
Use Case ID.
Alternate Document other, legitimate usage
Flow scenarios that can take place within
this use case separately in this
section. State the alternative course,
and describe any differences in the
sequence of steps that take place.
Exception Describe any anticipated error
Flow conditions that could occur during
execution of the use case, and define
how the system is to respond to those
conditions. Also, describe how the
system is to respond if the use case
execution fails for some unanticipated
reason.
If the use case results in a durable
state change in a database or the
outside world, state whether the change
is rolled back, completed correctly,
partially completed with a known state,
or left in an undetermined state as a
result of the exception.
Includes List any other use cases that are
included (“called”) by this use case.
Common functionality that appears in
multiple use cases can be split out
into a separate use case that is
included by the ones that need that
common functionality.

University of Baguio Page 13 of 14 10/23/19

<TITLE ACRONYM> SRS

Assumptions Assumed fields and values that will be

used in the process
Business List any business rule that influence
Rules this use case.
- Standard formula used
- Source documents
- Special considerations or
protocols involved in the process
Related Place the diagram name or reference
Models/ section from the document where the
Diagrams diagram and related UI can be found
Field Specify list of fields here as
Validations applicable, description and possible
values.
Place the table name or reference
section from the document where the
table can be found.
Author Specify names of authors
Date Specify Date started/revised

University of Baguio Page 14 of 14 10/23/19