The Islamia University of Bahawalpur: Department of Software Engineering
The Islamia University of Bahawalpur: Department of Software Engineering
The Islamia University of Bahawalpur: Department of Software Engineering
By
Student Name
Roll No
Section
Session Spring 2020 – 2024
Supervisor
Supervisor Name
Revision History
ii
Project Title
Document Approval
The following Software Requirements Specification has been accepted and approved by the
following:
Supervised by
<Supervisor’s Name>
Signature______ _____
iii
Project Title
Table of Contents
1. Introduction 1
1.1 Purpose 1
1.2 Scope 1
1.3 Definitions, Acronyms, and Abbreviations. 1
1.4 References 1
1.5 Overview 1
3. Specific Requirements 4
3.1 External Interface Requirements 5
3.1.1 System Interfaces 5
3.1.2 Interfaces 5
3.1.3 Hardware Interfaces 5
3.1.4 Software Interfaces 5
3.1.5 Communications Interfaces 6
3.2 Functional Requirements 6
3.2.1 <Functional Requirement or Feature #1> 6
3.2.2 <Functional Requirement or Feature #2> 7
3.3 Use Cases 7
3.3.1 Use Case #1 7
3.3.2 Use Case #2 7
3.4 Classes / Objects 7
3.4.1 <Class / Object #1> 7
3.4.2 <Class / Object #2> 7
3.5 Non-Functional Requirements 7
3.5.1 Performance 8
3.5.2 Reliability 8
3.5.3 Availability 8
3.5.4 Security 8
3.5.5 Maintainability 8
3.5.6 Portability 8
3.6 Inverse Requirements 8
3.7 Logical Database Requirements 8
3.8 Design Constraints 8
3.8.1 Standards Compliance 8
iv
Project Title
4. Analysis Models 9
4.1 Sequence Diagrams 9
4.2 Data Flow Diagrams (DFD) 9
4.3 State-Transition Diagrams (STD) 9
5. Supporting Information 9
Appendix A – Background Research on: 9
Appendix B – Data Dictionary 9
v
Project Title
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
Identify the purpose of this SRS and its intended audience. In this subsection, describe
the purpose of the particular SRS and specify the intended audience for the SRS.
1.2 Scope
In this subsection:
(1) Identify the software product(s) to be produced by name
(2) Explain what the software product(s) will, and, if necessary, will not do
(3) Describe the application of the software being specified, including
relevant benefits, objectives, and goals
(4) Be consistent with similar statements in higher-level specifications if they
exist
This should be an executive-level summary. Do not enumerate the whole requirements
list here.
1.4 References
In this subsection:
(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.
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.
1.5 Overview
In this subsection:
(1) Describe what the rest of the SRS contains
2.1.1 Operations
Specify the normal and special operations required by the user such as:
(1) The various modes of operations in the user organization
(2) Periods of interactive operations and periods of unattended operations
(3) Data processing support functions
(4) Backup and recovery operations
(Note: This is sometimes specified as part of the User Interfaces section.) If you
separate this from the UI stuff earlier, then cover business process type stuff that would
impact the design. For instance, if the company brings all their systems down at
midnight for data backup that might impact the design. These are all the work tasks
that impact the design of an application, but which might not be located in software.
3. Specific Requirements
This will be the largest and most important section of the SRS. The customer
requirements will be embodied within Section 2, but this section will give the D-
requirements that are used to guide the project’s software design, implementation, and
testing.
Each requirement in this section should be:
• Correct
• Traceable (both forward and backward to prior/future artifacts)
• Unambiguous
• Verifiable (i.e., testable)
• Prioritized (with respect to importance and/or stability)
• Complete
• Consistent
3.1.2 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?
(1) Name
(2) Mnemonic
(3) Specification number
(4) Version number
(5) Source
For each interface, provide:
(1) Discussion of the purpose of the interfacing software as related to this software
product
(2) Definition of the interface in terms of message content and format
Here we document the APIs, versions of software that we do not have to write, but that
our system has to use. For instance if your customer uses SQL Server 7 and you are
required to use that, then you need to specify i.e.
3.2.1.2 Inputs
3.2.1.3 Processing
3.2.1.4 Outputs
3.4.1.2 Functions
<Reference to functional requirements and/or use cases>
3.5.1 Performance
3.5.2 Reliability
3.5.3 Availability
3.5.4 Security
3.5.5 Maintainability
3.5.6 Portability
4. Analysis Models
List all analysis models used in developing specific requirements previously given in
this SRS. Each model should include an introduction and a narrative description.
Furthermore, each model should be traceable the SRS’s requirements.
5. Supporting Information