Software Requirements Specification (SRS) Template 

The  Software  Requirements  Specifications  (SRS)  document  defines  the 

requirements  for  a  system  and  the  methods  to  be  used  to  ensure  that  each 
requirement  is  satisfied.  The  SRS  should  encapsulate  all  the  characteristics  and 
features  expected  of  the  system  including  functionality,  user  interfaces, 
performance and attributes. Any constraints to the  implementation of the  system 
are also discussed in the SRS. The SRS should exhibit the following properties: 
­  Correct 
­  Unambiguous 
­  Complete 
­  Consistent 
Writing  and  using  good  software  requirements  specifications  is  crucial  for  the 
success  of  a  project.  It  carries  the  initial  vision  for  a  project  through  to  its 
completion and is a vehicle for correcting the vision along the way. 

This  template  is  an  annotated  outline  of  a  software  requirements  specification 
document  adapted  from  the  IEEE  Recommended  Practice  for  Software 
Requirements  Specifications.  The  IEEE  Recommended  Practice  for  Software 
Requirements Specifications have been reduced and modified in order to simplify 
this assignment while still retaining the main components and providing a general 
idea of writing an SRS document. For your own information, please refer to IEEE 
Std  830­1998 1  for  the  full  IEEE  Recommended  Practice  for  Software 
Requirements Specifications (SRS) Document. 

1 
http://www.dcc.ufmg.br/~rodolfo/es­1­03/IEEE­Std­830­1998.pdf
(Team Name) 
(Project Title) 
Software Requirements Specifications 

Name (s): 
Lab Section: 
Workstation: 

Date: (mm/dd/yyyy)
 Software Requirements Specifications 

TABLE OF CONTENTS 

1.  INTRODUCTION  2 
1.1  Purpose  2 
1.2  Scope  2 
1.3  Reference Material  2 
1.4  Definitions and Acronyms  2 
1.5  Overview of Document  2 

2.  OVERALL DESCRIPTION  2 
2.1  Product Perspective  3 
2.2  Product Functions  3 
2.3  Assumptions and Dependencies  3 

3.  SPECIFIC REQUIREMENTS  3 

3.1  External Interface Requirements  3 
3.2  Functional Requirements  4 
3.3  Performance Requirements  5 
3.4  Software System Attributes  5 

4.  APPENDICES  5

1 
 Software Requirements Specifications 

1. INTRODUCTION 

1.1  Purpose 
Identify  the  purpose  of  this  SRS  and  its  intended  audience.  (e.g.  “This  SRS  describes  the 
function  and  performance  requirements  allocated  to  the  X  system.  The  X  is  a  stand­alone 
software ….”). 

1.2  Scope 
Provide a description and scope of the software and explain the goals, objectives and benefits 
of your project. This will provide the basis for the brief description of your product. 

1.3  Reference Material 
This section is optional. 
List  any  documents,  if  any,  which  were  used  as  sources  of  information  for  this  software 
requirements specifications. 

1.4  Definitions and Acronyms 
This section is optional. 
Provide  definitions  of  all  terms,  acronyms,  and  abbreviations  that  might  exist  to  properly 
interpret the SRS. These definitions should be items used in the SRS that are most likely not 
known to the audience. 

1.5  Overview of Document 
A short description of how the rest of the SRS is organized and what can be found in the rest 
of the document. 

2. OVERALL DESCRIPTION 

Provide  an  overall  background  description  of  the  requirements.  This  is  a  very  client  oriented 
view, and should be understandable by a general audience.

2 
 Software Requirements Specifications 

2.1  Product Perspective 
Identify  major  system  interfaces  (ex.  System/component  interfaces,  user  interfaces,  hardware 
interfaces, communication interface) and provide an overall description of their functionalities to 
satisfy the system requirements.  A block diagram showing the major components of the system 
and the interfaces, interconnections and external interfaces should be included. 

2.2  Product Functions 
Provide a summary of the major functions that the software will perform. Do not mention a 
vast amount of details. It should be understandable to the customer or to anyone else reading 
the document for the first time. 

2.3  Assumptions and Dependencies 
List  each  of  the  factors  that  affect  the  requirements  stated  in  the  following  section.  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. 

3. SPECIFIC REQUIREMENTS 

This  section  includes  all  the  technical  information  needed  to  design  the  software.  It  is  more 
specific  than  the  previous  section.  It  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.  Remember,  the  requirements  should  exhibit  the 
following properties: correct, unambiguous, complete and consistent. 

3.1  External Interface Requirements 

This  contains  a  detailed  description  of  all  inputs  and  outputs  expected  from  the  software 
system. For each input or output, the following format should be completed: 
3.1.1  Name of Item (Input or Output) 
3.1.1.1  Purpose and Description 
3.1.1.2  Source / Destination 
Identify the source of the input or the destination of the output 
3.1.1.3  Boundaries 
Valid range, accuracy and/or tolerance 
3.1.1.4  Format
3 
 Software Requirements Specifications 

Format and units of measure 

3.2  Functional Requirements 
Describe each of the  functional  components that were  identified  in Section 2.2. For EACH 
functional component, you should have a sub­section for each sub function that makes up the 
functional component. Each of these sections follow this format: 

3.2.1  Functional Component 1 

3.2.1.1 Sub Function 1 
3.2.1.1.1  Purpose / Description 
3.2.1.1.2  Inputs 
In  what  form/format  will  inputs  arrive;  from  what  sources  input  will  be 
derived, legal domains of each input element 
3.2.1.1.3  Processing 
Describes  the  *outcome*  rather  than  the  *implementation*;  include  any 
validity checks on the data, exact timing of each operation (if needed), how 
to handle unexpected or abnormal situations 
3.2.1.1.4  Outputs 
The form, shape, destination, and volume of the output; output timing; range 
of parameters in the output; unit measure of the output; process by which the 
output is stored or destroyed; process for handling error messages produced 
as output 

3.2.1.2 Sub Function 2 
3.2.1.2.1  Purpose / Description 
3.2.1.2.2  Inputs 
3.2.1.2.3  Processing 
3.2.1.2.4  Outputs 

3.2.2  Functional Component 2 

3.2.2.1 Sub Function 1 
3.2.2.1.1  Purpose / Description
4 
 Software Requirements Specifications 

3.2.2.1.2  Inputs 
3.2.2.1.3  Processing 
3.2.2.1.4  Outputs 

3.2.2.2 SubFunction 2 
3.2.2.2.1  Purpose / Description 
3.2.2.2.2  Inputs 
3.2.2.2.3  …. 
3.2.3  Functional Component 3 

. 
. 
. 
. 

3.3  Performance Requirements 
Issues such as number of connections to the system, number of simultaneous users, response 
time, number of files, size of files and tables, number of files, size of files and tables, number 
of transactions per interval (all defined in terms of acceptable ranges) 

3.4  Software System Attributes 
Issues  such  as  security,  availability,  reliability,  and  maintainability  to  the  extent  possible. 
These  should  be  specified  in  a  quantifiable  way  so they  can  be  accurately  measured  in  the 
end product. 

4. APPENDICES 
This section is optional. 
Appendices may be included if any, either directly or by reference, to provide supporting details that 
could aid in the understanding of the Software Requirements Specifications.

5