Software Requirements Specification (SRS) Template

(Delete this page after reading/before submission)

The document in this file is an annotated outline for specifying software requirements, adapted
from the IEEE Guide to Software Requirements Specifications (Std 830-1993).

Tailor this to your needs, removing explanatory comments as you go along. Where you decide
to omit a section, you might keep the header, but insert a comment saying why you omit the data.

In this template you will find text bounded by the “< >” symbols. This text appears in italics
and is intended to guide you through the template and provide explanations regarding the
different sections in this document. There are two types of comments in this document. These
comments that are in black are intended specifically for that course. These comments that are
in blue are more general and apply to any SRS. Please, make sure to delete all of the
comments before submitting the document.

The explanations provided below, do not cover all of the material, but merely, the general nature
of the information you would usually find in SRS documents. It is based on the IEEE
requirements and was adapted specifically for the needs of Software Engineering courses. Most
of the sections in this template are required sections, i.e. you must include them in your version
of the document. Failure to do so will result in marks deductions. Optional sections will be
explicitly marked as optional. >

Anything highlighted with this color is optional.

Please write ‘to the point text’ in this proposal. No lengthy stories!
Software Requirements Specification for <Project> Page ii

Software Requirements Specification Document

(CS360)
<Project Name>

Group Number: <your group number here>

<name>
<name>
<name>
<name>
<name>

Course: Software Engineering CS360

Instructor: Suleman Shahid
University: Lahore University of Management
Sciences (LUMS

Version: 1.0
Date: (dd/02/2020)
Number of hours spent on this document: <Total hours>
Software Requirements Specification for <Project> Page iii

Content

CONTENTS................................................................................................................................................................III
1 INTRODUCTION................................................................................................................................................1
1.1 DOCUMENT PURPOSE.................................................................................................................................1
1.2 PRODUCT SCOPE........................................................................................................................................1
1.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW....................................................................................1
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS........................................................................................1
1.5 REFERENCES AND ACKNOWLEDGMENTS...................................................................................................1
2 OVERALL DESCRIPTION...............................................................................................................................2
2.1 PRODUCT PERSPECTIVE.............................................................................................................................2
2.2 PRODUCT FUNCTIONALITY..........................................................................................................................2
2.3 USERS AND CHARACTERISTICS..................................................................................................................2
2.4 ASSUMPTIONS AND DEPENDENCIES...........................................................................................................2
3 SPECIFIC REQUIREMENTS...........................................................................................................................3
3.1 FUNCTIONAL REQUIREMENTS.....................................................................................................................3
3.2 EXTERNAL INTERFACE REQUIREMENTS.....................................................................................................4
3.3 USE CASE VIEW..........................................................................................................................................5
4 OTHER NON-FUNCTIONAL REQUIREMENTS..........................................................................................6
4.1 PERFORMANCE REQUIREMENTS................................................................................................................6
4.2 SAFETY AND SECURITY REQUIREMENTS...................................................................................................6
4.3 SOFTWARE QUALITY ATTRIBUTES..............................................................................................................6
APPENDIX A – TOP 10 USER STORIES...............................................................................................................7
APPENDIX B – ARCHITECTURAL SPIKE (ONE STORY).................................................................................8
APPENDIX C - GROUP LOG....................................................................................................................................9
APPENDIX D – CONTRIBUTION STATEMENT.................................................................................................10
Software Requirements Specification for <Project> Page 1

1 Introduction
<TO DO: Please provide a brief introduction to your project and a brief overview of what the reader
will find in this section.>

1.1 Document Purpose

<Identify the product whose software requirements are specified in this document, including the
revision or release number. Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a single subsystem.
TO DO: Write 1-2 paragraphs describing the purpose of this document as explained above.>

1.2 Product Scope

<Provide a short description of the software being specified and its purpose, including relevant
benefits, objectives, and goals.
TO DO: 1-2 paragraphs describing the scope of the product. Make sure to describe the benefits
associated with the product.>

1.3 Intended Audience and Document Overview

<Describe the different types of reader that the document is intended for, such as developers,
project managers, marketing staff, users, testers, and documentation writers (In your case it would
probably be the “client”, teaching assistants and the instructor). Describe what the rest of this SRS
contains and how it is organized. Suggest a sequence for reading the document, beginning with
the overview sections and proceeding through the sections that are most pertinent to each reader
type.>

1.4 Definitions, Acronyms and Abbreviations

<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.
TO DO: Please provide a list of all abbreviations and acronyms used in this document sorted in
alphabetical order.>

1.5 References and Acknowledgments

<List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document. .>
Software Requirements Specification for <Project> Page 2

2 Overall Description
2.1 Product Perspective
<Describe the context and origin of the product being specified in this SRS. For example, state
whether this product is a follow-on member of a product family, a replacement for certain existing
systems, or a new, self-contained product. If the SRS defines a component of a larger system,
relate the requirements of the larger system to the functionality of this software and identify
interfaces between the two. In this part, make sure to include a simple diagram that shows the
major components of the overall system, subsystem interconnections, and external interface. In
this section it is crucial that you will be creative and provide as much information as possible.

TO DO: Provide at least one paragraph describing product perspective. Provide a general diagram
that will illustrate how your product interacts with the environment and in what context it is being
used.>

2.2 Product Functionality

<Summarize the major functions the product must perform or must let the user perform. Details will
be provided in Section 3, so only a high level summary is needed here. Organize the functions to
make them understandable to any reader of the SRS. A picture of the major groups of related
requirements and how they relate, such as a top level data flow diagram will be effective.
TO DO:
1. Provide a bulleted list of all the major functions of the system
2. (Optional) Provide a Data Flow Diagram of the system to show how these functions relate to
each other.>

2.3 Users and Characteristics

<Identify the various users that you anticipate will use this product. Users may be differentiated
based on frequency of use, subset of product functions used, technical expertise, security or
privilege levels, educational level, or experience.
TO DO:
1. Describe the pertinent characteristics of each user. Certain requirements may pertain only to
certain users.
3. Distinguish the most important users for this product from those who are less important to
satisfy.>

2.4 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. The project could be affected if
these assumptions are incorrect, are not shared, or change. Also identify any dependencies the
project has on external factors, such as software components that you intend to reuse from
another project.
TO DO: Provide a short list of some major assumptions that might significantly affect your design.
For example, you can assume that your client will have 1, 2 or at most 50 Automated Banking
Machines. Every number has a significant effect on the design of your system. >
Software Requirements Specification for <Project> Page 3

3 Specific Requirements
3.1 Functional Requirements

< Functional requirements capture the intended behavior of the system. This behavior may be
expressed as services, tasks or functions the system is required to perform. This section is the
direct continuation of section 2.2 where you have specified the general functional requirements.
Here, you should list in detail the different product functions with specific explanations regarding
every function.

TO DO: Brake the functional requirements to several functional areas and divide this section into
subsections accordingly. Provide a detailed list of all product operations related to these functional
areas. You can pick one of the two style shown below:

<Example – Style 1>

<Category: Login and purchase credit >

<categorize based on system functionality and/or user types>

RQ<1> - Customer Functional Requirement 1

• Description
The system will allow the customer to log into the mobile credit recharging portal (MCRP)

• Input
User login details (username and password)

• Processing
Authentication

• Output
User logged in and message is displayed

RQ<2> - Customer Functional Requirement 2

• DescriptionThe system will allow the logged in customer to recharge his/her account using
a credit card. As a notification of a successful recharge, the system will send a confirmation
email to the customer. (<note here: separate output if the system does not authenticate>)

• Input
User login and Credit Card information

• Processing
Information Authentication
(<note here: the credit card will be authenticated using the external system – external
software interface>)

• Output
Customer account is updated and an email sent to the customer

<Example – Style 2>

Software Requirements Specification for <Project> Page 4

Customer Functional Requirements

RQ1: In case of a low balance in the customer account, the system will reject the payment.

RQ2: In case of a three wrong attempts, the system will block of the account for 15 minutes and
will send an email to the customer

3.2 External Interface Requirements

3.2.1 User Interfaces

< Specify:
(1) The logical characteristics of each interface between the software product and its users.
(2) All the aspects of optimizing the interface with the person who must use the system

This is a description of how the system will interact with its users. Is there a GUI, a command line
or some other type of interface? Are there special interface requirements? If you are designing for
the general student population for instance, what is the impact of ADA (American with Disabilities
Act) on your interface?>

3.2.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. You are not
required to specify what protocols you will be using to communicate with the hardware, but it will
be usually included in this part as well.
TO DO: Please provide a short description of the different hardware interfaces. If you will be using
some special libraries to communicate with your software mention them here. In case you have
more than one hardware interface divide this section into subsections.>

3.2.3 Software Interfaces

<Describe the connections between this product and other specific software components (name
and version), including databases, operating systems (Windows? Linux? Etc…), tools, libraries,
and integrated commercial components. Identify the data items or messages coming into the
system and going out and describe the purpose of each. Describe the services needed and the
nature of communications. Identify data that will be shared across software components. If the
data sharing mechanism must be implemented in a specific way (for example, use of a global data
area in a multitasking operating system), specify this as an implementation constraint.
3
TO DO: The previous part illustrates some of the information you would usually include in this part
of the SRS document. To make things simpler, you are only required to describe the specific
interface with the operating system.>
Software Requirements Specification for <Project> Page 5

3.3 Use Case View

<A use case defines a goal-oriented set of interactions between external actors and the system
under consideration. Since sometimes we will not be able to specify completely the behaviour of
the system by just State Diagrams, we use use-cases to complete what we have already started in
section 3.3.1.

3.3.1 Use Case Table

1. Use Case table

Primary Actor Associated Use cases

<Customer> <1. Make profile>
<2. Recharge Account>
<3. View balance>
<Manager>

3.3.2 Use Case Diagram

TO DO: Provide a use case diagram which will encapsulate the entire system and all
possible actors.

<consult lecture slides>

3.3.3 Use Case Description <Only provide description for the top 5 – most
important – user cases!>

Use Case 1:

Use Case 2:

<Consult lecture slides for use case description template>

Software Requirements Specification for <Project> Page 6

4 Other Non-functional Requirements

4.1 Performance 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 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.
TODO: Provide at least 5 different performance requirements based on the information you
collected from the client. For example, you can say “1. Any transaction will not take more than 10
seconds, etc…>

4.2 Safety and Security 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. 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.
TODO:
 Provide at least 3 different safety requirements based on your interview with the client or,
on your related research, and again you need to be creative here.
 Describe briefly what level of security is expected from this product by your client and
provide a bulleted (or numbered) list of the major security requirements.>

4.3 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.

TODO: Use subsections (e.g., 4.3.1 Reliability, 4.3.2 Portability, etc…) provide requirements
related to the different software quality attributes. Base the information you include in these
subsections on the material you have learned in the class. Make sure, that you do not just write
“This software shall be maintainable…” Indicate how you plan to achieve it, & etc…Do not forget to
include such attributes as the design for change. Please note that you need to include at least 2
quality attributes, but it is the mere minimum and it will not receive the full marks.>
Software Requirements Specification for <Project> Page 7
Software Requirements Specification for <Project> Page 8

Appendix A – Top 10 User Stories

<Please include the most important user stories you would like to include/work on in the
development phase. The purpose of this section is to help you understand how to write user
stories in the Agile context. Therefore we are not asking for an exhaustive list. However, we do
want that you intelligently select 10 most important stories. You can use any format for writing
these user stories. We will share a format in the class but each story should be complete and self-
explanatory.>
Software Requirements Specification for <Project> Page 9

Appendix B – Architectural Spike (One Story)

<Write one story which fall under the “Architectural Spike”>
Software Requirements Specification for <Project> Page 10

Appendix C - Group Log

<Please include here all the minutes from your group meetings, your group activities, and any
other relevant information that will assist ME and the Teaching Assistants to determine the effort
put forth to produce this document. You can simple copy minutes (data by date) from the slack
channel>
Software Requirements Specification for <Project> Page 11

Appendix D – Contribution Statement

Name Contributions in this phase Approx. Remarks
Number
of hours